4.2 Migration Approach
Official task mapping
SAP-C02 task 4.2: Transfer and identity knowledge; secure application, file and database migration selection. This lesson applies the official task to an original design exercise; it is not an exhaustive exam syllabus.
Prerequisites
Review DMS, Transform MGN and DataSync. Be able to explain the relevant failure boundary and access/cost model before choosing a service.
Match the migration unit
Use AWS Transform MGN (the mgn API namespace remains) for supported server replication/test/cutover workflows. Staging, tests and target resources have infrastructure charges. Finalizing cutover does not itself shut down the source operating system; source-write fencing and decommissioning remain explicit runbook actions.
DMS moves supported data using full-load/CDC modes and source-specific prerequisites. Schema conversion is a separate capability/tooling decision: unsupported procedures, permissions, indexes and application SQL need assessment and manual remediation. CDC reduces downtime but does not guarantee zero lag or migrate every database object.
DataSync handles supported file/object transfer paths; validate agent/mode requirements, metadata preservation, verification and network access. Transfer Family serves supported transfer protocols, not block replication. Compare usable throughput, data change rate and deadlines; network transfer time is not just advertised link speed.
SMS is retired. Snowball Edge and Snowmobile are also in full shutdown; historical Snow Family exam mentions are not current deployment recommendations. Check current service/customer availability rather than copying device capacities from old tables.
Transfer mechanism and cutover matrix
| Unit | Candidate | Preconditions |
|---|---|---|
| Supported server disks | Transform MGN | Agent/connectivity, staging, test and target support |
| Database records/CDC | DMS | Source logs/permissions, target schema and compatibility |
| Schema/stored code | Supported conversion assessment/tooling | Manual remediation and application regression tests |
| Files/objects | DataSync | Supported locations/mode, metadata and verification |
| Client SFTP/FTPS/FTP/AS2 workflows | Transfer Family | Supported protocol, identity, storage and integrations |
A network path with 500 Mbit/s usable bandwidth transfers at 62.5 MB/s before protocol/application effects. At 20 decimal TB it needs about 3.7 days for one full copy; a 10% usable duty cycle increases this to about 37 days. Add source changes and validation, not merely link speed. DataSync is not guaranteed faster than every rsync/CLI workload.
Distinguish full load, ongoing CDC and schema conversion. Build indexes/constraints/permissions as required by the chosen source/target and tooling; neither DMS nor SCT guarantees all objects convert. Plan LOBs, transaction ordering, source log retention and validation.
Offline-device tables are historical when the offering is retired/restricted. An insufficient pipe still needs a transfer alternative, but “choose Snowmobile” is not a current answer. Assess supported provider/partner transfer paths or a different deadline/connectivity plan.
A complete cutover stage gates writes, confirms replication catch-up, reconciles counts/business invariants, redirects clients, observes and then finalizes/decommissions only after authorization.
Scenario and rationale
A 20-TB file share and a changing PostgreSQL database must move over a 500-Mbit/s usable path. At a decimal 20 TB, ideal transfer alone is about 320,000 seconds, or 3.7 days; protocol overhead and ongoing changes increase this. Evaluate DataSync for files and DMS full load/CDC for supported database data, with separate schema/permission conversion and cutover checks.
Reject one file-copy tool for a live database without consistency controls. Reject “CDC means no downtime”: write freeze, catch-up, validation and application switching still take time.
Practice drill
Create a cutover checklist covering prechecks, network/IAM/key access, initial copy, deltas, source-write freeze, validation, target enablement and rollback. Specify measured lag and reconciliation thresholds. Include the point after which rollback needs reverse synchronization. Do not finalize or delete a source in this design exercise.
References
- Official Domain 4 task guide
- MGN migration workflow
- DMS migration tasks
- DataSync task options
- Retired migration services
Return to Domain 4. The drill is proposed study work, not a claim of a completed deployment.
Across the wiki
- Migration Patterns — migration (Architecture)
- Data Migration Patterns — migration (Architecture)
- Change Data Capture (CDC) — migration (Architecture)
- Strangler Fig Pattern — migration (Architecture)