How to Migrate from DigitalOcean to AWS: A Comprehensive Guide

When hearing the phrase DigitalOcean to AWS migration, the first thing that often comes to mind is moving virtual machines and servers between the two cloud platforms. However, depending on the current environment that’s set up on DigitalOcean, it might extend to more than just this. 

DigitalOcean offers a variety of cloud services including Droplets, Volumes, Spaces, Managed Databases, Kubernetes, Load Balancers, and networking services. AWS provides equivalents for most of these capabilities, but the architecture, interconnectivity, security controls, and operational model are significantly different. 

So depending on which services you use on DigitalOcean and which migration strategy you decide for each workload, the details of the migration will differ.

A successful migration therefore requires two decisions:

1. What should be moved as-is?
2. What should be redesigned using an AWS-native service?

For example, a DigitalOcean Droplet can be migrated to Amazon EC2 as a lift-and-shift operation. But a different migration strategy (i.e. refactoring) that involves redesigning the app into a microservices architecture, might move the application totally or partially to ECS, EKS, and lambda.

This guide explains how to migrate the major DigitalOcean services to AWS, including practical examples, migration strategies, commands, architecture considerations, downtime reduction techniques, and post-migration validation.

1. DigitalOcean-to-AWS Service Mapping

The first step in preparing for the migration is to create an inventory of everything running in DigitalOcean. Then you can list the potential equivalent AWS services that can be used and correspond to each DigitalOcean service.

A typical mapping looks like this:

The important point is that there isn’t always a one-to-one mapping.

DigitalOcean’s relatively simpler model might not always have a direct AWS alternative service with exactly the same behavior. In that case, treat the migration as an opportunity to set up an AWS architecture that best matches each workload.

2. Start With a Complete DigitalOcean Inventory

The next step is to document every workload’s related specs and infrastructure resources. 

For every application, record:

• Droplet name
• Droplet size
• Operating system
• Region
• Public IP
• Private IP
• Attached Volumes
• CPU utilization
• RAM utilization
• Disk utilization
• Network traffic
• Open ports
• Firewall rules
• Running services
• Cron jobs
• Systemd services
• Environment variables
• Secrets
• SSL certificates
• DNS records
• Database connections
• Object-storage dependencies
• Container images
• Backups
• Monitoring
• External integrations

For example:

Application: ecommerce.example.com

DigitalOcean:

  Droplet: web-01

  Size: 4 vCPU / 8 GB RAM

  OS: Ubuntu 24.04

  Region: NYC

  Volume: 200 GB

Database:

  Managed PostgreSQL

  4 vCPU / 8 GB RAM

  150 GB storage

Storage:

  Spaces bucket: ecommerce-assets

Networking:

  Cloud Firewall

  Ports: 80, 443, 22

DNS:

  ecommerce.example.com

  www.example.com

Background jobs:

  cron

  Redis

Containers:

  Docker Compose

This inventory becomes the migration blueprint which you’ll evaluate and plan the migration destination accordingly.

3. Decide on the Migration Strategy

As we mentioned, a migration strategy can influence the decision of the destination AWS service to be used. Therefore, using the directly mapped AWS service corresponding to the DigitalOcean service might not always be the choice.

There are three common approaches.

Strategy 1: Rehost

Move the workload with minimal architectural changes.

For example:

DigitalOcean Droplet → Amazon EC2

This is usually the fastest approach.

It is appropriate when:

• You need a quick migration.
• The application is stable.
• You don’t want major application changes.
• You want to migrate first and modernize later.

Strategy 2: Replatform

Move the application but replace some infrastructure with managed AWS services.

For example:

DigitalOcean:

Droplet

   │

   ├── Application

   ├── PostgreSQL

   └── uploaded files

             ↓

AWS:

EC2

   │

   ├── Application

   │

   └── Amazon RDS PostgreSQL

Amazon S3

   └── uploaded files

This is often the best compromise.

You retain much of the existing application while reducing infrastructure-management responsibilities.

Strategy 3: Refactor

Redesign the application around AWS-native services.

For example:

                        ┌── CloudFront

                         │

Users ── Route 53 ── ALB ── ECS

                         │

                         ├── RDS/Aurora

                         │

                         ├── ElastiCache

                         │

                         └── S3

This can provide better scalability and availability but requires considerably more engineering effort.

4. Migrating DigitalOcean Droplets to AWS EC2

A DigitalOcean Droplet is essentially a virtual machine, and Amazon EC2 is the equivalent AWS service that’s typically the destination of migrating a virtual machine in a life-and-shift strategy.

There are two main approaches for implementing this:

Approach A — Rebuild the server

This is simply achieved by creating a new EC2 instance and installing the application components.

For example, suppose the DigitalOcean server runs:

Ubuntu

Nginx

PHP 8.3

Laravel

Instead of copying the entire machine, you could create:

EC2 Ubuntu / CentOS / Windows

    ↓

Install Nginx

    ↓

Install PHP

    ↓

Deploy Laravel

    ↓

Restore configuration

This produces a cleaner AWS architecture.

This is usually preferable when the application can be reproduced through:

• Ansible
• Terraform
• Cloud-init
• Docker
• Packer
• Configuration-management scripts

Approach B — Rehost the VM

If preserving the existing server is important, you can migrate the machine image.

AWS VM Import/Export supports importing VM images into EC2. The AWS workflow involves exporting the VM image, uploading it to Amazon S3, and importing it into EC2.

AWS Application Migration Service is another option for supported workloads and is specifically intended for lift-and-shift server migrations. AWS identifies it as the primary migration service for lift-and-shift migrations in its Migration Hub documentation.

Choosing the Correct EC2 Instance

Don’t automatically select an EC2 instance based on the DigitalOcean droplet CPUs and memory specs, but rather try to measure the actual utilization of the droplet to decide the application needs.

A 4-vCPU DigitalOcean Droplet isn’t necessarily equivalent to a particular 4-vCPU EC2 instance.

Measure:

• CPU utilization
• Memory utilization
• Network throughput
• Disk throughput
• Disk IOPS
• Application latency

For example, a server currently using:

4 vCPU

8 GB RAM

Average CPU: 20%

Average RAM: 45%

might not need a large EC2 instance.

Conversely, a server with:

4 vCPU

8 GB RAM

CPU: 90%

Disk I/O: high

may require a substantially different architecture.

5. Migrating DigitalOcean Volumes to Amazon EBS

DigitalOcean Volumes provide block storage attached to Droplets. The AWS equivalent is generally Amazon EBS.

A simple migration is:

DigitalOcean Volume

       ↓

Temporary backup/copy server

       ↓

AWS S3 or transfer mechanism

       ↓

Amazon EBS

       ↓

EC2 Mount

However, you should first determine what the Volume contains.

If it contains application files:

/var/www/uploads

EBS may be appropriate.

If it contains:

images

videos

user documents

backups

Amazon S3 is usually a better destination.

If it contains a shared filesystem used by multiple servers, consider Amazon EFS or another AWS file-storage service instead.

6. Migrating DigitalOcean Spaces to Amazon S3

DigitalOcean Spaces is S3-compatible object storage. DigitalOcean explicitly documents compatibility with the S3 API and AWS S3 tools/SDKs.

This makes Spaces one of the easier DigitalOcean services to migrate.

The target architecture is:

DigitalOcean Spaces

        │

        │ S3-compatible transfer

        ↓

Amazon S3

Option 1 — AWS DataSync

AWS DataSync supports DigitalOcean Spaces as an object-storage location and can transfer data between DigitalOcean Spaces and AWS storage.

This is particularly useful for large buckets.

Example:

Spaces:

photos-prod

    ├── users/

    ├── products/

    ├── invoices/

    └── backups/

              ↓

S3:

company-production-assets

    ├── users/

    ├── products/

    ├── invoices/

    └── backups/

DataSync can also perform integrity validation during transfers.

Option 2 — AWS CLI

Because Spaces supports the S3 API, S3-compatible tools can be used.

For example, you can configure an S3-compatible endpoint for DigitalOcean and then copy objects to AWS S3.

Conceptually:

aws s3 sync \

  s3://digitalocean-bucket \

  s3://aws-s3-bucket \

  –endpoint-url https://nyc3.digitaloceanspaces.com

The exact endpoint depends on your Spaces region.

Important considerations

Check:

• Bucket permissions
• Public/private objects
• Object metadata
• Content-Type
• Cache-Control
• Object ownership
• Lifecycle policies
• CDN configuration
• Application URLs

DigitalOcean Spaces uses an S3-compatible API, but compatibility isn’t identical to Amazon S3, so test applications that depend on provider-specific behavior.

7. Migrating DigitalOcean Managed PostgreSQL to Amazon RDS

This is one of the most important parts of the migration.

The target can be:

• Amazon RDS for PostgreSQL
• Amazon Aurora PostgreSQL-Compatible

AWS DMS supports migrations from self-managed PostgreSQL to RDS PostgreSQL and Aurora PostgreSQL. AWS also provides homogeneous migration capabilities using PostgreSQL-native tools.

A typical architecture is:

DigitalOcean Managed PostgreSQL

             │

             │ AWS DMS

             ↓

 Amazon RDS PostgreSQL

PostgreSQL migration with pg_dump

For smaller databases, a dump and restore can be straightforward.

On the source:

pg_dump \

  -h SOURCE_HOST \

  -U SOURCE_USER \

  -Fc DATABASE_NAME \

  > database.dump

Transfer the dump to AWS and restore:

pg_restore \

  -h RDS_ENDPOINT \

  -U TARGET_USER \

  -d DATABASE_NAME \

  database.dump

This approach is simple but usually requires a write freeze during the final migration.

PostgreSQL Migration With AWS DMS

For larger production databases, AWS DMS can reduce downtime.

The general architecture is:

             ┌───────────────┐

              │ DigitalOcean  │

              │ PostgreSQL    │

              └───────┬───────┘

                      │

                      │ Initial load

                      │

                      │ Change replication

                      ↓

              ┌───────────────┐

              │    AWS DMS    │

              └───────┬───────┘

                      │

                      ↓

              ┌───────────────┐

              │ RDS PostgreSQL│

              └───────────────┘

AWS DMS can perform full-load and ongoing replication for supported PostgreSQL migrations.

The migration sequence is:

1. Create the RDS database.
2. Configure networking.
3. Configure source PostgreSQL access.
4. Configure DMS.
5. Start full load.
6. Allow changes to replicate.
7. Monitor replication lag.
8. Stop application writes.
9. Wait for replication to catch up.
10. Change the application’s database endpoint.
11. Validate the application.
12. Resume writes.

This can reduce the final downtime to the cutover period.

8. Migrating DigitalOcean Managed MySQL

The same general model applies to MySQL.

DigitalOcean Managed MySQL

           │

           │

           ↓

       AWS DMS

           │

           ↓

RDS MySQL / Aurora MySQL

AWS provides migration workflows for MySQL to RDS MySQL and Aurora MySQL.

For smaller databases:

mysqldump \

  -h SOURCE_HOST \

  -u USER \

  -p \

  DATABASE > database.sql

Then:

mysql \

  -h RDS_ENDPOINT \

  -u USER \

  -p \

  DATABASE < database.sql

For production systems where downtime matters, use replication or AWS DMS.

9. Migrating Redis

DigitalOcean Redis workloads may need to move to:

• Amazon ElastiCache for Valkey/Redis
• Redis-compatible infrastructure running on EC2
• Another AWS caching architecture

Please note, AWS Valkey might be cheaper than Redis.

First determine whether Redis contains:

Disposable cache data

If Redis is only caching database queries, you may not need to migrate the data at all.

Simply:

Create new ElastiCache

       ↓

Deploy application

       ↓

Application repopulates cache

Persistent application state

If Redis contains:

• queues
• sessions
• counters
• persistent application state

then you need a proper migration strategy.

For example:

DigitalOcean Redis

       │

       ├── sessions

       ├── queues

       └── application state

              │

              ↓

       migration/replication

              │

              ↓

      AWS ElastiCache

Do not treat Redis as disposable until you have confirmed exactly what the application stores there.

10. Migrating DigitalOcean Kubernetes to Amazon EKS

DigitalOcean Kubernetes and Amazon EKS both run Kubernetes, but they are not identical environments.

The safest strategy is generally not to copy the Kubernetes cluster itself.

Instead:

DigitalOcean Kubernetes

          │

          │ Kubernetes manifests

          ↓

       Amazon EKS

          │

          ├── Deployments

          ├── Services

          ├── ConfigMaps

          ├── Secrets

          └── Ingress

Export or retrieve:

• Deployments
• StatefulSets
• Services
• ConfigMaps
• Secrets
• Ingress
• PersistentVolumeClaims
• CronJobs
• RBAC
• Helm values

Then adapt them for AWS.

Kubernetes storage

This requires particular attention.

DigitalOcean Persistent Volumes may need to become:

• Amazon EBS CSI volumes
• Amazon EFS
• S3

For example:

DigitalOcean PVC

       ↓

If block storage → EBS

If shared filesystem → EFS

If object data → S3

Don’t just recreate every DigitalOcean volume as an EBS volume.

11. Migrating DigitalOcean Container Registry to Amazon ECR

If applications use DigitalOcean Container Registry, Amazon Elastic Container Registry (ECR) is the natural AWS equivalent.

Example:

DigitalOcean Registry

       │

       ├── app:v1

       ├── app:v2

       └── app:v3

             ↓

          Amazon ECR

             │

             ├── app:v1

             ├── app:v2

             └── app:v3

You can pull the existing image:

docker pull registry.digitalocean.com/myregistry/myapp:v1

Tag it for ECR:

docker tag \

  registry.digitalocean.com/myregistry/myapp:v1 \

  AWS_ACCOUNT_ID.dkr.ecr.REGION.amazonaws.com/myapp:v1

Authenticate to ECR:

aws ecr get-login-password –region REGION |

docker login \

  –username AWS \

  –password-stdin \

  AWS_ACCOUNT_ID.dkr.ecr.REGION.amazonaws.com

Then push:

docker push \

  AWS_ACCOUNT_ID.dkr.ecr.REGION.amazonaws.com/myapp:v1

For CI/CD, update the pipeline so future builds go directly to ECR.

12. Migrating DigitalOcean Load Balancers

DigitalOcean Load Balancer configurations should generally be recreated using AWS Elastic Load Balancing.

Depending on the application, you can use:

• Application Load Balancer
• Network Load Balancer
• Gateway Load Balancer

For a normal HTTP/HTTPS web application:

Internet

   │

   ↓

Route 53

   │

   ↓

Application Load Balancer

   │

   ├── EC2

   ├── EC2

   └── EC2

Instead of pointing DNS directly to an EC2 instance, point it to the load balancer.

This also makes future Auto Scaling easier.

13. Migrating DigitalOcean DNS to Route 53

DigitalOcean provides domain and DNS management as part of its networking services.

The AWS equivalent is Amazon Route 53.

Before changing DNS, recreate:

• A records
• AAAA records
• CNAME records
• MX records
• TXT records
• SPF
• DKIM
• DMARC
• Verification records
• CAA records
• Subdomains

For example:

DigitalOcean DNS

example.com

www.example.com

api.example.com

mail.example.com

becomes:

Route 53 Hosted Zone

example.com

 ├── www

 ├── api

 ├── mail

 └── …

Lower DNS TTL before migration

Several days before the cutover, reduce the TTL.

For example:

Before:

TTL = 3600 seconds

Migration:

TTL = 60 seconds

Then change the records to AWS.

After the migration is stable, increase the TTL again.

14. Migrating DigitalOcean Floating IPs

DigitalOcean Floating IPs provide static addresses that can be assigned to Droplets.

The AWS equivalent is generally an Elastic IP, although the preferred AWS architecture is often to put applications behind a load balancer rather than depend on a single public IP.

Instead of:

DNS

 │

 ↓

Static IP

 │

 ↓

One server

prefer:

DNS

 │

 ↓

ALB

 │

 ├── EC2

 ├── EC2

 └── EC2

This eliminates a single server as a point of failure.

15. Migrating DigitalOcean VPC Networking

DigitalOcean VPCs provide private networking between resources.

AWS provides considerably more networking functionality through Amazon VPC.

A production AWS VPC commonly contains:

                    Internet

                        │

                  Internet Gateway

                        │

             ┌──────────┴──────────┐

             │                     │

       Public Subnet          Public Subnet

             │                     │

            ALB                   NAT

             │

       ┌─────┴─────┐

       │           │

 Private Subnet  Private Subnet

       │           │

      EC2         EC2

       │

       ↓

      RDS

A basic production design often includes:

• VPC
• Public subnets
• Private application subnets
• Private database subnets
• Internet Gateway
• NAT Gateway
• Route tables
• Security Groups
• Network ACLs where appropriate

16. Migrating DigitalOcean Cloud Firewalls

DigitalOcean Cloud Firewalls are stateful network firewalls for Droplets.

AWS primarily uses:

• Security Groups
• Network ACLs

Security Groups should normally be the first layer you use for EC2.

For example, instead of:

Allow:

22

80

443

5432

from everywhere, create application-specific rules.

Web server

Inbound:

80  ← Internet

443 ← Internet

22  ← Admin IP/VPN only

Database

Inbound:

5432 ← Application Security Group

17. Migrating SSL/TLS Certificates

If certificates currently exist on DigitalOcean servers, decide whether AWS should terminate TLS.

A typical architecture is:

Internet

   │ HTTPS

   ↓

Application Load Balancer

   │

   │ HTTP/HTTPS

   ↓

EC2

Use AWS Certificate Manager for certificates associated with AWS services such as Application Load Balancers.

This removes certificate-renewal tasks from individual servers.

18. Migrating DigitalOcean App Platform

If your application currently runs on DigitalOcean App Platform, there may not be a single AWS replacement.

Choose based on how the application works.

Containerized web application

Consider:

Amazon ECS + Fargate

Route 53

   ↓

ALB

   ↓

ECS/Fargate

   ↓

RDS

Kubernetes application

Consider:

Amazon EKS

Route 53

   ↓

ALB

   ↓

EKS

Event-driven application

Consider:

AWS Lambda

API Gateway

     ↓

Lambda

     ↓

DynamoDB/RDS/S3

Traditional server application

Use:

EC2

ALB

 ↓

EC2

19. Migrating Backups

Backups should be migrated separately from production data.

DigitalOcean backups may be useful for rollback during the migration, but they aren’t necessarily your long-term AWS backup strategy.

For AWS, consider:

• EBS snapshots
• AWS Backup
• RDS automated backups
• RDS snapshots
• S3 versioning
• S3 lifecycle policies
• Cross-region replication

For example:

RDS

 │

 ├── Automated backups

 ├── Manual snapshots

 └── AWS Backup

For S3:

S3

 ├── Versioning

 ├── Lifecycle

 └── Replication

20. Migrating Monitoring

Recreate monitoring in Amazon CloudWatch.

Monitor:

EC2

• CPU
• Network
• Disk
• Status checks

RDS

• CPU
• Connections
• Free storage
• Read/write latency
• IOPS
• Replication

ALB

• Request count
• HTTP errors
• Target health
• Response time

Application

Use:

• CloudWatch Logs
• CloudWatch Metrics
• CloudWatch Alarms
• AWS X-Ray where appropriate
• OpenTelemetry-compatible observability tools

21. Secrets and Environment Variables

DigitalOcean applications may currently have secrets such as:

DATABASE_URL

REDIS_URL

API_KEY

STRIPE_SECRET

JWT_SECRET

SMTP_PASSWORD

Do not simply place all of them into EC2 environment files.

AWS provides:

• AWS Secrets Manager
• Systems Manager Parameter Store
• IAM roles

For example:

Application

     │

     ↓

Secrets Manager

     │

     ├── DB password

     ├── API key

     └── OAuth secret

This also makes secret rotation and access control easier.

22. A Complete Example: Migrating a Laravel Application

Consider a DigitalOcean application with:

Droplet

 ├── Nginx

 ├── PHP/Laravel

 ├── Queue workers

 └── Cron

Managed PostgreSQL

Spaces

 └── User uploads

Redis

 └── Cache + queues

Load Balancer

DNS

A good AWS target architecture would be:

                        Route 53

                            │

                            ↓

                     CloudFront

                            │

                            ↓

                           ALB

                            │

                  ┌─────────┴─────────┐

                  ↓                   ↓

               EC2/ECS             EC2/ECS

                  │                   │

                  └─────────┬─────────┘

                            │

                    ┌───────┼────────┐

                    ↓       ↓        ↓

                   RDS   ElastiCache S3

                    │

                    ↓

               PostgreSQL

Migration sequence:

Step 1

Create AWS networking.

Step 2

Create RDS PostgreSQL.

Step 3

Start database migration.

Step 4

Create S3 bucket.

Step 5

Copy Spaces objects to S3.

Step 6

Create ECR repository.

Step 7

Push application image to ECR.

Step 8

Create EC2 or ECS infrastructure.

Step 9

Configure Secrets Manager.

Step 10

Deploy application.

Step 11

Point the application at RDS.

Step 12

Validate application behavior.

Step 13

Lower DNS TTL.

Step 14

Perform final database synchronization.

Step 15

Switch DNS to AWS.

Step 16

Monitor.

Step 17

Keep DigitalOcean available for rollback.

23. Testing Before Cutover

Create a formal migration test plan.

Infrastructure

Test:

• EC2 availability
• Load balancer
• Security Groups
• NAT
• DNS
• TLS

Application

Test:

• Login
• Registration
• Checkout
• Search
• File uploads
• File downloads
• Email
• Background jobs
• Webhooks
• API integrations

Database

Test:

• Row counts
• Critical tables
• Indexes
• Stored procedures/functions
• Permissions
• Transactions

Storage

Test:

• Object count
• Object sizes
• Permissions
• Metadata
• Application access

For example:

DigitalOcean:

users = 1,250,342

AWS:

users = 1,250,342

Then compare important business tables rather than relying solely on infrastructure-level success messages.

AWS notes that some homogeneous DMS migrations do not provide built-in data validation, so application and database-level validation remains important.

24. Common Migration Mistakes

Mistake 1: Treating AWS like DigitalOcean

AWS isn’t simply “DigitalOcean with more services.”

You need to understand:

• VPCs
• IAM
• Security Groups
• Subnets
• Route tables
• Availability Zones
• Load balancers
• IAM roles

Mistake 2: Migrating servers without understanding dependencies

A Droplet may depend on:

Droplet

 ├── PostgreSQL

 ├── Redis

 ├── Spaces

 ├── SMTP

 ├── DNS

 └── External API

Moving only the Droplet doesn’t move the application.

Mistake 3: Forgetting background workers

Web traffic may work while:

queues

cron

scheduled jobs

workers

are broken.

Mistake 4: Forgetting object-storage URLs

Applications frequently store URLs such as:

https://bucket.nyc3.digitaloceanspaces.com/image.jpg

After migration, these may need to become:

https://cdn.example.com/image.jpg

or an S3/CloudFront URL.

Mistake 5: Changing architecture and cloud provider simultaneously

If your DigitalOcean application works perfectly, migrating it and completely rewriting it at the same time greatly increases risk.

A safer approach is:

Phase 1:

DigitalOcean → AWS with minimal changes

Phase 2:

AWS optimization

Phase 3:

Modernization

25. Final Checklist

Before shutting down DigitalOcean, verify:

Compute

• All Droplets migrated
• CPU/RAM sizing validated
• Services running
• Cron jobs migrated
• Workers migrated
• SSH/admin access tested

Database

• Database migrated
• Row counts validated
• Indexes validated
• Users/permissions recreated
• Replication tested
• Backup configured
• Application tested

Storage

• Spaces copied
• Object counts compared
• Object metadata checked
• Permissions tested
• Application URLs updated
• CDN tested

Networking

• VPC created
• Subnets created
• Routes configured
• Security Groups configured
• Load balancer tested
• TLS configured

DNS

• DNS zone recreated
• MX records migrated
• TXT records migrated
• SPF/DKIM/DMARC checked
• TTL reduced
• AWS endpoints tested

Operations

• CloudWatch configured
• Alarms configured
• Logging enabled
• Backups configured
• IAM reviewed
• Secrets migrated

Cutover

• AWS environment tested
• Database synchronized
• Storage synchronized
• Rollback plan tested
• DNS switched
• Application monitored
• DigitalOcean retained temporarily

Conclusion

Migrating from DigitalOcean to AWS should not be approached as simply copying Droplets into EC2. The best migration separates data, compute, networking, storage, databases, DNS, and application services, then maps each workload to the appropriate AWS architecture.

The most important principle is to migrate state carefully and applications independently. Databases and persistent storage deserve the most attention because they determine how much downtime is required. AWS DMS can be particularly useful for supported PostgreSQL and MySQL migrations where continuous replication is desirable. 

For large environments, a phased migration—discover → build AWS → replicate data → deploy → test → cut over → optimize—is generally safer than attempting a single large migration event.