DigitalOcean to AWS: the service map, the cutover, and who runs it.

IWhy teams move off DigitalOcean

Nobody leaves DigitalOcean because it is hard to use. They leave because its simplicity becomes a limit on scale, services or the buyers they can sell to.

Scale. Droplet sizes, GPU options and specialised hardware are narrower than AWS (no Graviton, no Inferentia or Trainium, fewer large-memory types). Autoscaling is basic next to EC2 Auto Scaling and ECS service scaling, and DigitalOcean runs far fewer Regions than AWS's 30-plus.

Services. DigitalOcean keeps a small, curated catalog: Droplets, App Platform, Managed Databases (PostgreSQL, MySQL, Valkey, MongoDB, Kafka, OpenSearch), Spaces, DOKS, Load Balancers and Functions. That covers a classic web app. A data warehouse, managed streaming or ETL, fine-grained IAM or a long tail of managed primitives means running it yourself on a Droplet.

Enterprise and compliance. As teams sell upmarket, security reviews ask for data residency in specific Regions, private connectivity (PrivateLink, Direct Connect), org-level guardrails (AWS Organizations, Control Tower) and a broad set of compliance attestations. A blocked enterprise deal is a common trigger.

IIWhat each DigitalOcean piece becomes on AWS

The data and storage services map almost one-to-one. The real decision is how much control you want at the compute layer. The full row-by-row table is further down.

Compute. Droplets become Amazon EC2, or Amazon Lightsail if you want the closest fixed-price, simple-console experience. App Platform becomes Amazon ECS on Fargate. For a Heroku-style "image in, URL out" setup, ECS Express Mode creates the Fargate service, load balancer and scaling for you. (App Runner closed to new customers on April 30, 2026.) DOKS becomes Amazon EKS.

Data. DigitalOcean Managed PostgreSQL or MySQL becomes Amazon RDS or Aurora. Both ends speak the same open-source engine, so queries and ORM code do not change. Managed Valkey or Redis becomes ElastiCache with a connection-string change. Managed MongoDB maps to Amazon DocumentDB, or Atlas if you need full MongoDB feature parity.

Storage and glue. Spaces is S3-compatible, so it becomes Amazon S3 with a new endpoint and credentials, and the Spaces CDN becomes CloudFront. Load Balancers become an ALB or NLB, Functions become Lambda, DNS moves to Route 53, TLS comes from AWS Certificate Manager, monitoring moves to CloudWatch, env-file secrets move to Secrets Manager, and Droplet cron jobs become EventBridge Scheduler rules.

IIIThe cutover: copy data early, switch in a short window

Compute, networking and buckets can be built and tested without touching production. The database cutover and the final object copy are the only moments that touch live data.

Database. If your DigitalOcean database user can use logical replication, AWS Database Migration Service (DMS) can do a full load into RDS and then stream ongoing changes (CDC), so at cutover you switch to an already-current copy. Check this early. If it cannot, use pg_dump and pg_restore (or mysqldump) inside a maintenance window, and time a test restore first so you know the window.

Spaces to S3. Because Spaces is S3-compatible, rclone or the AWS CLI can bulk-sync buckets into S3 ahead of time. For large datasets, AWS DataSync gives a managed, parallel transfer. Run a final incremental sync at cutover.

The switch. Lower the DNS TTL a day ahead. Then: maintenance mode, final database sync or restore, final Spaces sync, swap the connection string and S3 endpoint, point traffic at the new service, update Route 53, check that writes land in RDS and uploads land in S3, and leave maintenance mode. Keep DigitalOcean running as a fallback for a short, defined window.

IVThe step-by-step migration

The sequence a partner runs. Most of it happens in parallel and none of it touches production until the cutover.

• Assess: Inventory every Droplet, App Platform app, database, Spaces bucket, DOKS cluster, Load Balancer, Function, cron job and DNS zone. Pick the compute target and RDS or Aurora. Build a before and after cost model with the AWS Pricing Calculator.
• Landing zone: Accounts, VPC, subnets, security groups, IAM roles, ECR and Secrets Manager. Do this first; bolting on networking and IAM later is where projects slip.
• Compute: Build EC2, the ECS services or the EKS cluster. Containerise anything that ran as a bare Droplet process or App Platform app.
• Data and storage: Create RDS or Aurora and ElastiCache, restore the schema, create S3 buckets and CloudFront, and rebuild cron jobs as EventBridge Scheduler rules.
• Sync and test: Start DMS (or rehearse the dump and restore) and bulk-sync Spaces. Deploy the new stack against the synced data and run the full test suite, background jobs and asset delivery.
• Cut over: Run the switch above in a low-traffic window.
• Optimise and decommission: Right-size, add autoscaling, apply a Savings Plan once usage is stable, check alarms and backups. Then actually delete the Droplets, databases and Spaces, or you pay twice.

VGotchas that turn a clean migration messy

Most DigitalOcean to AWS migrations that go badly fail for a small, repeatable set of reasons.

• AWS has more to configure: A Droplet is a VM you SSH into. The AWS equivalent needs a VPC, subnets, security groups, IAM roles and a load balancer before it serves traffic. Budget for the landing zone.
• Spaces to S3 is API-compatible, not identical: Bucket policies, ACLs, CORS rules, signed-URL settings and encryption defaults do not carry over. S3 Block Public Access is on by default, so public Spaces assets can return 403 after cutover. Recreate every policy on purpose.
• Database SSL and connection settings: RDS wants its own SSL mode and CA bundle, and connection limits scale with instance class. Most "will not connect" issues after cutover are sslmode and certificate settings. Test them before the window.
• DOKS to EKS is a rebuild: Manifests and Helm charts carry over, but IAM roles for service accounts, the registry (to ECR), the ingress controller, the storage (CSI) driver and the autoscaler all need re-wiring.
• Cron jobs do not move themselves: Every schedule on a Droplet or App Platform job has to be rebuilt in EventBridge Scheduler. Inventory them in the Assess step.
• Forgetting to shut DigitalOcean down: Keep it as a fallback for a defined short window, then delete it.

VIWho runs the move, and who can fund it

AWS asks you to own more than DigitalOcean did. That extra surface is why many teams have a partner run the migration.

A vetted AWS partner can build the landing zone, move compute and data, run the cutover and hand you a documented setup, or operate it for you afterwards.

Partner-filed funding: the AWS Migration Acceleration Program (MAP) helps offset initial migration costs. Your matched partner files it when the migration qualifies and AWS approves. For startups this is typically $50K to $150K. Depends on the workload; AWS approves. MAP is built for migrations with meaningful ongoing AWS spend, so many small DigitalOcean workloads will not qualify. The partner checks before filing.

AWS Activate: you apply yourself. Activate Founders gives self-funded startups $1,000 to start, up to $5,000. Activate Portfolio gives up to $200,000 with the Org ID from your VC, accelerator or angel group, if it is an Activate Provider. A consulting partner cannot file Activate for you.