AWS Production-Grade Migration: MGN Server Migration (Part 3)

Overview

In this comprehensive guide, we’ll use AWS Application Migration Service (MGN) to perform a “lift-and-shift” migration of the source web server from the on-premises VPC to the target AWS environment. MGN performs continuous, block-level replication and allows for seamless cutover with minimal downtime, making it the ideal solution for production-grade server migrations.

Estimated Time: 90-120 minutes (including initial sync time)
Region: ap-south-1 (Mumbai)
Difficulty: Intermediate

Why This Matters for Cloud Migration

AWS Application Migration Service (MGN) is the modern approach to server migration, offering:

• Zero-downtime migration with continuous replication
• Block-level replication ensuring data consistency
• Test before cutover capability for risk mitigation
• Production-grade reliability with AWS-managed infrastructure
• Cost-effective solution with minimal operational overhead

Prerequisites Checklist

• Phase 1 and Phase 2 completed successfully
• Source web server is running and accessible
• Target VPC infrastructure is ready
• VPC peering is configured and tested
• All resource IDs documented

Cost Warning

⚠️ Resources that will incur charges:

• MGN replication servers: Automatically created t3.small instances (~$0.024/hour)
• EBS volumes for replication: ~$0.10/GB/month
• Data transfer for replication: Typically minimal within same region
• Converted instances: Based on the instance type you choose for cutover

Estimated MGN Cost: ~$1-2 per day during active replication

💡 Cost Tip: MGN initial setup and replication is free for the first 90 days (2,160 hours) of source server usage. After that, it’s $0.01188/hour per source server.

How AWS MGN Works

Architecture Flow

┌─────────────────────────────────────────────────────────────────┐
│ Source Server (on-prem-vpc)                                     │
│ ┌──────────────────────────────────────────────────────────┐   │
│ │ EC2: on-prem-web-server                                   │   │
│ │ ┌──────────────────────────────────────┐                 │   │
│ │ │ MGN Agent (installed)                 │                 │   │
│ │ │ - Captures disk blocks continuously   │                 │   │
│ │ │ - Encrypts data                       │                 │   │
│ │ │ - Sends to MGN staging area          │                 │   │
│ │ └──────────────────────────────────────┘                 │   │
│ └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘
                            │
                            │ Continuous Replication (encrypted)
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│ MGN Staging Area (automatically created in target account)      │
│ ┌──────────────────────────────────────────────────────────┐   │
│ │ Replication Server (t3.small)                             │   │
│ │ - Receives replicated data                                │   │
│ │ - Stores in staging EBS volumes                           │   │
│ │ - Keeps continuous point-in-time copies                   │   │
│ └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘
                            │
                            │ When you trigger Cutover
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│ Target Environment (aws-target-vpc)                             │
│ ┌──────────────────────────────────────────────────────────┐   │
│ │ New Migrated EC2 Instance                                 │   │
│ │ - Exact copy of source server                             │   │
│ │ - Launched in target subnet                               │   │
│ │ - All data and applications intact                        │   │
│ │ - Ready to serve traffic                                  │   │
│ └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘

Key Concepts

1. MGN Agent: Lightweight software installed on the source server that performs block-level replication 2. Replication Server: Temporary EC2 instance (t3.small) automatically created by MGN to receive replicated data 3. Staging EBS Volumes: Temporary storage holding the replicated data 4. Initial Sync: First-time full replication of the source disk (can take 30-90 minutes depending on size) 5. Continuous Replication: Ongoing capture of disk changes (keeps target up-to-date) 6. Test Cutover: Optional test to verify the migrated server works correctly 7. Cutover: Final launch of the production migrated instance in the target environment

Step 1: Initialize AWS Application Migration Service

1.1 Navigate to MGN Console

1. Sign in to AWS Console
2. Ensure you’re in ap-south-1 region
3. Go to Services → Type “Application Migration Service” → Click it
   • Or search for “MGN” in the search bar

1.2 Get Started with MGN

If this is your first time using MGN in this region:

1. You’ll see a Get started page
2. Click Get started button
3. MGN will initialize the service (takes 10-30 seconds)
4. You’ll see the MGN dashboard

1.3 Set Up Replication Template

1. In the left sidebar, click Settings
2. Click on Replication settings template
3. Review the default settings:
   • Replication server instance type: t3.small (default, good for our use case)
   • EBS volume type: gp3 (default, optimal performance)
   • Data routing: Use private IP (since we have VPC peering)
   • Create Security Group: Yes (MGN will create this automatically)
4. Leave everything as default for now
5. No need to save - these are the defaults

1.4 Configure IAM Permissions

MGN needs certain IAM roles. These are typically auto-created:

1. Go to Settings → IAM roles
2. Verify these roles exist or click to create them:
   • AWSApplicationMigrationReplicationServerRole
   • AWSApplicationMigrationConversionServerRole
   • AWSApplicationMigrationMGHRole
3. If they don’t exist, click Create roles and MGN will create them automatically

Step 2: Prepare Source Server for MGN Agent

2.1 Create IAM Role for MGN Agent

The MGN agent needs an IAM role to authenticate and send replication data. This is more secure than using access keys.

1. Go to Services → IAM
2. Click Roles in the left sidebar
3. Click Create role
4. Configure:
   • Trusted entity type: AWS service
   • Use case: EC2
   • Click Next
5. Attach permissions policies:
   • Search for and select: AWSApplicationMigrationAgentPolicy
   • Click Next
6. Role details:
   • Role name: MGN-Agent-Role
   • Description: IAM role for MGN agent replication
   • Click Create role

2.2 Create Instance Profile

1. In the Roles section, find and click on MGN-Agent-Role
2. Go to the Trust relationships tab
3. Click Edit trust policy
4. Ensure the trust policy looks like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

5. Click Update policy

2.3 Verify Instance Profile

When you create an IAM role for EC2, AWS automatically creates an instance profile with the same name. Let’s verify it exists:

1. Go to IAM → Roles
2. Find and click on MGN-Agent-Role
3. Go to the Trust relationships tab
4. Verify the trust policy allows EC2 service to assume the role
5. The instance profile MGN-Agent-Role is automatically created and ready to use

📝 IMPORTANT: The instance profile ARN will be:

• Instance Profile ARN: arn:aws:iam::935398764279:instance-profile/MGN-Agent-Role

⚠️ Security Note: This approach is more secure than using access keys as the credentials are automatically managed by AWS and don’t need to be stored manually.

Step 3: Install MGN Agent on Source Server

3.1 Generate Installation Commands

1. Go back to Application Migration Service console
2. Click Source servers in the left sidebar
3. Click Add source servers button (top right)
4. You’ll see installation instructions for different operating systems

3.2 Select Operating System

1. Choose Linux
2. Choose RPM-based distributions (for Amazon Linux)

3.3 Copy Installation Commands

You’ll see commands similar to this (yours will be specific to your region):

wget -O ./aws-replication-installer-init https://aws-application-migration-service-ap-south-1.s3.ap-south-1.amazonaws.com/latest/linux/aws-replication-installer-init

sudo chmod +x aws-replication-installer-init
sudo ./aws-replication-installer-init --region ap-south-1

📝 Keep this browser tab open - you’ll need these commands

3.4 SSH into Source Web Server

ssh -i on-prem-web-key.pem ec2-user@YOUR_SOURCE_PUBLIC_IP

3.5 Download and Run MGN Agent Installer

On the source server, run the correct commands:

# Download the MGN agent installer (binary executable)
wget -O ./aws-replication-installer-init https://aws-application-migration-service-ap-south-1.s3.ap-south-1.amazonaws.com/latest/linux/aws-replication-installer-init

# Make it executable and run the installer
sudo chmod +x aws-replication-installer-init
sudo ./aws-replication-installer-init --region ap-south-1

3.6 Attach IAM Role to Source Instance

Before running the installer, we need to attach the IAM role to the source instance:

1. Go to EC2 Console → Instances
2. Select your source web server instance
3. Actions → Security → Modify IAM role
4. Select MGN-Agent-Role from the dropdown
5. Click Update IAM role

3.7 Provide Configuration Details

The installer will automatically detect the region from the command line parameter and prompt you for disk selection:

1. Disk Selection:

Choose the disks you want to replicate. Your disks are: /dev/xvda,/dev/nvme0n1
To replicate some of the disks, type the path of the disks, separated with a comma (for example, /dev/sda,/dev/sdb). To replicate all disks, press Enter:

Response: Press Enter to replicate all disks (recommended)

2. The installer will then:

• Identify volumes for replication
• Download the AWS Replication Agent
• Install and configure the agent
• Start the initial sync process

Note: The installer automatically uses the IAM role attached to the instance for authentication, so no manual credential entry is needed.

3.8 Wait for Installation

The installer will:

• Download required packages
• Install the MGN agent
• Configure the replication
• Start initial sync

Expected output:

Installing AWS Replication Agent...
Creating snapshot...
Installing MGN agent...
Agent installed successfully.
Initial sync started.

This process takes 5-10 minutes.

⚠️ Do not close the SSH session during installation

3.9 Verify Agent Installation

# Check if the agent is running
sudo systemctl status aws-replication-agent

# Expected output: "active (running)"

# Check agent logs (optional)
sudo tail -f /var/log/aws-replication-agent.log

✅ If the status is “active (running)”, the agent is successfully installed!

Step 4: Monitor Source Server in MGN Console

4.1 View Source Servers

1. Go back to MGN Console
2. Click Source servers in the left sidebar
3. You should now see your source server listed!

4.2 Click on the Source Server

Click on the server to see detailed information:

• Server details: Hostname, IP address, OS version
• Disks: Shows all disk volumes being replicated
• Replication progress: % complete
• Network: Network interfaces
• Tags: Any tags on the source instance

4.3 Monitor Initial Sync

The Data replication status will progress through these stages:

1. Initial Sync (0-30% complete) - ~20-40 minutes
2. Initial Sync (30-100% complete) - ~20-40 minutes
3. Continuous Replication - Ongoing

☕ This is a good time for a break! Initial sync typically takes 30-90 minutes depending on:

• Disk size (your server has ~8 GB, so ~30-40 minutes)
• Network speed
• Disk activity on source server

4.4 Wait for “Ready for Testing”

The Migration lifecycle status will change to:

• Not Ready → Ready for testing

✅ Once it says “Ready for testing”, you can proceed to the next step

Step 5: Configure Launch Settings for Target

Before we launch the migrated server, we need to configure where and how it should launch in the target environment.

5.1 Select Source Server

1. In MGN Console, click Source servers
2. Select your source server (checkbox on the left)
3. Go to the Launch settings tab (bottom panel)

5.2 Configure EC2 Launch Template

1. In the Launch settings tab, click Edit button (top right)

General launch settings:

• Instance type: t2.micro (same as source, or change to t3.micro for better performance)
• Launch disposition: Test and Cutover (default)

Network settings:

• Target subnet: Select target-app-subnet-1a (10.1.11.0/24)
  • This is the private subnet for applications in the target VPC
• Security groups: Select target-web-sg (created in Phase 2)

IAM instance profile:

• Leave blank (or create one if you need AWS API access)

Tenancy:

• Default (shared tenancy)

License:

• AWS License (default)

Right sizing:

• Leave as default (use current instance type)

5.3 Configure Post-Launch Actions (Optional)

You can specify scripts to run after the instance launches:

Post-launch script (optional):

#!/bin/bash
# Restart web server after migration
systemctl restart httpd

# Log migration timestamp
echo "Server migrated on $(date)" >> /var/log/migration.log

5.4 Save Launch Settings

1. Scroll down and click Save settings
2. You’ll see a confirmation message

Step 6: Set Up AWS Migration Hub (Optional but Recommended) -> Currently doesnt support ap-south-1 region

Migration Hub provides a central dashboard to track all your migrations.

6.1 Navigate to Migration Hub

1. Go to Services → Migration Hub
2. If first time, click Get started
3. Select Home region: ap-south-1
4. Click Connect or Migrate and modernize

6.2 View MGN in Migration Hub

1. In Migration Hub, click Servers in the left sidebar
2. You should see your server listed with status
3. This provides a unified view if you’re migrating multiple servers

6.3 Create Migration Project (Optional)

1. Click Create project
2. Name it: Legacy-to-Cloud-Migration
3. Description: Migration of on-premises web server and database to AWS
4. Click Create
5. Associate your source server with this project

Step 7: Perform Test Cutover (Recommended)

Before doing the final cutover, it’s best practice to test the migration.

7.1 Initiate Test Launch

1. Go back to MGN Console → Source servers
2. Select your source server (checkbox)
3. Click Test and cutover (top button bar)
4. Select Launch test instances
5. A dialog appears confirming the test launch
6. Click Launch to confirm

7.2 Monitor Test Launch Progress

1. The Migration lifecycle status changes to Test in progress
2. Click on the source server to see detailed progress
3. Go to Job log tab to see real-time progress:
   • Creating launch template
   • Launching test instance
   • Applying user data
   • Waiting for instance to be ready

This takes 5-10 minutes

7.3 Test Launch Complete

1. Status will change to Launched test instance
2. Go to EC2 Console → Instances
3. You should see a new instance:
   • Name: Something like mgn-test-i-xxxxxxxxx
   • Instance State: Running
   • VPC: aws-target-vpc
   • Subnet: target-app-subnet-1a (10.1.11.0/24)
   • Private IP: 10.1.11.x (no public IP, it’s in private subnet)

7.4 Verify Test Instance

Option A: Using Bastion Host (if you created one in Phase 2)

# SSH to bastion host first
ssh -i on-prem-web-key.pem ec2-user@BASTION_PUBLIC_IP

# Then SSH to the test instance from bastion
ssh ec2-user@10.1.11.x

Option B: Using Systems Manager Session Manager (Recommended)

1. Go to Systems Manager → Session Manager
2. Click Start session
3. Select your test instance
4. Click Start session
5. You’ll get a browser-based terminal

Option C: Temporarily add public IP for testing

1. Go to EC2 → Instances
2. Select the test instance
3. Actions → Networking → Manage IP addresses
4. Allocate and attach an Elastic IP
5. Update security group to allow HTTP from your IP
6. Test: http://ELASTIC_IP
7. After testing, release the Elastic IP

7.5 Verify Application Works

Once connected to the test instance:

# Check if Apache is running
sudo systemctl status httpd

# Check web content
curl http://localhost

# Check if it can connect to source database (it should still point to source)
psql --host=YOUR_SOURCE_RDS_ENDPOINT --port=5432 --username=postgres --dbname=legacydb -c "SELECT COUNT(*) FROM users;"

# Check network configuration
ip addr show
ip route

Expected results:

• Apache should be running
• Web content should load
• Database connection should work (still pointing to source DB - we’ll update after DMS)
• Network config shows private IP in 10.1.11.0/24 range

7.6 Finalize Test

1. Go back to MGN Console → Source servers
2. Select your source server
3. Click Test and cutover → Mark as “Ready for cutover”
4. Or, if test failed, click Delete test resources to retry

⚠️ Important: Test instances remain running and incur costs. We’ll clean them up after cutover.

Step 8: Perform Final Cutover

Now that testing is successful, let’s do the final production cutover.

8.1 Pre-Cutover Checklist

Before cutting over, ensure:

• Test cutover was successful
• Source server is still running and replicating
• Replication lag is minimal (check in MGN console)
• You have a rollback plan (keep source server running initially)
• Phase 4 (DMS) is ready to start (you can do this in parallel)

8.2 Initiate Cutover

1. In MGN Console → Source servers
2. Select your source server (checkbox)
3. Click Test and cutover → Launch cutover instances
4. A dialog appears with important warnings:
   • “This will launch the production instance”
   • “Continuous data replication will continue until you finalize cutover”
5. Click Launch to confirm

8.3 Monitor Cutover Progress

1. The Migration lifecycle status changes to Cutover in progress
2. Go to Job log tab to see real-time progress:
   • Creating launch template (if not exists)
   • Launching cutover instance
   • Configuring instance
   • Waiting for instance to be ready

This takes 5-10 minutes

8.4 Cutover Instance Launched

1. Status changes to Cutover complete
2. Go to EC2 Console → Instances
3. You should see a new instance:
   • Name: mgn-cutover- followed by original instance ID
   • Instance State: Running
   • VPC: aws-target-vpc
   • Subnet: target-app-subnet-1a
   • Private IP: 10.1.11.x
4. 📝 Note down the Private IP address

8.5 Rename the Migrated Instance

For clarity, let’s rename it:

1. Select the cutover instance
2. Click on the Name field
3. Rename to: migrated-web-server
4. Add tags:
   • Key: Environment, Value: Production
   • Key: MigratedFrom, Value: on-prem-vpc
   • Key: MigrationDate, Value: 2025-10-17

Step 9: Verify Migrated Application

9.1 Connect to Migrated Instance

Use one of the methods from Step 7.4 (Bastion, Session Manager, or temporary Elastic IP).

9.2 Verify Services

# Check Apache status
sudo systemctl status httpd

# If not running, start it
sudo systemctl start httpd
sudo systemctl enable httpd

# Check if web server responds
curl http://localhost

# Verify Python CGI application
curl http://localhost/cgi-bin/db_app.py

# Check PostgreSQL client
psql --version

9.3 Test Database Connectivity

The application is still pointing to the source database (which is correct until we migrate the database in Phase 4):

# Test connection to source database
psql --host=YOUR_SOURCE_RDS_ENDPOINT --port=5432 --username=postgres --dbname=legacydb -c "SELECT * FROM users;"

# This should still work and show your 4 users

9.4 Update Database Configuration (Do this AFTER Phase 4)

⚠️ Don’t do this yet - wait until Phase 4 (DMS) is complete

After you complete the database migration in Phase 4, you’ll update the application to point to the new database:

sudo sed -i 's|YOUR_SOURCE_RDS_ENDPOINT|YOUR_TARGET_RDS_ENDPOINT|g' /var/www/cgi-bin/db_app.py
sudo systemctl restart httpd

Step 10: Set Up Application Load Balancer (Optional - Production)

For a production setup, you’d put the migrated server behind an ALB for high availability.

10.1 Create Target Group

1. Go to EC2 → Target Groups
2. Click Create target group
3. Configure:
   • Choose a target type: Instances
   • Target group name: migrated-web-tg
   • Protocol: HTTP
   • Port: 80
   • VPC: aws-target-vpc
   • Health check path: /
   • Advanced health check:
     • Healthy threshold: 2
     • Unhealthy threshold: 3
     • Timeout: 5
     • Interval: 30
4. Click Next
5. Register targets: Select migrated-web-server
6. Click Include as pending below
7. Click Create target group

10.2 Create Application Load Balancer

1. Go to EC2 → Load Balancers
2. Click Create Load Balancer
3. Select Application Load Balancer
4. Configure:
   • Name: migrated-app-alb
   • Scheme: Internet-facing
   • IP address type: IPv4
   • VPC: aws-target-vpc
   • Mappings: Select both AZs
     • ap-south-1a: Select public subnet (10.1.1.0/24)
     • ap-south-1b: Select public subnet (10.1.2.0/24)
   • Security groups: Create a new one or use target-web-sg
   • Listeners: HTTP:80
   • Default action: Forward to migrated-web-tg
5. Click Create load balancer
6. 📝 Note the ALB DNS name: migrated-app-alb-xxxxxxxxx.ap-south-1.elb.amazonaws.com

10.3 Test Through Load Balancer

Wait 2-3 minutes for health checks to pass, then:

# Test from your local machine
curl http://YOUR_ALB_DNS_NAME

# Or open in browser
http://YOUR_ALB_DNS_NAME

✅ You should see your application served through the ALB!

Step 11: Finalize Migration in MGN

11.1 Verify Everything is Working

Before finalizing:

• Migrated instance is running smoothly
• Application is accessible and functional
• Database connectivity confirmed
• No critical errors in logs
• Performance is acceptable

11.2 Finalize Cutover

1. Go to MGN Console → Source servers
2. Select your source server
3. Click Test and cutover → Finalize cutover
4. Read the warning:
   • “This will stop continuous replication”
   • “You can no longer perform cutover for this server”
   • “Replication infrastructure will be removed”
5. Type finalize to confirm
6. Click Finalize cutover

11.3 What Happens After Finalization

• Continuous replication stops
• The MGN agent on source server is disabled
• Replication servers are automatically terminated
• Staging EBS volumes are deleted
• Source server status changes to Cutover complete

💰 After finalization, you stop paying for replication infrastructure!

Step 12: Monitor with CloudWatch and Migration Hub

12.1 View in Migration Hub

1. Go to Migration Hub → Servers
2. Your server should show:
   • Status: Completed
   • Target: New EC2 instance ID
   • Migration date: Today’s date

12.2 Set Up CloudWatch Alarms

1. Go to CloudWatch → Alarms
2. Click Create alarm
3. Create alarms for the migrated instance:
   • CPU Utilization > 80%
   • Status Check Failed (any)
   • Network In (baseline monitoring)

12.3 Enable Detailed Monitoring (Optional)

1. Go to EC2 → Select migrated-web-server
2. Actions → Monitor and troubleshoot → Manage detailed monitoring
3. Check Enable
4. This provides 1-minute metrics instead of 5-minute (costs extra)

Step 13: Post-Migration Tasks

13.1 Update DNS (If Applicable)

If you have a domain:

1. Go to Route 53 → Hosted zones
2. Update A record to point to:
   • ALB DNS name (if using ALB), or
   • Elastic IP attached to migrated instance

13.2 Configure Backup Strategy

1. Go to AWS Backup or EC2 Snapshots
2. Create a backup plan for the migrated instance
3. Set retention period (e.g., 7 days)

13.3 Document the Migration

Create a migration report documenting:

• Source server details
• Migration start and end time
• Total replication time
• Cutover downtime (should be minutes)
• Any issues encountered
• Current status and location

Verification Checklist

• MGN agent successfully installed on source server
• Initial sync completed (100%)
• Continuous replication active
• Launch settings configured correctly
• Test cutover performed and verified
• Final cutover completed successfully
• Migrated instance running in target VPC
• Application accessible and functional
• Database connectivity working (to source DB)
• Migration finalized in MGN console
• Test instances terminated (cost optimization)
• Replication infrastructure cleaned up
• Migration documented in Migration Hub

Resource Inventory

📝 Important IDs for Phase 4 and Cleanup:

Troubleshooting

Issue: MGN agent installation fails

Solution:

• Check internet connectivity from source server
• Verify IAM user has correct permissions
• Ensure Python 3 is installed: python3 --version
• Check logs: sudo cat /var/log/aws-replication-agent.log
• Try reinstalling: Remove /opt/aws/mgn and reinstall

Issue: Initial sync stuck at low percentage

Solution:

• Check disk activity on source server: iostat -x 1
• Verify network connectivity to MGN endpoints
• Check security groups allow MGN traffic
• MGN uses TCP 443 and TCP 1500 - ensure not blocked
• Monitor replication lag in MGN console

Issue: Test instance won’t launch

Solution:

• Verify launch settings are correct
• Check target subnet has available IPs
• Verify security group exists and is valid
• Check service quotas for EC2 instances
• Review CloudTrail logs for detailed error messages

Issue: Migrated instance can’t reach internet

Solution:

• Private instances need NAT Gateway for internet access
• Or use VPC endpoints for AWS services
• Or connect through bastion host
• Check route tables have correct routes

Issue: Application not working after migration

Solution:

• Check if services started: sudo systemctl status httpd
• Review application logs: /var/log/httpd/error_log
• Verify security groups allow required traffic
• Check if database endpoint is still accessible
• Ensure file permissions are intact

Cost Optimization

Immediate Actions After Cutover

1. Finalize cutover to stop replication charges
2. Delete test instances - no longer needed
3. Remove staging EBS volumes (automatic after finalization)
4. Delete MGN IAM role and instance profile if no longer needed

Ongoing Optimization

1. Right-size the instance - monitor usage and adjust
2. Use Savings Plans for long-running instances
3. Stop development instances when not in use
4. Set up Auto Scaling for variable workloads

Next Steps

✅ Phase 3 Complete!

Your web server has been successfully migrated from the on-premises environment to the target AWS VPC using MGN!

What you’ve accomplished:

• Installed and configured MGN agent
• Performed block-level replication of entire server
• Tested the migration with minimal risk
• Cut over to production with minimal downtime
• Application is running in target environment

Current state:

• Migrated web server is running in target VPC (private subnet)
• Application is functional
• Still connected to source database (will be updated after Phase 4)

Proceed to Phase 4: Migrate the database using AWS Database Migration Service (DMS)

Quick Reference Commands

# Check MGN agent status
sudo systemctl status aws-replication-agent

# View MGN agent logs
sudo tail -f /var/log/aws-replication-agent.log

# Restart MGN agent (if needed)
sudo systemctl restart aws-replication-agent

# Connect to migrated instance via Session Manager
# (Do this from AWS Console → Systems Manager → Session Manager)

# Test application on migrated server
curl http://localhost
curl http://localhost/cgi-bin/db_app.py

# Check Apache logs
sudo tail -f /var/log/httpd/access_log
sudo tail -f /var/log/httpd/error_log

Conclusion

In this comprehensive guide, we’ve successfully migrated a production web server using AWS Application Migration Service (MGN), demonstrating the power of modern cloud migration tools. This hands-on approach provides essential experience with enterprise-grade server migration strategies.

What we’ve accomplished:

• ✅ MGN Agent Installation: Successfully installed and configured the MGN agent on the source server
• ✅ Continuous Replication: Set up block-level replication with minimal performance impact
• ✅ Test Migration: Performed risk-free testing before production cutover
• ✅ Production Cutover: Executed seamless migration with minimal downtime
• ✅ Application Verification: Confirmed all services and applications work correctly in the target environment

Key Learning Outcomes:

• Understanding of AWS Application Migration Service (MGN) capabilities
• Hands-on experience with continuous replication and cutover processes
• Risk mitigation through test cutover procedures
• Production-grade migration strategies and best practices
• Cost optimization techniques for migration services

This server migration is now complete and ready for the final phase of our migration journey, where we’ll migrate the database using AWS Database Migration Service (DMS).

This is Part 3 of a comprehensive AWS migration series. Here is the Part 4, where we’ll migrate the database using AWS Database Migration Service (DMS).