Moving a production platform from DigitalOcean to AWS

Context

I joined a SaaS platform with a clear first mandate: plan and lead its move from DigitalOcean to AWS. The existing environment combined application servers, a self-hosted MySQL database, and media stored on the same compute fleet. Traffic reached servers directly, making scaling, maintenance, and storage growth harder to separate.

This was not only a hosting change. It was a chance to reduce operational risk, create clearer infrastructure boundaries, and make future growth easier to manage.

Constraints

The platform had to continue serving customers while its compute, database, storage, delivery, networking, and DNS layers changed. The work was led by a small infrastructure team, so the target architecture also had to be realistic to operate after the migration—not merely impressive on a diagram.

The migration plan therefore favored staged replication, explicit verification, controlled cutover steps, and rollback awareness. The architecture shown here is sanitized to protect account boundaries and customer-specific details.

1. 01Source platform

   Compute · database · media

2. 02Replication

   MGN · DMS · staged verification

3. 03AWS platform

   EC2 · RDS · private networking

4. 04Delivery edge

   ALB · S3 · CloudFront · Route 53

Decisions

Improve the architecture instead of copying it

A direct lift-and-shift would have reproduced the same coupling on AWS. Media moved off application servers into S3 and CloudFront, separating storage and delivery from compute. Application Load Balancers replaced direct server routing, creating a cleaner path for health checks and autoscaling.

Use purpose-built migration services

AWS Application Migration Service (MGN) replicated DigitalOcean servers into EC2. AWS Database Migration Service (DMS) moved the self-hosted database into Amazon RDS while keeping the source available during the migration window.

Harden access as part of the move

The target environment introduced least-privilege IAM and VPN-only connectivity to private infrastructure. VPC design, security groups, NACLs, NAT gateways, and private-resource access were treated as part of the migration—not as cleanup for later.

Separate transitional and final routing

Global Accelerator supported traffic while DNS still lived outside AWS. DNS later moved from Cloudflare to Route 53, bringing traffic routing and DNS management into the target AWS operating model.

Implementation

The work was sequenced by dependency and reversibility:

1. Build and validate the AWS network and access foundation.
2. Replicate servers with MGN and test the EC2 targets.
3. Establish RDS and migrate data through DMS.
4. Move media to S3 and place CloudFront in front of it.
5. Introduce load balancing and health checks.
6. Rehearse the cutover, verification, and rollback paths.
7. Move production traffic and continue monitoring the new environment.

CI/CD then automated the application build, frontend build, database migrations, S3 synchronization, and CloudFront invalidations across staging and production. This reduced the number of manual steps required for a release after the platform moved.

Results

• The primary infrastructure cutover was delivered within four months of joining the company.
• Annual infrastructure cost fell by approximately US$30,000 through consolidation, right-sizing, and moving media delivery to S3 and CloudFront.
• The migration established clearer compute, data, delivery, networking, and access boundaries for continued reliability work.

Lessons

The migration succeeded because the target was designed as an operating model, not just a new cloud account. Moving data and servers mattered, but the durable value came from separating concerns, controlling access, making releases repeatable, and leaving the team with infrastructure it could actually run.

The principle I carried forward is simple: choose the architecture the operating team can support, and make every cutover plan answer two questions—how will we verify it, and how will we get back?