Your legacy system still runs the business, which is exactly why moving it feels risky. A failed weekend cutover can mean lost orders, angry customers and a rushed rollback.
To migrate a legacy application to the cloud without downtime, run the old and new environments side by side, keep the data in sync with continuous replication, and move traffic gradually with DNS or a load balancer while keeping a tested rollback path. Plan the migration in small, reversible steps rather than one big switch.
Why do cloud migrations cause downtime?
Downtime usually comes from three places: the database (data has to stop changing while it is copied), hidden dependencies (a cron job, a file share or a hard-coded IP address nobody documented) and the cutover itself (DNS caching, sessions and configuration that differ between environments). A good plan addresses each of these before moving any traffic.
Step 1: Assess what you actually have
Start with an inventory. List servers, databases, scheduled jobs, file storage, third-party integrations, email sending, certificates and every place configuration lives. Talk to the people who run the system day to day; they know about the script that runs on the first of every month.
- Map dependencies between components and external systems.
- Record current performance and error baselines so you can compare after migration.
- Identify data that must stay in a specific country or region for legal or contractual reasons.
- Decide on acceptable risk: is a few seconds of read-only mode acceptable, or must writes never pause?
Step 2: Choose a migration strategy
AWS and others describe common approaches as the "Rs" of migration. The most relevant ones for a legacy application are below.
| Strategy | What it means | Good when | Watch out for |
|---|---|---|---|
| Rehost ("lift and shift") | Move servers largely as they are, for example with AWS Application Migration Service | You need to leave a data centre quickly | Carries existing inefficiencies into the cloud |
| Replatform | Small changes to use managed services, such as moving the database to Amazon RDS | You want less operational work without a rewrite | Needs testing for version and configuration differences |
| Refactor | Re-architect parts of the application for the cloud | The system blocks growth or is costly to change | Longest and most expensive route |
| Retire or retain | Switch off unused parts or keep some on-premises for now | Parts of the system are unused or not ready | Hybrid connectivity needs planning |
Many successful migrations combine them: rehost or replatform first to get out of the old environment, then refactor gradually using the strangler fig pattern, where new services take over features one at a time behind the same entry point.
Step 3: Build the target environment as code
Define networking, servers or containers, databases and permissions with infrastructure as code such as Terraform or AWS CloudFormation. This makes the new environment repeatable, reviewable and easy to rebuild for rehearsals. Set up a CI/CD pipeline at the same time; our guide to setting up a CI/CD pipeline explains the basics.
Step 4: Keep data in sync with replication
The database is where zero downtime is won or lost. Instead of a single dump and restore, use continuous replication:
- AWS Database Migration Service (DMS) can perform a full load and then use change data capture to keep the target in sync while the old system stays live.
- Native replication, such as MySQL binary log replication or PostgreSQL logical replication, can do the same for supported versions.
- Files and uploads can be synced to Amazon S3 with tools such as AWS DataSync, followed by a final incremental sync.
Validate the copied data with row counts and checksums on key tables before you trust it.
Step 5: Rehearse, then cut over gradually
Run at least one full rehearsal in a non-production copy. Then plan the real cutover:
- Lower DNS TTL values a few days in advance so changes propagate quickly.
- Run the new environment against replicated data and smoke-test it.
- Move a small share of traffic using Route 53 weighted routing or a load balancer, and watch errors and latency.
- Increase traffic in steps while monitoring closely.
- When writes move to the new database, stop replication from the old one and, if possible, set up reverse replication so rollback does not lose data.
These are the same ideas behind canary and blue-green releases, covered in our guide to zero-downtime deployments.
Cloud migration readiness checklist
| Item | Ready? |
|---|---|
| Full inventory of servers, jobs, integrations and data | Yes / No |
| Performance and error baselines recorded | Yes / No |
| Target environment defined as code | Yes / No |
| Continuous data replication running and validated | Yes / No |
| Monitoring and alerts in the new environment | Yes / No |
| Rehearsal completed and issues fixed | Yes / No |
| DNS TTLs lowered | Yes / No |
| Written rollback plan with an owner and trigger criteria | Yes / No |
| Stakeholders and support team informed | Yes / No |
What happens after the migration?
Keep the old environment available for a defined period in case you need to roll back, then decommission it so you are not paying twice. Review the new setup for rightsizing and cost; see AWS cost optimization: 12 ways to cut your cloud bill. Finally, use the cleaner platform as a base for gradual modernisation.
Key takeaways
- Most downtime comes from the database, hidden dependencies and the cutover, so plan for each.
- Use continuous replication and gradual traffic shifting rather than a single big switch.
- Rehearse the migration and keep a tested rollback path until the new system is proven.
Planning to move a legacy system to the cloud? Get a DevOps and cloud migration quote from AppifyDevs, or read about our delivery approach on the how we work page.