LEARN. PRACTICE. GROW.Choose the migration unit
A fictional funds project has three elements: relational tables, reconciliation files, and servers running a legacy application. Choose tooling by the element and its requirements. DMS supports data migration between supported engines; schema conversion needs its own work and validation. DataSync handles files and objects. AWS Transform MGN, formerly Application Migration Service, handles server rehosting. Before the window, record versions, volumes, dependencies, owners, and acceptance criteria. A DMS premigration assessment can identify incompatible types. Resolve the finding and rehearse the transformation; a successful preliminary report does not demonstrate that the final result contains every business operation.
Read the lag before promising a window
A completed full load means the initial copy finished, not that subsequent changes have reached the target. CDC needs accessible source logs; increasing network capacity cannot recover purged binlogs when no usable copy remains. If capture follows the source but apply falls behind, investigate the target and its writes, including necessary indexes. In the teaching model, arrivals are 100 MB/s, apply is 140 MB/s, and backlog is 2400 MB: the net 40 MB/s gives 60 seconds. This constant-rate estimate excludes long transactions and validation. Measure real conditions before turning it into a downtime commitment.
Prove the data the business will use
Define acceptance before opening the target for writes. In a fictional batch, the team requires every selected movement, no unresolved discrepancy, and totals reconciled by date. DMS validation distinguishes pending, suspended, and mismatched records; zero failures is not zero outstanding work. Validation also consumes resources, so include it in capacity rehearsal and reserved time. For files, confirm the DataSync verification scope: checking transferred files does not prove the whole dataset. A destination-preservation option can retain an old file. Compare the required inventory against the items that were actually readable and migrated.
Rehearse files and servers as services
A file copy with correct bytes can still fail for the batch account. For NFS with preserved POSIX metadata, check UID, GID, and effective destination permissions; matching names are insufficient when numeric identities differ. In an MGN rehearsal, new changes go to staging and do not update the already launched test instance. Test authentication, certificates, connections, and processing as well as boot. If AD remains at the source, isolate the test so the clone cannot interfere with the production identity. Document untested dependencies and who decides on residual risk before accepting the service.
Decide the switch using evidence
Build a sequence with owners and decision points: suspend authorized ingestion and writes, obtain planned protection, finish synchronization, reconcile, switch routing, and validate the service. Details depend on the engine and design; there is no universal cutover command. For a partial migration, measure latency between components left apart. If that path alone makes the batch exceed its window, adding servers may not fix it. MGN Finalize cutover ends replication and removes replication resources, so it presupposes completed acceptance. For continuing recovery with failback, evaluate AWS DRS and that solution’s own requirements.
Prepare return after new writes
After production starts, the target can contain movements the source never received. Changing DNS does not transport them. In the workshop, the source knows identifiers 1 through 100 while the target has acknowledged through 103; returning without reconciliation loses visibility of three operations. Define how to preserve new acknowledgements, prevent competing writers, and verify restoration or a forward fix. The local model shows this difference and replication balance without representing a distributed transaction protocol. Give APS acceptance evidence, alerts, owners, and a rehearsed recovery plan. Reviewing counts is part of acceptance, not a complete integrity proof.
// Synthetic constant-rate teaching model; no AWS calls or production data.
function drain(backlog,arrivals,apply){
if(![backlog,arrivals,apply].every(x=>Number.isFinite(x)&&x>=0))throw Error('Non-negative finite rates required');
if(backlog===0)return 0;
return apply>arrivals?backlog/(apply-arrivals):null;
}
const source=new Set(Array.from({length:100},(_,i)=>i+1));
const acknowledged=Array.from({length:103},(_,i)=>i+1);
console.log(JSON.stringify({drainSeconds:drain(2400,100,140),noConvergence:drain(2400,100,90),frozenSeconds:Math.round(drain(2400,0,140)*100)/100,missingOnReturn:acknowledged.filter(id=>!source.has(id))}))Twenty-minute workshop: calculate drain time for 2400 MB with arrivals at 100 MB/s and apply at 140 MB/s. Repeat with apply at 90 MB/s and then with writes suspended. Expected: 60 seconds, no convergence, and about 17.14 seconds. Explain model limitations and identify operations 101, 102, and 103 that the source would lack in a fictional rollback.
Common pitfalls
Confusing full load with current CDC, ignoring skipped files, testing only boot, or promising DNS rollback after new writes. A copy and matching counts do not prove business behavior.
Related topics: Resilience, capacity, and recovery · Databases, replicas, and cache · Recovery: dependencies, capacity, and cost
Choose tooling by the element, confirm synchronization, and validate data and service before switching. Exercises are fictional; the local model does not measure AWS, guarantee RPO/RTO, or replace an authorized rehearsal.
Reference: SAA-C03 resilient architectures · SAA-C03