What zero downtime means
Zero downtime means visitors keep using the site while the data moves. It does not mean no pause at all. Change data capture is not real-time: AWS documents that replication latency varies, has no SLA, and can reach several minutes or longer, so the cutover needs a short, planned pause in writes.
AWS Database Migration Service runs the pattern as a full load of existing data followed by change data capture, reading the source's transaction logs.
AWS's documentation on ongoing replication(opens in a new tab) describes the latency and how change capture works.
Replicate: full load, then keep the target current
Verify: compare the two sides row by row
Cut over: pause writes, switch, confirm
Keep rollback until the new system proves itself
Server migration without data loss: replicate, then verify
Replication does the copying. Verification earns the cutover. Validation in AWS DMS compares each source row with its target row after the full load and reports mismatches. It needs a primary key or unique index on each table, and its queries add load on both databases and the network.
AWS's data validation documentation(opens in a new tab) lists what it compares and where it stops.
Rows that change continuously cannot be validated, and AWS suspends them. So run checks while replication runs, then run the final comparison after writes pause. Validation-only tasks can give a full-load comparison just before the cutover.
A clean restore is not verification. Teams that treat a clean restore as proof are the teams that discover a missing week of records a month later.
- Row counts per table.
- Checksums on critical ranges.
- Application spot checks, such as whether the newest order exists on both sides.
AWS migration process: the cutover is a decision
Lower the DNS TTL before the window. Route 53 advises a shorter value first, such as 300 seconds, and raising it after the new settings are confirmed. Pause writes at the switch, let replication catch up, run the final comparison, then point traffic at the new system. Make the go or no-go call against a written checklist.
Route 53's TTL documentation(opens in a new tab) explains why a long TTL slows a change.
If verification fails at the gate, the cutover waits for another night. Waiting is the process working, not the team failing.
- Replication latency is back to normal, checked just before the window opens.
- Final comparison after the write pause: no mismatches.
- DNS TTL lowered ahead of the window.
- Rollback path written down and tested.
- A named person makes the go or no-go call.
Zero data loss migration: keep rollback until proven
Choose the rollback pattern before the window. A read-only old system is simple, but writes made after the cutover exist only on the new side. Reverse replication keeps the old system current. AWS DMS supports it with a second, change-only task, though AWS warns it is not multi-master and has no conflict resolution.
AWS documents bidirectional replication(opens in a new tab) and its limits.
Prove the new side with error rates, completed jobs, and a backup restore test on the new system. Take a final backup before decommissioning the old one.
- Read-only old system: simple, but writes made after the cutover exist only on the new side.
- Reverse replication: keeps the old system current, so a rollback loses nothing, at the cost of more moving parts.
Where this comes from
Our About page records multiple production server and database moves with verified parity every time, and the migration package covers EC2, RDS, S3 and Route 53. The steps here are the general pattern. Engines, tools and traffic differ, so a plan for your system starts with its data volume, service count and downtime tolerance.
The website migration service page lists what the infrastructure package covers.
Questions about zero downtime migration
Is zero downtime really possible?
For visitors, usually yes. For writes, plan a short pause at cutover. Per AWS, change data capture is not real-time and latency can reach several minutes or longer, so the final switch needs a controlled pause while replication catches up.
How do I check the new database matches the old one?
Compare every row, not just counts. AWS DMS validation compares each source row with its target row and reports mismatches. It needs a primary key or unique index, and it cannot validate rows that change continuously, so run the final comparison after writes pause.
Why lower the DNS TTL before cutover?
A long TTL slows the effect of a DNS change because resolvers cache the old answer. Route 53 advises a shorter value first, such as 300 seconds, and raising it once the new settings are confirmed.
Can I roll back after the cutover?
Yes, if you chose the path in advance. With a read-only old system you get a restore point but lose later writes. Reverse replication keeps the old system current, but AWS notes it is not multi-master and has no conflict resolution.
How long should I keep the old system?
Until the new system has proved itself with error rates, completed jobs and a backup restore test. Then take a final backup before decommissioning the old one.