On-Premises Migration To AWS

Why This Migration Exists

A retailer must leave its data center within nine months. Its application depends on servers, a relational database, shared files, jobs, DNS, identity, and external systems. Rewriting everything before the deadline would combine a risky move with a risky redesign.

The team therefore separates migration from broader modernization:

• Rehost moves a workload with minimal change—the usual “lift and shift” choice when speed is the pressure.
• Replatform makes a bounded platform change, such as moving a self-managed database to a managed database, without redesigning the whole application.
• Refactor changes the application code or architecture substantially.

This migration primarily rehosts servers and selectively replatforms components. Refactoring can continue after the workload is safely running in AWS.

The Architecture In One View

“Move the application” is not one copy operation. Servers, database rows, and files need different migration mechanisms. A hybrid network connects the data center to a prepared AWS destination while production runs. The paths join after the complete business flow is tested and the team is ready to transfer authority.

Tap to exploreOpen diagram

The Jobs That Matter

• Landing zone — prepare the governed destination. Accounts, networking, routing, permissions, logging, encryption, backups, quotas, and target storage must exist before replication depends on them. Otherwise foundation problems appear during migration testing.
• Site-to-Site VPN or Direct Connect — provide the bridge. VPN creates an encrypted path over the internet relatively quickly. Direct Connect takes longer to establish and costs more, but provides dedicated private connectivity with more predictable network behavior. Direct Connect is private, not automatically encrypted.
• AWS Application Migration Service (MGN) — rehost servers. MGN replicates supported source-server disks into AWS staging resources, then launches test or cutover EC2 instances. It does not redesign the application or convert database engines.
• AWS Database Migration Service (DMS) — move database data. A full load copies existing rows. Change Data Capture (CDC) then applies supported ongoing changes while the source remains active. This moves most data before cutover and reduces the final outage. CDC can lag, so the target must catch up and be validated.
• Schema conversion — translate database structures and code. DMS moves data. If source and target engines differ, data types, tables, procedures, or database code may also need conversion. Oracle to PostgreSQL therefore has both data-movement and compatibility problems.
• AWS DataSync — move file and object data. DataSync transfers supported on-premises NFS, SMB, or object data to destinations such as S3, EFS, or FSx. The destination must match how the application accesses data. S3 exposes object APIs; it does not automatically replace a mounted file path or preserve the same permission semantics.

Read deeper into the landing zone and hybrid bridge Read deeper into DMS, CDC, and schema conversion

How The Migration Moves From Copy To Production

1. Discover the workload. Inventory servers, data, DNS, identity, jobs, traffic, owners, and dependencies. Group resources that must move together into migration waves.
2. Choose the outcome. Decide what will be rehosted, selectively replatformed, or left for later refactoring before choosing tools.
3. Prepare AWS and connectivity. Build the landing zone and establish the VPN or Direct Connect path so replication and testing have a controlled destination.
4. Replicate by data shape. MGN copies changing server disks, DMS performs full load and CDC, and DataSync runs initial and incremental file transfers while users continue using the source application.
5. Test an isolated wave. Away from live users, prove login, reads and writes, file permissions, jobs, integrations, restore behavior, performance, and record reconciliation. A booted EC2 instance proves only that the server started—not that the application works.
6. Rehearse the cutover. Record the order, duration, evidence, decision owners, and rollback boundary before the production clock starts.
7. Restrict source writes. Reduce or stop new writes so replication can close the remaining gap instead of chasing a changing source.
8. Catch up and reconcile. Wait for the server, database, and file deltas to reach the accepted state, then compare source and target records.
9. Transfer authority and traffic. Make the AWS targets the production systems and change DNS, routing, load-balancer targets, or client configuration. AWS becomes authoritative when the application begins accepting new production writes there—not merely when a DNS record changes.
10. Observe before retiring the source. Confirm technical health and business acceptance, and retain the old environment until the rollback window closes.

Rollback is simplest before AWS accepts authoritative writes: users can be directed back while the old source still owns the current data. After new orders exist only in AWS, reversing DNS alone would lose or split those writes. Recovery then requires reconciliation, reverse replication, or a deliberate move-forward plan.

Read deeper into cutover authority and rollback

Distinctions Worth Holding Onto

• MGN vs DMS: MGN rehosts server disks onto EC2; DMS moves database data.
• DMS vs schema conversion: DMS transfers rows and supported changes; schema conversion addresses cross-engine structures and database code.
• VPN vs Direct Connect: VPN favors speed of establishment and encrypted internet transport; Direct Connect favors sustained private, predictable connectivity but is not encryption by itself.
• DataSync vs S3: DataSync is a transfer service. S3 is one possible object-storage destination, not a mounted-file-system substitute.

SAA Recognition Signals

• “Rehost physical or virtual servers onto EC2” points first to Application Migration Service because the thing being moved is a server environment.
• “Migrate a database with minimal downtime” points to DMS full load plus CDC because the initial copy and ongoing changes are separate jobs.
• “Change database engine” adds schema-conversion work because moving rows does not translate every database object or behavior.
• “Move NFS or SMB data to S3, EFS, or FSx” points to DataSync because the source is file or object data.
• “Establish encrypted hybrid connectivity quickly” points to Site-to-Site VPN; “dedicated private and predictable connectivity” points to Direct Connect.
• “Minimize the cutover window” means replicate and test first, then restrict writes, catch up, reconcile, and switch.

The wording is a clue, not the reasoning. Match the service to the object being moved and the requirement that changes the decision.

High-Value Traps

• Do not choose one migration service for servers, databases, and files.
• Do not call a copied resource a validated application; dependencies and business flows must work together.
• Do not assume CDC means zero lag or removes reconciliation.
• Do not treat S3 as a drop-in mounted filesystem.
• Do not combine a deadline-driven move with an unnecessary full refactor.
• Do not assume rollback is a traffic-only action after AWS has accepted new writes.

One-Minute Review

Tap to exploreOpen diagram

discover dependencies
-> choose rehost / replatform / refactor
-> prepare landing zone + connectivity
-> MGN for servers, DMS + CDC for database data, DataSync for files
-> test the whole business flow
-> restrict writes, catch up, reconcile
-> make AWS authoritative and switch traffic
-> validate before retiring the source

If you remember only one thing: migration succeeds when the dependent workload—not merely its bytes—has been replicated, tested, cut over, and proven recoverable.