Swftbox

Swftbox runs a multi-service platform — web and mobile applications backed by containerized microservices — supporting e-commerce parcel delivery and on-demand services. The business decided to move from Google Cloud Platform to AWS to standardize on AWS-native services and improve operational resilience, but faced four compounding obstacles: executing a low-risk GCP-to-AWS migration with limited internal cloud expertise; technical debt in infrastructure and CI/CD; poor visibility and reliability in ECS-based deployments, where a pipeline could report success once an image reached the registry even if the actual service deployment failed; and a set of self-managed components — message queues, search and document databases, SSL certificates — that needed rationalizing without jeopardizing uptime on a revenue-bearing logistics platform.

The objectives were explicit: safely migrate production workloads, re-implement the architecture as Infrastructure as Code with Terraform, establish reliable CI/CD aligned to AWS best practices, minimize downtime, improve cost efficiency and access management, and upskill Swftbox’s engineering team on AWS and Terraform so they could operate independently after handover.

Assess (from January 2025).VeUP produced the target-state architecture first, mapping each GCP service to its AWS counterpart. Because the workloads were already containerized, a like-for-like replatform was selected as the primary 7Rs disposition — containers onto Amazon ECS, static content onto S3 with CloudFront, lightweight utility APIs onto Lambda — keeping architectural change, and therefore migration risk, to a minimum for a lean engineering team. The phased migration plan ran Discovery & Planning (infrastructure, application, and data-schema audit with dependency documentation and contingency planning), AWS Environment Setup (account provisioning, access policies, GCP-to-AWS connectivity, and a pre-migration checkpoint), Migration Execution (incremental workload migration and validation, final data synchronization, cutover preparation, and live cutover), and Testing & Validation (functional testing and data-integrity validation). Sequencing discipline was contractual: non-critical systems first, then mission-critical workloads, with continuity of operations and meeting or exceeding existing SLAs for uptime, latency, and performance as stated requirements. Scope decisions were equally explicit — of 24 repositories only the six active ones carried forward, and candidate moves to managed database and messaging services were evaluated with documented cost analysis rather than assumed, including a cost break-even analysis between Lambda and ECS for the utility APIs.

Mobilize (June–September 2025).The master Statement of Work — covering audit, refactoring, and validation of the migration — was executed in June and July 2025. VeUP audited the migrated workloads against AWS best practices, produced a criticality-rated findings backlog with remediation steps, and closed the highest-priority items, including migrating application secrets out of object storage into AWS Secrets Manager. In parallel, the Infrastructure-as-Code foundation went in: reusable Terraform modules for the ECS clusters and core application infrastructure, validated in a lab environment before promotion. Governance ran throughout — a regular standup cadence with Swftbox’s engineers, retrospectives at key milestones, a named principal contact, and formal written change control for any scope or timeline movement.

Migrate & Modernize (through October 2025).The modernization centerpiece was the CI/CD estate. Delivery tooling had been split — production on GitLab CI, lower environments on AWS CodeBuild — so VeUP migrated all six active pipelines to GitHub Actions on a single standardized workflow, with secrets drawn from AWS Secrets Manager at deploy time. Each pipeline gained end-to-end deployment visibility from image push in Amazon ECR through ECS service and task status, post-deploy health checks verifying that tasks start and containers are healthy against agreed criteria, and circuit-breaker logic that rolls a failed deployment back to the last known-good task definition — implemented where technically feasible, formally verified in production on the ECS pipelines, and documented as runbook procedure where legacy coupling prevented full automation. Cutover for the CI/CD estate followed the same discipline as the workload migration: dry-run validation in development and staging, then production validation, with rollback verified before handover. Application infrastructure was rebuilt as Terraform modules across the six repositories with environment-specific state, and enablement was built into the plan rather than appended to it — Terraform and IaC training sessions, GitHub Actions onboarding, live walkthroughs of the modularized code committed into Swftbox’s own GitHub, per-repository documentation, and runbooks delivered at handover. Deeper refactors, such as the self-managed queue tier, were deliberately deferred and documented as the customer’s forward modernization path, and a generative-AI roadmap was delivered as an in-scope advisory deliverable. The engagement completed on 24 October 2025 with the customer team operating the environment themselves.

The estate that moved and modernized, in concrete terms:

• A containerized microservices platform — web and mobile front ends with microservice back ends — running in production in AWS me-central-1.
• 24 source repositories, of which six active workloads with CI/CD pipelines deploy to Amazon ECS clusters, S3 + CloudFront front ends, and Lambda utility services; inactive repositories were explicitly retired or retained out of scope.
• A data tier on Amazon RDS for PostgreSQL with ElastiCache for caching, alongside self-managed search and document stores on ECS; managed-service alternatives for the database and messaging tiers were assessed with documented cost-benefit findings, and the message-queue refactor was consciously deferred because it required application changes across every service — a risk-based sequencing decision, documented as such.
• Application secrets migrated from object storage into AWS Secrets Manager via a reusable Terraform module integrated with the deployment pipelines.
• The full CI/CD estate: six production pipelines consolidated from a split GitLab CI / AWS CodeBuild toolchain onto standardized GitHub Actions workflows with Slack and GitHub notifications and per-repository documentation.

Production runs in me-central-1 with isolated VPCs for production, staging, and development. Containerized services run on Amazon ECS behind an Application Load Balancer; static web content is served from S3 with CloudFront; lightweight utility APIs run on Lambda; the data tier uses RDS for PostgreSQL with ElastiCache; container images live in Amazon ECR and application secrets in AWS Secrets Manager. Ingress terminates in public subnets at the load balancer, while ECS workloads and data services sit in private subnets — and the whole application layer is provisioned through reusable Terraform modules with environment-specific state, so the security posture is version-controlled and repeatable.

The delivered estate holds up against all six pillars as evidenced in the engagement. Operational excellence: everything at the application layer is Terraform, deployments surface end-to-end status from image push to running task, and per-repository documentation plus handover runbooks make operations repeatable. Security: secrets centralized in AWS Secrets Manager and injected at deploy time, workloads and data confined to private subnets with ingress-only public subnets, IAM roles and security groups version-controlled in Terraform, and a criticality-rated security risk assessment delivered with remediation steps — alongside documented assessments of certificate consolidation onto ACM and session-based access management in place of bastion hosts. Reliability: the ECS scheduler maintains desired task counts and replaces unhealthy tasks, the load balancer routes only to healthy targets, and deployment failures are contained rather than propagated — post-deploy health checks gate each release and circuit-breaker logic rolls back to the last known-good task definition. Performance efficiency: compute placement was decided on evidence, including a documented Lambda-versus-ECS cost break-even analysis by request volume for the utility APIs. Cost optimization: a cost-optimization analysis was part of the validation phase, and every candidate move to a managed service carried a documented cost-benefit finding before a wave-one decision was made. Sustainability: the like-for-like replatform lands on managed, demand-scaled services — ECS, S3, CloudFront, Lambda — with capacity administered by AWS rather than idle self-managed infrastructure.