Cloud migration cutovers
Stop background writers before the final data sync
A quiet website can still have an active database. Include jobs, callbacks and queued work in the cutover fence.
In this article
Build the write inventory
List every process that can change the migrating data. For each, record its identity, trigger, target and shutdown or fencing mechanism.
A scheduled invoice job may run in a different environment from the web application. A partner webhook may continue arriving after users see a maintenance page. These paths need their own handling.
Decide whether incoming work is rejected, durably held or drained before the switch. If it is held, preserve operation identity so release after migration does not create duplicate effects.
Apply the fence deliberately
Disable or fence the old writers using controls appropriate to the service. Confirm the controls from observed behaviour, not only configuration state.
A process can already hold work in memory when its schedule is disabled. Wait for in-flight work to complete or stop it under a documented recovery procedure.
Record unresolved operations with their identities and known outcomes. A timeout does not establish whether an external request or database transaction completed.
Establish the final checkpoint
After old writes are prevented, identify the source position required for the target to be complete. Use the migration tool and database's supported checkpoint semantics.
{
"cutoverId": "migration-example-12",
"oldWritersFenced": true,
"inFlightWorkResolved": true,
"sourceCheckpoint": "platform-specific-position",
"targetCheckpointVerified": false,
"newWritesEnabled": false
}This is an illustrative run record. The booleans must be backed by evidence and an accountable operator, not set automatically because a timer elapsed.
Wait for the required changes to apply and reconcile selected business records and totals. Check file or object transfers separately if they are not part of the database replication path.
Enable one authoritative path
Point the application and background workers at the target under the agreed sequence. Ensure old workers cannot resume writing if a host restarts or a scheduler is re-enabled.
Run a controlled business transaction and verify its downstream result before releasing held work broadly. Observe retries and duplicate handling as queues resume.
Keep the source protected during the observation period. Its continued availability may support recovery, but it must not become an accidental second writer after the target has accepted new business changes.
Primary sources
AWS DMS: ongoing replicationReferences checked 11 September 2026.