Swftbox validates its GCP-to-AWS migration and lays a Terraform IaC foundation

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 the right 7Rs call — 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 migration ran in phases: discovery and planning (a full infrastructure, application, and data-schema audit with dependency mapping and contingency plans), AWS environment setup (account provisioning, access policies, GCP-to-AWS connectivity, and a pre-migration checkpoint), execution (incremental workload moves and validation, final data synchronization, and live cutover), then functional and data-integrity testing. Sequencing was deliberate: non-critical systems first, then mission-critical workloads, with the bar set at meeting or beating existing SLAs for uptime, latency, and performance throughout. Scope was equally deliberate — of 24 repositories only the six active ones carried forward, and every candidate move to a managed database or messaging service was costed rather than assumed, down to a break-even analysis between Lambda and ECS for the utility APIs.

Mobilize (June–September 2025).The main build — audit, refactoring, and validation of the migration — kicked off in June 2025. VeUP audited the migrated workloads against AWS best practices, ranked every finding by how much it could hurt, and closed the worst ones first — starting with application secrets, which moved 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, proven in a lab environment before promotion. The whole thing ran on a steady rhythm — standups with Swftbox’s engineers, retrospectives at key milestones, a named principal contact, and written change control whenever scope or timeline needed to move.

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 — proven in production on the ECS pipelines, and where legacy coupling ruled out full automation, the rollback lives as a runbook instead. Cutover for the CI/CD estate followed the same discipline as the workload migration: dry runs in development and staging, then production, with rollback proven 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 at handover. Deeper refactors, such as the self-managed queue tier, were deliberately deferred — mapped out as Swftbox’s forward modernization path rather than rushed into this one — and VeUP left the team a generative-AI roadmap for what comes next. By late October 2025 the engagement was complete and Swftbox’s own team was 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 costed before any decision, and the message-queue refactor was consciously deferred because it would have meant application changes across every service — a risk call, not an oversight.
• 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 estate Swftbox now runs holds up against all six Well-Architected pillars. 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 security risk assessment that ranked every finding and paired it with a fix — plus a clear-eyed look at consolidating certificates onto ACM and replacing bastion hosts with session-based access. 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 — a Lambda-versus-ECS cost break-even analysis by request volume settled where the utility APIs should run. Cost optimization: a cost-optimization analysis was part of the validation phase, and no move to a managed service was made on faith — each was costed before a wave-one decision. 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.