AWS Scenarios
On-Premises Migration To AWS
Design a phased on-premises migration to AWS using Application Migration Service, DMS, DataSync, Snow Family concepts, VPN or Direct Connect, validation, cutover, and SAA-C03 traps.
After this, you will understand
This scenario teaches learners to split migration by workload type: servers, databases, files, connectivity, and cutover are different problems.
Use MGN for server rehosting, DMS for databases, DataSync for files, Snow-style transfer when the network is not enough, and VPN or Direct Connect for hybrid connectivity.
Learners choose one migration service for everything or forget validation, replication lag, DNS cutover, and rollback planning.
Inventory dependencies, pick migration tools by data shape, replicate before cutover, test in AWS, then switch traffic with a rollback plan.
Think before readingWhy is a migration plan not just a data copy?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- Data center migration planning
- Server rehosting with MGN
- Database migration with DMS
- File migration with DataSync
- Physical transfer decision signals
- Hybrid VPN or Direct Connect
- Cutover and rollback
- Validation and replication lag
- Security during migration
- SAA-C03 migration traps
1. Situation
A company is leaving an on-premises data center. It has application servers, relational databases, file shares, scheduled jobs, and internal dependencies. The business wants minimal downtime, but it cannot rewrite every application before the deadline.
Some applications can be rehosted. Some databases should move to RDS or Aurora. File shares need to move to S3, EFS, or FSx. Connectivity is needed during the transition.
The scenario is really several migrations:
servers + databases + files + network + cutover
Each part has a different AWS answer.
2. Naive Design
The naive migration is a weekend copy:
stop apps -> copy everything -> start in AWS -> hope it works
That can work for small systems with generous downtime. It fails for large databases, active file shares, undocumented servers, slow networks, and applications with hidden dependencies.
Another naive design is choosing DMS for everything because "migration" appears in the name. DMS is database-focused. It does not rehost application servers or move file shares.
A third naive design is using online transfer for a dataset that would take months over the available network.
3. What Breaks
Large datasets outgrow the maintenance window. Applications keep writing while data is being copied. DNS changes take time. Firewall rules are missed. Hardcoded IPs break. License servers remain on premises. Database schemas differ. File permissions do not map cleanly.
Cutover can fail late if testing only checks that servers boot, not that the application works end to end.
Rollback can become impossible if users start writing to the new system and the old system cannot receive those changes.
Migration architecture is about reducing uncertainty before cutover.
4. AWS Architecture
Use AWS Application Migration Service for lift-and-shift server migration. Install agents where appropriate, replicate source server disks to a staging area, test launch EC2 instances, then perform cutover launches.
Use AWS DMS for database migration. For minimal downtime, perform full load plus change data capture so the target stays near the source until cutover.
Use AWS DataSync for online file and object transfer from NFS, SMB, HDFS, object storage, S3, EFS, or FSx locations.
Use Snow Family concepts or current AWS physical transfer options when bandwidth, dataset size, or disconnected locations make online transfer impractical.
Use Site-to-Site VPN for fast encrypted connectivity and Direct Connect for sustained private, predictable hybrid connectivity.
5. Request Or Data Flow
During migration, users continue using the on-premises application.
MGN continuously replicates server disks into AWS. DMS performs a full database load and then replicates ongoing changes. DataSync runs scheduled or incremental file transfers.
Test environments launch in AWS. Teams validate application behavior, database consistency, file access, IAM roles, security groups, DNS, monitoring, and backups.
At cutover, freeze or reduce writes, let replication catch up, switch DNS or routing, and move users to the AWS-hosted system.
After cutover, monitor errors, latency, database lag, logs, and user behavior before decommissioning old systems.
6. Security Controls
Use least privilege for migration roles, agents, replication users, and target resources.
Encrypt data in transit. DMS supports SSL/TLS where endpoints support it. DataSync provides secure transfer and AWS IAM integration. VPN provides IPsec connectivity.
Protect staging areas. Migration resources can contain full copies of production systems and data.
Use KMS for encrypted EBS volumes, S3 buckets, RDS targets, and backup storage where required.
Do not bring old security mistakes forward unquestioned. Rehosted servers may still contain weak local users, secrets on disk, old agents, and open ports.
7. Resilience Controls
Run test launches before cutover. Booting is not enough; test user flows, batch jobs, database writes, file access, and monitoring.
Watch replication lag. Minimal downtime depends on the target catching up.
Keep source systems intact until the cutover is validated.
Take backups or snapshots before risky changes.
Plan rollback. Know whether rollback means DNS reversal, data replay, read-only source mode, or a decision that cutover is one-way.
After migration, improve resilience with Multi-AZ databases, Auto Scaling, load balancers, backups, alarms, and patching.
8. Performance Controls
Migration performance depends on source read capacity, network bandwidth, replication tool sizing, target write capacity, and change rate.
Do not overload the source database during business hours with full-load tasks.
DataSync performance depends on file count, average file size, source storage, network, and destination service limits.
MGN initial replication depends on disk size and change rate.
Direct Connect can improve sustained throughput and predictability, but provisioning time matters. VPN can be faster to set up but depends on internet path and tunnel limits.
For huge transfers, compare online transfer time with physical transfer timelines.
9. Cost Controls
Migration creates temporary double-running cost: on-premises infrastructure plus AWS replication, staging, test, and target resources.
DMS replication instances or serverless capacity, MGN staging resources, DataSync transfer, test EC2 instances, EBS volumes, snapshots, logs, and connectivity all cost money.
Direct Connect may be justified for long-term hybrid workloads, but may be too much for a short migration.
Right-size after migration. Lift-and-shift often preserves old overprovisioning.
Use Cost Explorer and Compute Optimizer after cutover to find waste.
10. Exam Variants
"Rehost many servers with minimal downtime" points to AWS Application Migration Service.
"Migrate a database with ongoing replication" points to AWS DMS.
"Move NFS or SMB file data to S3, EFS, or FSx" points to DataSync.
"Network transfer would take too long" points to Snow Family-style physical transfer or current AWS physical transfer options.
"Private dedicated connectivity" points to Direct Connect.
"Fast encrypted connection over the internet" points to Site-to-Site VPN.
11. Common Traps
Do not choose DMS for whole-server migration.
Do not choose MGN for database engine conversion.
Do not choose DataSync for relational CDC.
Do not ignore replication lag before cutover.
Do not decommission source systems before validation.
Do not forget that rehosting is not modernization.
12. Related Topics
Review AWS Application Migration Service, AWS Database Migration Service, AWS DataSync, AWS Direct Connect, and AWS Site-to-Site VPN.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.