Memory hook: Discover together, move deliberately, reconcile before retirement.
Must remember
Inventory business services and their technical dependencies, including batch jobs, shared files, identity, licensing, network allow lists and hidden database consumers. Group tightly coupled components into migration waves or provide a temporary connectivity strategy. Prioritize using business value, risk, readiness and dependency complexity, not only server size.
Choose among retain, retire, rehost, relocate, repurchase, replatform and refactor. A deadline-driven data-center exit may favor rehost before selective modernization; a license or engine limitation may require a different path. AWS Application Migration Service supports server rehosting; database migration needs its own schema/application/data plan. Service availability and source support must be checked for the actual environment.
For databases, separate schema conversion from data movement. DMS supports full load and CDC for supported engines; conversion tooling addresses compatible schema/code transformations but cannot guarantee every stored procedure or application query behaves identically. Assess data types, encoding, constraints, sequences, large objects and engine-specific features. Validate counts and business totals as well as transport status.
Cutover sequence: prepare target and recovery plan, load baseline, capture changes, reconcile, control source writes, drain the replication gap, switch clients, validate business behavior and monitor. Rollback must account for writes accepted at the new target. Keep the source only as long as its defined rollback/compliance role requires, then retire credentials, replication jobs and temporary connectivity.
DataSync moves supported file/object data and helps recurring transfer; Transfer Family exposes managed transfer protocols; Storage Gateway supports ongoing hybrid access patterns. Pick by application protocol and operating requirement. A physical-transfer solution may be inappropriate or unavailable to new customers; verify current eligibility and lead time rather than choosing it solely because a dataset is large.
A strangler approach moves selected capabilities behind controlled routing while the legacy system remains. Use an anti-corruption layer to isolate old data/contracts, decide authoritative ownership and reconcile events. The transactional outbox pattern can reduce the risk of committing database state without its corresponding event; consumers still need idempotence. A distributed saga uses local transactions and compensating actions where a single global transaction is unsuitable. Compensation is a business action, not a time machine that undoes all side effects.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Short exit deadline with compatible servers | Rehost with dependency-aware waves and later optimization. |
| Low-downtime supported DB migration | Full load plus CDC, reconciliation and controlled cutover. |
| Replace one legacy capability at a time | Strangler routing with explicit data ownership. |
Traps
- CDC is not schema conversion.
- Dual writes can diverge when one destination succeeds and the other fails.
- A migration tool’s success status is not business acceptance.
Active recall
1. Why migrate dependencies together?
To avoid breaking latency, reachability or consistency assumptions.
2. What does schema conversion not guarantee?
Complete application compatibility and identical business behavior.
3. Why stop/drain writes during controlled cutover?
To establish a known consistent transition point.
4. What risk does an outbox address?
A database commit succeeding while its event publication is lost.
5. Why is compensation not a true rollback?
External or human-visible effects may require an offsetting business action rather than erasure.