LAB 02
Lift and shift an application server to AWS with continuous block-level replication and minimal-downtime cutover
This lab migrates an entire application server from a simulated on-premises environment to AWS using Application Migration Service (MGN). The replication agent continuously copies disk blocks to a staging area, then MGN launches the final target instance on demand.
The replication agent on the source server continuously streams disk blocks to the staging area over an encrypted connection. When you launch a test or cutover instance, MGN converts the replicated data into a bootable EBS volume and launches the target EC2 instance in your configured subnet with the specified security group and instance profile.
AWS MGN tracks your server through a defined lifecycle. Each state represents a milestone in the migration journey — from initial replication through to final cutover. Watch the animation to see how a server progresses through the pipeline.
Expand each task for the goal, key configuration, and important notes. Use this as a condensed companion while working through the lab console steps.
Install Apache, PHP, and a sample web application on the source server to simulate an on-premises workload ready for migration.
| Setting | Value |
|---|---|
| OS | Amazon Linux 2 |
| Web Server | Apache (httpd) |
| Runtime | PHP 7.2 (lamp-mariadb10.2-php7.2) |
| Application | instanceData.zip (displays instance metadata) |
| Document Root | /var/www/html |
Connect via Session Manager — no SSH key required. The web app simply displays the EC2 instance ID and Availability Zone, making it easy to verify which server you're viewing after migration.
Confirm the web application is running and accessible via HTTP before starting the migration process.
| Setting | Value |
|---|---|
| Protocol | HTTP (not HTTPS) |
| URL | Public DNS of Source Application Server |
| Expected Output | Instance ID + Availability Zone |
Use HTTP, not HTTPS. The source server does not have an SSL certificate configured. Note down the instance ID — you'll compare it against the target after migration.
Initialize Application Migration Service, configure the replication template with the correct staging subnet, and obtain the agent installation commands.
| Setting | Value |
|---|---|
| Staging area subnet | Target-Pub-Staging |
| Access Key | MigrationAccessKey (from lab resources) |
| Secret Key | MigrationSecret (from lab resources) |
Copy both the download command and the install command to a text editor before navigating away. You'll need them in the next task when connecting to the source server.
Download and run the AWS Replication Agent on the source server to begin continuous block-level replication to the staging area.
| Step | Command |
|---|---|
| Elevate privileges | sudo su |
| Download agent | sudo wget -O ./aws-replication-installer-init.py ... |
| Install agent | sudo python3 aws-replication-installer-init.py ... |
| Success message | "The AWS Replication Agent was successfully installed" |
Run as root (sudo su) before executing the agent commands. After successful installation, type exit to drop root privileges. Replication begins automatically — no reboot required.
Customize the EC2 launch template that MGN uses when creating test and cutover instances — instance type, subnet, security group, and IAM profile.
| Setting | Value |
|---|---|
| Right-sizing | Off (disabled) |
| Instance type | t3.small |
| Subnet | Target-Pub-A |
| Security group | TargetAppSG |
| Auto-assign public IP | Enable |
| Name tag | Target Application Server |
| IAM instance profile | EC2InstanceProfile |
| Default version | Version 3 |
Disable right-sizing first (General launch settings), then modify the EC2 Launch Template. After creating the new template version, set it as the default (version 3) so MGN uses your configuration for all launches.
Validate the migration by launching a non-disruptive test instance. This does not affect the source server or ongoing replication.
| Step | Detail |
|---|---|
| Wait for status | Ready for testing (10–15 min) |
| Action | Test and cutover → Launch test instances |
| Monitor | Launch history → Job ID → Status: Completed |
| After validation | Mark as "Ready for cutover" |
The test instance launch takes 10–15 minutes. Once complete, verify the application works on the test instance, then mark the server as "Ready for cutover" to proceed to the final migration step.
Launch the final production cutover instance — this is the actual migrated server that replaces the source.
| Step | Detail |
|---|---|
| Action | Test and cutover → Launch cutover instances |
| Monitor | Launch history → Cutover Job ID |
| Duration | ~10–15 minutes |
| Verify | Target Application Server in EC2 console |
If you see "Failed to launch cutover instances" — the test instance is still being terminated. Wait 2–4 minutes and retry. The cutover instance uses the same launch template configuration you set up earlier.
Stop replication, clean up staging resources, and mark the migration as complete. This is the final step.
| Step | Detail |
|---|---|
| Verify target app | HTTP access to Target Application Server public DNS |
| Expected output | New instance ID + different AZ from source |
| Finalize action | Test and cutover → Finalize cutover |
| Final status | Cutover complete |
Finalizing the cutover terminates the replication server in the staging subnet and archives the source server entry. This action is irreversible — only finalize after confirming the target application works correctly.
Core ideas behind application migration with AWS MGN. Understanding these concepts helps you make informed decisions during the migration process.
Migrate an entire server as-is to AWS. The operating system, applications, configurations, and data are all replicated block-by-block — no application-level changes required.
Copies raw disk blocks continuously rather than individual files. This captures everything including OS state, installed packages, and application binaries — providing a true 1:1 copy of the source.
A lightweight agent installed on the source server that streams disk changes to AWS. No reboot is needed during installation, and performance impact on the source workload is minimal.
Temporary replication servers in the target VPC that receive and store replicated data. These are auto-managed by MGN and cleaned up when you finalize the cutover.
Controls how the target EC2 instance is configured: instance type, subnet placement, security groups, IAM profile, and tags. You customize this before launching test or cutover instances.
Launch test instances without affecting the source server or ongoing replication. Validate that the migrated application works correctly before committing to the final cutover.
For AnyCompany Bank, MGN's non-disruptive testing is critical for migrating application servers that process financial transactions. Teams can validate that the migrated server handles payment workflows correctly before committing to cutover — ensuring zero transaction loss during the migration window. The block-level approach means no application code changes are needed, reducing risk for compliance-sensitive workloads.