On-Premises Migration To AWS

1. Situation

A retailer must leave its data center within nine months. One business application includes:

• three virtual application servers;
• a 4 TB relational database;
• a 20 TB shared file system;
• scheduled jobs;
• internal DNS names;
• an identity provider; and
• connections to payment and warehouse systems.

The business wants minimal downtime. It does not have time to rewrite every application first.

The first mental shift is that “move the application” is not one operation:

servers + database + files + network + identity + dependencies + cutover

The team must also choose the desired migration outcome:

• Rehost: move the application with minimal change—often called lift and shift.
• Replatform: make a bounded change, such as moving a self-managed database to a managed database, without redesigning the whole application.
• Refactor: change the application architecture or code substantially.

This scenario uses rehosting and selective replatforming because the data-center deadline is the immediate pressure. Modernization can continue after the move.

2. Naive Design

Naive option 1: the big-bang weekend

Tap to exploreOpen diagram

This may fit a small, self-contained workload with generous downtime. It fails when transfer duration exceeds the window, source data keeps changing, or an undocumented dependency appears late.

Naive option 2: choose one AWS migration service for everything

AWS Database Migration Service (DMS) moves database data; it does not rehost a virtual server or preserve an SMB network file share. AWS Application Migration Service (MGN) replicates server disks so the server can launch on EC2, but it does not convert an Oracle database schema into PostgreSQL behavior.

The tool follows the thing being moved.

Naive option 3: modernize during the emergency move

The team changes the operating system, application runtime, database engine, network design, and deployment model in the same cutover. When testing fails, nobody knows which change caused it.

Naive option 4: assume copied bytes prove success

The servers boot and file counts match, but the application cannot resolve the payment host, scheduled jobs point at old paths, and users cannot authenticate.

3. What Breaks

Follow a failed migration weekend:

1. The first full database copy takes longer than estimated.
2. Users continued placing orders, so the target became stale during the copy.
3. The AWS application server starts, but a hardcoded database IP still points on premises.
4. A file share copied its contents but not the permissions the application expects.
5. DNS is changed, yet some clients continue using cached answers.
6. New orders reach AWS, making a simple return to the old database unsafe.

The technical failures come from four missing ideas:

• dependency discovery: knowing what must move or remain reachable;
• continuous replication: reducing how much changes between initial copy and cutover;
• end-to-end validation: proving the application, not just each resource; and
• rollback boundaries: deciding when return is safe and when recovery must move forward.

Migration architecture reduces uncertainty before users are switched.

4. AWS Architecture

Build the migration path one question at a time.

Step 1: inventory first, then create migration waves

List servers, databases, file systems, traffic flows, owners, recovery requirements, maintenance windows, licenses, DNS records, and external dependencies.

Then group resources that must move together into a migration wave:

Tap to exploreOpen diagram

Moving a low-risk wave first tests the landing zone, network, tools, runbook, monitoring, and team communication before critical systems depend on them.

Step 2: prepare the AWS destination and temporary bridge

Before replicating production, prepare a landing zone: the governed AWS account and network foundation where migrated workloads will run. It includes accounts, VPCs, subnets, routing, workload permissions, security groups, logging, encryption keys, backups, quotas, and target storage.

Tap to exploreOpen diagram

Use Site-to-Site VPN when the team needs an encrypted internet-based path quickly. Use Direct Connect when sustained private connectivity, predictable network behavior, or long-term hybrid traffic justifies its lead time and cost. Some migrations begin over VPN and add Direct Connect later.

Connectivity does not solve overlapping addresses, missing routes, firewall rules, or DNS. Those remain explicit design tasks.

Step 3: rehost servers with Application Migration Service

AWS Application Migration Service (MGN) is the primary signal for rehosting supported physical, virtual, or cloud-hosted servers onto EC2.

Tap to exploreOpen diagram

The source continues running while its disks replicate. Launch settings define how a replicated server becomes an EC2 instance. The team can launch a test instance, validate it without switching production, correct configuration, and later launch the cutover instance.

MGN answers “How do we rehost this server?” It does not decide whether the application should instead become containers, Lambda functions, or a redesigned service.

Step 4: move database data with DMS

If the target database can be prepared while the source remains active, AWS Database Migration Service can perform:

Tap to exploreOpen diagram

• Full load copies the existing rows.
• Change Data Capture (CDC) reads supported ongoing changes and applies them to the target.

CDC reduces the final outage because the target can remain close to the source until cutover. It does not promise zero lag, and it does not eliminate data validation.

DMS primarily moves data. When source and target database engines differ, schemas, data types, procedures, and database code may need conversion. DMS Schema Conversion can assess and convert many supported objects, but unsupported or behaviorally different objects still need human work and application testing.

Step 5: move file and object data with DataSync

The shared file system is a different data shape. NFS is a common network-file protocol for Linux and Unix systems; SMB is commonly used for Windows-compatible network shares:

Tap to exploreOpen diagram

DataSync automates online file and object transfer, integrity verification, scheduling, filtering, and incremental copies for supported locations.

Choose the AWS destination from how applications use the data:

• choose S3 for object access, analytics, archives, and application designs that do not require a mounted file system;
• choose Amazon EFS, AWS's managed shared NFS file system, for Linux workloads that still need mounted-file access; and
• choose an appropriate Amazon FSx service when the workload needs a managed Windows or specialized file system with compatible behavior.

DataSync moves data. It does not make an application written for a file path automatically use S3 object APIs. Permission metadata is also target-dependent: POSIX ownership or SMB access control lists are not automatically preserved when the destination uses different authorization semantics, such as S3. Verify what the source-and-target pair can carry, then recreate and test the required access controls at the destination.

Step 6: compare online transfer time with physical-transfer options

Estimate transfer time from usable bandwidth, not advertised link speed:

transfer time ≈ data size / sustained usable throughput

Then include change rate. If new data arrives as fast as the network can copy old data, the migration never catches up.

As of 2026, AWS Snow Family devices are no longer available for new customers to order. Current new-customer options include online transfer with DataSync, AWS Data Transfer Terminal for eligible enterprise customers bringing their own storage devices to a physical facility, and AWS Partner solutions.

Older SAA-C03 material may still use Snowball Edge as the recognition answer for very large datasets, constrained bandwidth, or disconnected locations. Learn that historical exam signal, but do not describe it as the current default for a new implementation.

Step 7: test before the cutover clock starts

Tap to exploreOpen diagram

Test more than boot status:

• login and authorization;
• reads and writes;
• file permissions and paths;
• scheduled jobs and integrations;
• monitoring, backup, and restore;
• performance under realistic load; and
• reconciliation of business records.

Record how long each step takes and which evidence allows the team to proceed.

Step 8: make cutover a controlled state transition

announce -> restrict writes -> catch up -> reconcile -> switch traffic
         -> validate -> proceed or invoke rollback decision

At cutover, reduce or stop source writes when the data design requires it. Wait for MGN, DMS, and file deltas to reach the agreed state. Validate counts and business records. Then change DNS, routing, load balancer targets, or client configuration.

Define the point of no simple return. Before AWS accepts new authoritative writes, DNS reversal may be enough. After users create new data in AWS, returning to the old source may require reverse replication or reconciliation. A rollback plan must address data, not only traffic.

Completed migration architecture

Tap to exploreOpen diagram

5. Request Or Data Flow

Learn the migration through three lifecycles.

Lifecycle 1: continuous preparation

1. MGN replicates changed server blocks to its AWS staging resources.
2. DMS performs the database full load and then applies captured changes.
3. DataSync runs initial and incremental file transfers.
4. Users continue using the on-premises application.
5. Monitoring tracks lag, task errors, network saturation, target capacity, and data validation results.

Lifecycle 2: test launch

1. The team launches replicated servers into an isolated test network.
2. Test configuration prevents accidental calls to production dependencies.
3. The application connects to test or replicated database and storage targets.
4. Technical and business owners execute defined test cases.
5. Problems update launch settings, conversion work, security rules, or the runbook.
6. Testing is repeated until the wave is approved for cutover.

Lifecycle 3: production cutover

1. Stakeholders enter the maintenance or controlled-change window.
2. New source writes are stopped or constrained as planned.
3. Replication catches up to the accepted Recovery Point Objective (RPO), the maximum recent data loss the business will accept.
4. The team reconciles source and target data.
5. Cutover instances and target services become authoritative.
6. Traffic and DNS move to AWS.
7. Operators watch application and business metrics.
8. The source remains protected until acceptance criteria and rollback windows are complete.

6. Security Controls

Protect migration copies like production

Staging disks, replication instances, test launches, snapshots, and transfer locations can contain full production data. Place them in controlled networks, encrypt them, log access, and remove them according to the post-migration plan.

Give each migration tool a narrow role

MGN agents, DMS source users, DataSync roles, deployment pipelines, and operators need different permissions. A database replication user should have only the source permissions CDC requires; it should not become a permanent database administrator.

Encrypt the path and destination

Use TLS or service-supported encryption for migration traffic. Site-to-Site VPN provides IPsec encryption. Direct Connect is private connectivity but does not encrypt traffic by default; use application encryption, VPN over Direct Connect, or supported MACsec where the requirement applies.

Use appropriate KMS keys for EBS, S3, RDS, logs, and backups, and confirm every migration and application role can use the required keys.

Do not preserve old weaknesses accidentally

Rehosted disks may contain local accounts, expired software, embedded secrets, unnecessary agents, and open services. Rehosting preserves much of the source; it does not automatically improve its security posture.

7. Resilience Controls

Monitor:

• source discovery coverage and unresolved dependencies;
• MGN replication health and lag;
• DMS task state, latency, table errors, and validation;
• DataSync task failures, bytes remaining, and verification;
• VPN tunnels or Direct Connect path health;
• test and cutover launch success;
• source-versus-target reconciliation; and
• user-facing errors after traffic moves.

Take protected recovery points before destructive schema changes or final cutover. Keep source systems intact until the business signs off.

Practice the rollback decision, including who has authority and how new target writes change the decision. After migration, introduce the intended AWS resilience controls—such as Multi-AZ, load balancing, backups, patching, and alarms—rather than assuming migration itself added them.

8. Performance Controls

The slowest constraint sets migration speed:

• source disk or database read throughput;
• usable network bandwidth and latency;
• ongoing source change rate;
• migration worker or task capacity;
• target write throughput; and
• quantity and size distribution of files.

Test with realistic workloads. Millions of small files can behave differently from a few large objects. Database full load can pressure source I/O. MGN replication can compete with production disk activity.

Schedule heavy copies around business demand, but measure whether the remaining time still meets the migration deadline. Direct Connect can improve sustained predictability, while VPN is usually faster to establish.

Performance testing after migration matters too. A server that boots successfully may still be undersized, placed far from a dependency, or constrained by a storage choice that does not match its access pattern.

9. Cost Controls

Migration creates a temporary double-running period:

on-premises cost + migration staging + AWS test + AWS production

Watch MGN staging disks and replication resources, DMS capacity, DataSync transfer charges, network transfer, Direct Connect or VPN, test EC2 instances, snapshots, logs, and target services.

Migrate in waves to avoid running every duplicate environment for the entire program. Terminate test and staging resources only after their required validation or cutover step completes.

Rehosted servers often carry old overprovisioning into EC2. Establish a stable performance baseline, then right-size. Do not buy long commitments before the post-migration shape and modernization plan are understood.

Include data-center exit timing. AWS savings are delayed if unused hardware, circuits, licenses, and facilities remain contracted after cutover.

10. Exam Variants

11. Common Traps

• Do not choose DMS for whole-server migration.
• Do not choose MGN for database-engine schema conversion.
• Do not choose DataSync for relational change data capture.
• Do not assume S3 is a drop-in mounted file system.
• Do not migrate applications before mapping their dependencies.
• Do not measure only initial data size; include the ongoing change rate.
• Do not call a booted EC2 instance a validated application.
• Do not change traffic while replication lag is unknown.
• Do not assume rollback is simple after AWS accepts new writes.
• Do not teach Snowball ordering as a current new-customer default; keep it as a legacy exam cue.
• Do not confuse rehosting with modernization.

Final Mental Model: One-Minute Review

Tap to exploreOpen diagram

If you remember only one sentence, remember this:

Migration succeeds when the dependent workload—not merely its bytes—has been replicated, tested, cut over, and proven recoverable.

12. Related Topics

Deepen the service mechanics with AWS Application Migration Service, AWS Database Migration Service, AWS DataSync, AWS Direct Connect, AWS Site-to-Site VPN, and the historical AWS Snow Family exam topic.

Official AWS references:

• What is AWS Application Migration Service?
• What is AWS Database Migration Service?
• Gathering migration requirements for AWS DataSync
• AWS Snowball Edge availability change
• What is AWS Data Transfer Terminal?