Context
A database migration can copy its initial dataset successfully and still fail before cutover. While the application continues writing, AWS Database Migration Service must capture and apply ongoing changes. If the source removes logs that replication still needs, restarting the task may not recover the missing history. A successful migration therefore needs a retention budget, a verified checkpoint, and an application acceptance plan.
Understand the moving recovery window
AWS DMS change data capture uses source-engine logging mechanisms to collect ongoing changes. The source requirements and supported starting points differ by database engine. AWS explicitly notes that CDC latency varies with workload, network conditions, replication resources, target capacity, and data characteristics. Review the linked service documentation alongside the relevant source-engine requirements; do not treat “replicating” as a promise of immediate consistency.
Source logs form a moving window. New changes arrive at one end while retention policies or storage pressure remove older history at the other. A paused or slow migration consumes that window. The important question is whether DMS can still read every change after its durable position when the task resumes, not whether the source currently has some logs available.
An illustrative overnight interruption
Consider a migration that pauses during a network incident. The team restores connectivity the following morning, but the source's log policy has already removed changes the task needs. The initial full load remains visible in the target, making the database look nearly complete. Switching the application now would risk silently missing the intervening updates.
Capture the task state, last known processing position, error messages, and source log availability before changing anything. Establish whether the required history still exists. Do not repeatedly restart the task or invent a later starting point merely to clear the error. Skipping a gap is a data-loss decision that needs explicit reconciliation or a new load strategy.
Build a retention budget
Estimate the longest credible interruption, including detection, investigation, approval, and catch-up. Add the time needed to perform the intended migration steps and a margin supported by workload evidence. Retention must cover the migration's operational reality rather than only the normal delay observed during a quiet test.
Check the storage cost of that retention using representative write activity. A time-based policy can still create substantial growth during a bulk update or import. Identify who monitors the source's log storage and what action is safe when capacity approaches its limit. Avoid allowing an emergency cleanup script to delete the exact history the migration depends on.
Distinguish capture delay from apply delay
Investigate the stage at which progress falls behind. The source can generate changes faster than they are read, or the target can apply them slower than they arrive. Those cases need different remedies. Record the source workload, replication resource utilisation, target write behaviour, and task logs over the same interval.
Do not increase replication capacity automatically without identifying the limiting stage. A target index, long transaction, lock, or constrained write path can dominate the delay. Test one change at a time and compare progress against the incoming workload. A backlog that briefly shrinks during a quiet period may still grow during the production peak.
Preserve checkpoint and task context
Retain the configuration needed to explain the task's scope: table selection, transformations, endpoint settings, source version, and target version. Record the supported restart procedure and the position information relevant to that source. A checkpoint without the corresponding task context can be difficult to use correctly.
Test a controlled pause and resume while source writes continue. Confirm that changes made during the pause reach the target and that the task catches up within the planned window. Use identifiable test records and updates, including deletion where it belongs to the migration scope. This exercise is more useful than proving that a task can merely return to a running state.
Plan a bounded cutover
Define how new writes will be stopped or redirected, how final changes will be observed, and which application checks must pass before users reach the target. A low latency metric is supporting evidence, not a substitute for validating the selected data population.
Prepare a rollback boundary. Once the target accepts new writes, reverting traffic to the old source can create another divergence problem. Decide beforehand whether rollback is possible through routing alone or requires reconciliation. Keep the source protected from accidental writes after cutover, and ensure scheduled workers cannot continue updating the old database.
Validate data and application behaviour
Compare counts and representative business relationships, then inspect transactions near the transition. Include high-value tables, recent updates, and known edge cases. If transformations intentionally change the target representation, validate the intended business equivalence rather than expecting every byte to match.
Run application reads and controlled writes against the target with the intended production identity. Confirm schema compatibility, sequences or identity generation, constraints, and required extensions or database features. A migration can preserve rows while missing an application dependency that was never represented in the table data.
Quick diagnostic map
| Evidence | Interpretation | Next check |
|---|---|---|
| Task cannot resume | Required history unavailable | Inspect source logs |
| Capture falls behind | Source-side bottleneck candidate | Compare capture progress |
| Apply falls behind | Target-side bottleneck candidate | Inspect target writes |
A focused operator exercise
Choose a small table with identifiable inserts, updates, and deletes, then run a representative migration task in a test environment. Pause replication while the source continues changing. Record the checkpoint and source-history availability. Resume using the supported procedure and verify that every selected change reaches the target without inventing a later start position.
Observe source capture and target apply progress separately during the catch-up. Introduce a controlled target slowdown and compare its evidence with the earlier paused-source case. This gives operators examples of two different delay patterns and prevents a generic instruction to increase replication resources whenever lag rises. Keep source workload and test timing in the same record.
For the cutover rehearsal, stop test writes through the intended application control, verify the final selected state, switch the application, and execute a controlled transaction. Explain the rollback boundary after that transaction. The acceptance receipt should identify any unresolved data difference and the remaining source-history window, so a migration decision is based on completeness rather than a running-task label.
Give operations a clear stop condition
Document conditions that halt the migration: unavailable source history, unexplained validation differences, sustained delay beyond the retention budget, or an untested rollback path. Give the migration owner a concise evidence record and a decision time, so a pressured release call does not become the first discussion of data completeness.
Clouvenix can help establish the retention budget, observe capture and apply stages, and rehearse the final cutover. The aim is a migration whose remaining change history is understood and whose acceptance rests on data and application evidence.
Explore Clouvenix database migration validation for implementation and operational handover.