AWS Migration Hub: Lift-and-Shift Migration Strategy and Tools (2026)

1. The 7 Rs Migration Strategy

AWS defines seven migration patterns — commonly called the "7 Rs" — that map source workloads to appropriate migration approaches. Choosing the right R for each application is the most consequential decision in your migration plan.

Strategy Definitions

• Retire — Decommission applications that are no longer needed. Typically 10–20% of a legacy portfolio. Reduces migration scope immediately.
• Retain — Leave workloads on-premises for now. Used for apps with regulatory constraints, recent hardware investment, or planned rewrites. Revisit in 12–24 months.
• Rehost (Lift and Shift) — Move VMs or physical servers to EC2 with no code changes. Fastest path to AWS. Use AWS MGN. Best for large legacy estates where speed matters more than optimisation.
• Replatform (Lift, Tinker, and Shift) — Minimal changes to leverage cloud features. Examples: move to RDS instead of self-managed MySQL, switch to Elastic Beanstalk instead of raw EC2. No core architecture changes.
• Repurchase — Replace on-premises software with a SaaS equivalent. E.g., migrate from on-prem CRM to Salesforce, or from self-hosted email to Microsoft 365.
• Refactor / Re-architect — Redesign the application to be cloud-native. Decompose monoliths into microservices, adopt Lambda, ECS, or EKS. Highest cost and effort; highest long-term ROI.
• Relocate — Move VMware workloads to VMware Cloud on AWS without converting VMs to EC2. Preserves VMware tooling and operational processes.

Decision Matrix

2. AWS Migration Hub: Centralized Tracking Dashboard

AWS Migration Hub aggregates migration status from MGN, DMS, and third-party tools (CloudEndure, ATADATA) into a single console. It does not perform migrations itself — it tracks them. Before using any migration tool, you must set a home region for Migration Hub. All migration data is stored in that region and cannot be changed later.

Setting the Home Region (AWS CLI)

# List available home regions
aws migrationhub-config describe-home-region-controls \
  --region us-east-1

# Set home region (one-time, irreversible per account)
aws migrationhub-config create-home-region-control \
  --home-region us-east-1 \
  --target '{"Type": "ACCOUNT"}' \
  --region us-east-1

# Confirm home region is set
aws migrationhub-config get-home-region \
  --region us-east-1

Key Migration Hub Concepts

• Applications — Logical groupings of servers that migrate together (e.g., a 3-tier web app: web tier, app tier, DB tier).
• Servers — Individual discovered or manually added source machines.
• Migration Tasks — Linked MGN or DMS tasks associated with each server.
• Progress States — Not Started → In Progress → Completed. Drill down per server for detailed status.

3. Discovery: AWS Application Discovery Service

Before migrating, you need an inventory of what you have: servers, software, network dependencies, and resource utilisation. AWS Application Discovery Service (ADS) provides two collection modes.

Agentless Discovery (via Discovery Connector)

The Discovery Connector is a VMware virtual appliance deployed in your vCenter. It collects VM metadata (CPU, memory, disk, OS) and network connections without touching individual VMs. Best for VMware environments where installing agents is impractical.

• Deploy OVA to vCenter (download from Migration Hub console)
• Configure vCenter credentials in the connector UI
• Data appears in Migration Hub within 15 minutes
• No agent installation required on guest VMs
• Does not collect running processes or installed software

Agent-Based Discovery

The Discovery Agent runs on each Linux or Windows server and collects detailed telemetry: running processes, installed software, inbound/outbound network connections, and performance metrics over time. Required for physical servers or non-VMware hypervisors.

# Install Discovery Agent on Linux (Amazon Linux / RHEL / CentOS)
curl -o aws-discovery-agent.tar.gz \
  https://s3.us-west-2.amazonaws.com/aws-discovery-agent.us-west-2/linux/latest/aws-discovery-agent.tar.gz

tar -xzf aws-discovery-agent.tar.gz

sudo bash install -r us-east-1 \
  -k <AWS_ACCESS_KEY_ID> \
  -s <AWS_SECRET_ACCESS_KEY>

# Verify agent is running
sudo systemctl status aws-discovery-daemon

Exporting Discovery Data

# Start an export of discovered data
aws discovery start-export-task \
  --region us-east-1

# Check export status
aws discovery describe-export-tasks \
  --region us-east-1

# The export generates CSV files in an S3 bucket:
# - servers.csv, processes.csv, connections.csv, performance-data.csv

4. Application Migration Service (MGN): How Replication Works

AWS Application Migration Service (MGN) — formerly CloudEndure Migration — is the primary AWS tool for rehosting (lift-and-shift). It performs continuous block-level replication from source servers to AWS, enabling near-zero downtime cutover.

Replication Architecture

1. MGN Agent installed on source server. Reads block-level disk data.
2. Encrypted data streams to a Replication Server (a temporary EC2 instance in your account) over TCP port 1500.
3. Replication Server writes data to EBS staging volumes — exact block-level copies of source disks.
4. During cutover, MGN converts staging volumes into a Launch Template and boots the target EC2 instance.
5. The replication server and staging volumes are automatically terminated after cutover.

Initial Setup via AWS CLI

# Initialize MGN in your account (one-time)
aws mgn initialize-service \
  --region us-east-1

# Create a replication configuration template
aws mgn create-replication-configuration-template \
  --replication-server-instance-type t3.small \
  --replication-servers-security-groups-ids sg-0abc123def456789 \
  --staging-area-subnet-id subnet-0123456789abcdef0 \
  --staging-area-tags Key=Purpose,Value=MGN-Staging \
  --use-dedicated-replication-server false \
  --bandwidth-throttling 0 \
  --region us-east-1

5. MGN Agent Installation and Replication Configuration

Linux Agent Installation

# Download and install MGN agent on Linux
wget -O ./aws-replication-installer-init.py \
  https://aws-application-migration-service-us-east-1.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py

sudo python3 aws-replication-installer-init.py \
  --region us-east-1 \
  --aws-access-key-id AKIAIOSFODNN7EXAMPLE \
  --aws-secret-access-key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY \
  --no-prompt

# Verify replication agent is running
sudo systemctl status aws-replication-agent

Windows Agent Installation (PowerShell)

# Download MGN agent installer for Windows
Invoke-WebRequest `
  -Uri "https://aws-application-migration-service-us-east-1.s3.amazonaws.com/latest/windows/AwsReplicationWindowsInstaller.exe" `
  -OutFile "C:\Temp\AwsReplicationWindowsInstaller.exe"

# Install silently
Start-Process -FilePath "C:\Temp\AwsReplicationWindowsInstaller.exe" -ArgumentList @(
  "--region", "us-east-1",
  "--aws-access-key-id", "AKIAIOSFODNN7EXAMPLE",
  "--aws-secret-access-key", "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
  "--no-prompt"
) -Wait -NoNewWindow

Configuring Launch Template After Initial Sync

Once the agent is installed and initial replication reaches "Healthy" state (typically 1–4 hours depending on disk size), configure the Launch Template that MGN uses when it boots the target EC2 instance.

# List source servers
aws mgn describe-source-servers \
  --filters IsArchived=false \
  --region us-east-1

# Update launch template for a specific source server
aws mgn update-launch-configuration \
  --source-server-id s-1234567890abcdef0 \
  --target-instance-type-right-sizing-method BASIC \
  --launch-disposition STOPPED \
  --licensing '{"osByol": false}' \
  --region us-east-1

6. Cutover Workflow: Test Instance → Validate → Cutover

MGN separates the cutover process into two phases: a test launch (no impact to source server) followed by the actual cutover launch. This is the safest migration pattern available.

Cutover Timeline

Triggering Test and Cutover via CLI

# Launch test instance
aws mgn start-test \
  --source-server-ids s-1234567890abcdef0 \
  --region us-east-1

# Check job status
aws mgn describe-jobs \
  --filters SourceServerIDs=s-1234567890abcdef0 \
  --region us-east-1

# After validation, launch cutover
aws mgn start-cutover \
  --source-server-ids s-1234567890abcdef0 \
  --region us-east-1

# Finalize (archives source server, terminates replication resources)
aws mgn finalize-cutover \
  --source-server-id s-1234567890abcdef0 \
  --region us-east-1

Rollback Strategy

If the cutover launch fails or validation reveals issues, MGN supports rollback:

• During test phase: terminate the test instance — source server is untouched and replication continues.
• During cutover: if source server is still running, revert DNS, scale up source, and let replication re-sync the delta. MGN keeps replication active until you call finalize-cutover.
• After finalize: restore from the EBS snapshot that MGN creates automatically at cutover time (retained for 30 days by default).

7. Database Migration Service (DMS): Supported Sources and Targets

AWS Database Migration Service migrates relational databases, data warehouses, NoSQL stores, and other data sources to AWS with minimal downtime. It supports both homogeneous migrations (e.g., MySQL → RDS MySQL) and heterogeneous migrations (e.g., Oracle → Aurora PostgreSQL).

Supported Sources and Targets (2026)

Creating a Replication Instance

# Create DMS replication instance
aws dms create-replication-instance \
  --replication-instance-identifier prod-migration-repl \
  --replication-instance-class dms.r6i.xlarge \
  --allocated-storage 100 \
  --vpc-security-group-ids sg-0abc123def456789 \
  --replication-subnet-group-identifier my-dms-subnet-group \
  --multi-az false \
  --engine-version 3.5.3 \
  --publicly-accessible false \
  --region us-east-1

8. DMS Task Creation: Full-Load, CDC, and Hybrid

Migration Modes

• Full Load — Copies all existing data from source to target. Source database continues running. After load completes, a final delta sync is needed. Use for short maintenance windows.
• CDC Only (Change Data Capture) — Replicates ongoing changes only. Used when you have already bulk-loaded the target by other means (e.g., native database export/import).
• Full Load + CDC — Copies all data, then automatically transitions to CDC once the initial load completes. The recommended approach for most migrations — minimal downtime, no manual handoff.

Table Mapping Rules (JSON)

Table mapping rules define which schemas and tables to include or exclude, and allow column transformations.

{
  "rules": [
    {
      "rule-type": "selection",
      "rule-id": "1",
      "rule-name": "include-all-tables",
      "object-locator": {
        "schema-name": "PROD_SCHEMA",
        "table-name": "%"
      },
      "rule-action": "include"
    },
    {
      "rule-type": "selection",
      "rule-id": "2",
      "rule-name": "exclude-audit-logs",
      "object-locator": {
        "schema-name": "PROD_SCHEMA",
        "table-name": "AUDIT_%"
      },
      "rule-action": "exclude"
    },
    {
      "rule-type": "transformation",
      "rule-id": "3",
      "rule-name": "lowercase-schema",
      "rule-action": "convert-lowercase",
      "rule-target": "schema",
      "object-locator": {
        "schema-name": "%"
      }
    }
  ]
}

Creating a Replication Task via CLI

aws dms create-replication-task \
  --replication-task-identifier prod-full-load-cdc \
  --source-endpoint-arn arn:aws:dms:us-east-1:123456789012:endpoint:source-endpoint-id \
  --target-endpoint-arn arn:aws:dms:us-east-1:123456789012:endpoint:target-endpoint-id \
  --replication-instance-arn arn:aws:dms:us-east-1:123456789012:rep:prod-migration-repl \
  --migration-type full-load-and-cdc \
  --table-mappings file://table-mapping.json \
  --replication-task-settings '{"TargetMetadata":{"TargetSchema":"","SupportLobs":true,"FullLobMode":false,"LobChunkSize":64},"FullLoadSettings":{"TargetTablePrepMode":"DROP_AND_CREATE","CreatePkAfterFullLoad":false},"Logging":{"EnableLogging":true}}' \
  --region us-east-1

Monitoring DMS Task Progress (Python boto3)

import boto3
import time

dms = boto3.client('dms', region_name='us-east-1')

TASK_ARN = 'arn:aws:dms:us-east-1:123456789012:task:prod-full-load-cdc'

def poll_task_status(task_arn, interval=30):
    while True:
        response = dms.describe_replication_tasks(
            Filters=[{'Name': 'replication-task-arn', 'Values': [task_arn]}]
        )
        task = response['ReplicationTasks'][0]
        status = task['Status']
        stats = task.get('ReplicationTaskStats', {})

        print(f"Status: {status} | "
              f"Tables loaded: {stats.get('TablesLoaded', 0)} | "
              f"Tables loading: {stats.get('TablesLoading', 0)} | "
              f"Tables errored: {stats.get('TablesErrored', 0)} | "
              f"Elapsed: {stats.get('ElapsedTimeMillis', 0) / 1000:.0f}s")

        if status in ('stopped', 'failed', 'load-complete-replication-ongoing'):
            print(f"Task reached terminal/CDC state: {status}")
            break

        time.sleep(interval)

poll_task_status(TASK_ARN)

9. Schema Conversion Tool (SCT): Oracle to PostgreSQL and SQL Server to Aurora

AWS Schema Conversion Tool (SCT) automates the conversion of database schemas from one engine to another. It handles DDL statements (tables, views, indexes, sequences) and attempts to convert stored procedures, functions, and triggers — flagging anything that requires manual rewriting.

Typical SCT Workflow

1. Install SCT on a laptop or EC2 instance with connectivity to both source and target databases.
2. Create a new project, specify source engine (Oracle 19c) and target engine (Aurora PostgreSQL 15).
3. Connect to source database — SCT loads the schema tree.
4. Run the Assessment Report. SCT categorises objects as: automatically converted, converted with minor issues, or requires manual intervention.
5. Review the action items. Oracle-specific syntax like CONNECT BY, DBMS_* packages, and ROWNUM require manual PostgreSQL equivalents.
6. Apply converted schema to target Aurora PostgreSQL instance.
7. Fix flagged objects manually — these are typically 5–20% of procedures in complex Oracle schemas.

Common Oracle → PostgreSQL Conversion Patterns

10. Migration Evaluator: TCO Analysis and Rightsizing

AWS Migration Evaluator (formerly TSO Logic) analyses your on-premises infrastructure and produces a Total Cost of Ownership (TCO) comparison against AWS. It ingests data from discovery agents, VMware vCenter exports, or manual inventory files.

Data Collection Options

• Agentless Collector — VMware vCenter integration, collects for 2–4 weeks.
• Import template — Upload a spreadsheet of server specs, utilisation, and costs.
• ADS integration — Pulls directly from Application Discovery Service if already deployed.

What the Evaluator Report Contains

• On-premises total cost: hardware refresh, software licences, power, cooling, facilities, operations.
• AWS right-sized cost: EC2, EBS, data transfer — using Reserved Instance and Savings Plan pricing.
• Licence optimisation: identifies SQL Server and Windows licences that can be brought to AWS (BYOL) or replaced with Linux + Aurora to eliminate licence cost entirely.
• Savings summary: typical outcome is 30–60% cost reduction over 3 years.

11. Post-Migration Validation: CloudWatch Metrics and Performance Baselines

Migration is not complete when the instance boots. You must verify that the migrated workload performs equivalently to on-premises and that all integrations are functional.

Validation Checklist

• Application starts cleanly — no missing libraries, environment variables, or config files.
• All inbound ports are reachable from expected clients (verify Security Group rules).
• Outbound connectivity to dependent services (databases, APIs, LDAP, NTP) works.
• Scheduled tasks and cron jobs are running.
• Log files are writing to expected paths — or redirected to CloudWatch Logs.
• Licence servers are reachable (for licensed software).
• Backup agent is configured for EBS snapshots.

Establishing a CloudWatch Performance Baseline (Python boto3)

import boto3
from datetime import datetime, timedelta

cloudwatch = boto3.client('cloudwatch', region_name='us-east-1')

INSTANCE_ID = 'i-0abc1234def56789'

def get_metric_stats(metric_name, period_hours=24):
    end_time = datetime.utcnow()
    start_time = end_time - timedelta(hours=period_hours)

    response = cloudwatch.get_metric_statistics(
        Namespace='AWS/EC2',
        MetricName=metric_name,
        Dimensions=[{'Name': 'InstanceId', 'Value': INSTANCE_ID}],
        StartTime=start_time,
        EndTime=end_time,
        Period=3600,  # 1-hour granularity
        Statistics=['Average', 'Maximum']
    )
    return response['Datapoints']

# Collect baseline metrics
for metric in ['CPUUtilization', 'NetworkIn', 'NetworkOut', 'DiskReadOps', 'DiskWriteOps']:
    datapoints = get_metric_stats(metric)
    if datapoints:
        avg = sum(d['Average'] for d in datapoints) / len(datapoints)
        maximum = max(d['Maximum'] for d in datapoints)
        print(f"{metric}: avg={avg:.2f}, max={maximum:.2f}")

Setting CloudWatch Alarms Post-Migration

# CPU alarm — alert if CPU stays above 80% for 15 minutes
aws cloudwatch put-metric-alarm \
  --alarm-name "MigratedServer-HighCPU" \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --dimensions Name=InstanceId,Value=i-0abc1234def56789 \
  --statistic Average \
  --period 300 \
  --evaluation-periods 3 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:migration-alerts \
  --region us-east-1

For comprehensive observability setup, refer to our AWS CloudWatch Monitoring guide.

12. Common Pitfalls in AWS Migrations

1. Windows Licensing Assumptions

MGN replicates the OS, but Windows licences are not automatically transferred. By default, AWS provides a new Windows licence included in the EC2 price. If you bring your own licence (BYOL) via Dedicated Hosts, you must configure this in the MGN Launch Template before cutover. Mixing up licensing post-cutover results in compliance violations or unexpected charges.

2. Underestimating Network Latency Impact

Applications that ran on a LAN with sub-1ms latency between application server and database server often break when database calls now cross a VPC subnet boundary or a VPN. Common symptoms: connection pool exhaustion, timeout errors, N+1 query performance collapse. Mitigate by placing application and database tiers in the same Availability Zone during initial migration, then optimise for multi-AZ resilience after stabilisation.

3. Skipping the Test Launch

Teams under schedule pressure often skip the test launch and cut over directly. This is the leading cause of migration-related outages. The test launch is free, non-disruptive, and takes 15 minutes. Always run it.

4. Insufficient IAM Permissions

MGN and DMS require specific IAM roles (AWSApplicationMigrationAgentPolicy, AmazonDMSVPCManagementRole, AmazonDMSCloudWatchLogsRole). Missing permissions cause silent failures — the agent appears healthy but replication stalls. Validate IAM with IAM Policy Simulator before starting agents.

5. Ignoring DNS TTL Before Cutover

If your application's DNS TTL is 3600 seconds (1 hour), clients will continue hitting the old IP for up to an hour after you update the record. Lower TTL to 60 seconds at least 24 hours before planned cutover, then restore it post-migration.

6. Not Planning for Multi-Account Migrations

Enterprise migrations frequently involve moving workloads from one AWS account to another, not just from on-premises. MGN supports cross-account migrations via IAM role delegation. If your target is a Landing Zone account, set up AWS Organizations and Control Tower first to ensure correct account structure, SCPs, and network connectivity (Transit Gateway, Direct Connect) are in place.

7. DMS CDC Gaps for Unsupported Data Types

DMS CDC relies on source database transaction logs. Some data types — Oracle XMLTYPE, SQL Server FILESTREAM, large BLOBs over 32 MB — are not supported in CDC mode. Identify these columns during the SCT assessment phase and migrate them via a separate bulk export/import process, not through DMS CDC.

8. Forgetting Security Group Egress Rules

New EC2 instances created by MGN inherit the security group specified in the Launch Template, but default egress rules may block outbound traffic your application needs. Common omissions: NTP (UDP 123), LDAP (TCP 389/636), SMTP (TCP 587). Audit required outbound connections during the test launch phase. See our AWS Security Best Practices for egress hardening patterns.