# Cross-Cloud VM Migration: GCP → AWS Using AWS Application Migration Service (MGN) Cross-cloud VM migration is not a disk copy task. It is: * An access model transformation * A replication lifecycle management exercise * A downtime control operation * A cost boundary decision We executed a production-grade migration from Google Compute Engine to Amazon EC2 using AWS Application Migration Service (MGN) under strict operational constraints: * Target RPO ≈ 0 at cutover (achieved through application write freeze, replication validation, and successful final synchronization) * Downtime < 30 minutes * No SSH/RDP lockout * Controlled replication cost * Preserved rollback capability This article documents a technically precise, enterprise-review-safe execution model. * * * ## 1\. Why We Chose AWS MGN We evaluated: * Manual snapshot export/import * Image-based migration * Backup/restore workflows * Application rebuild We selected AWS MGN because: * Continuous block-level replication minimizes downtime * Test migrations do not impact production * Cutover is controlled and repeatable * No application redesign required (pure rehost model) This was lift-and-shift, not modernization. * * * ## 2\. What AWS MGN Actually Does AWS MGN is an agent-based block-level replication service. It: * Installs a replication agent on the source VM * Reads disk blocks at the operating system level * Continuously replicates encrypted data to AWS * Uses staging replication servers and EBS volumes * Launches test and cutover EC2 instances ### Critical Clarification MGN replicates disk state. It migrates: * Local OS users stored on disk * SSH configuration files stored on disk * Application binaries * System configuration It does not migrate: * GCP OS Login (IAM-based access) * Metadata-injected SSH keys * DNS records * Load balancers * Managed services (Cloud SQL, etc.) * IAM identities Any identity mechanism tied to GCP metadata or IAM must be replaced with persistent OS-level users or SSM-based access prior to cutover. * * * ## 3\. Migration Architecture ```plaintext GCP VM ↓ MGN Replication Agent ↓ Encrypted TLS Transfer ↓ AWS Staging Replication Server ↓ EBS Replication Volumes ↓ Launch Template ↓ Test EC2 Instance ↓ Cutover EC2 Instance ``` Replication continues until cutover. * Data encrypted in transit (TLS) * EBS encryption configurable at rest * Replication throughput depends on bandwidth, write churn, and staging configuration * * * ## 4\. MGN Lifecycle States (Operational Meaning) ### Not Ready Initial full replication in progress. ### Ready for Testing Initial synchronization complete. Continuous delta replication active. ### Test in Progress Test EC2 launched. Source VM continues running. ### Ready for Cutover Replication functioning correctly with minimal lag. ### Production Cutover Gate Proceed only if: * Migration lifecycle = Ready for cutover * Replication status = Healthy * Replication lag is negligible or zero Never execute cutover if replication is not Healthy. ### Cutover in Progress Final synchronization executing and EC2 launching. ### Cutover Complete AWS EC2 becomes the active production workload. * * * ## 5\. Primary Risk: Access Model Mismatch Default GCP access model: * OS Login (IAM-based) * Metadata-injected SSH * Console SSH Default AWS access model: * OS-level local users * SSH key pairs * SSM Session Manager These models are incompatible. If a VM relies exclusively on GCP OS Login or metadata-based SSH, administrative access will be lost after migration. * * * ## 6\. Mandatory Pre-Migration Access Preparation ### Linux Create a persistent administrative user: ```plaintext sudo useradd awsadmin sudo mkdir -p /home/awsadmin/.ssh sudo chmod 700 /home/awsadmin/.ssh sudo nano /home/awsadmin/.ssh/authorized_keys sudo chmod 600 /home/awsadmin/.ssh/authorized_keys sudo chown -R awsadmin:awsadmin /home/awsadmin sudo usermod -aG sudo awsadmin ``` Validate SSH access before migration. Attach IAM role: ```plaintext AmazonSSMManagedInstanceCore ``` This ensures emergency fallback access via Session Manager. * * * ### Windows * Enable local Administrator * Enable RDP * Allow TCP 3389 * Validate login before migration * * * ## 7\. Network Requirements ### On GCP VM (Outbound Required)

Port

Protocol

Purpose

443

TCP

AWS control plane communication

1500

TCP

Replication data channel

53

TCP/UDP

DNS (system prerequisite)

123

UDP

NTP (system prerequisite)

No inbound firewall rules are required on the source VM for MGN. ### On AWS If staging and target instances reside in private subnets, outbound connectivity must be provided via: * NAT Gateway * VPC Endpoints * Direct Connect * VPN NAT is required only if no internet access or VPC endpoints are configured. * * * ## 8\. Replication Consistency Model AWS MGN provides crash-consistent replication. To achieve near-zero RPO: 1. Freeze application writes 2. Confirm replication status = Healthy 3. Confirm replication lag ≈ 0 4. Execute cutover For database workloads, application quiescing is mandatory. MGN does not provide automatic application-consistent snapshots. * * * ## 9\. Replication Timing Reality Initial synchronization depends on: * Disk size * Network bandwidth * IOPS * Write churn Example (environment dependent): * 50 GB → 20–40 minutes * 200 GB → 1–2 hours * 1 TB → Dependent on available bandwidth Downtime is not determined by disk size. Downtime = write freeze duration + final synchronization time. * * * ## 10\. Cutover Execution Model Validated production sequence: 1. Freeze application writes 2. Confirm replication status = Healthy 3. Confirm lag negligible 4. Launch cutover instance 5. Stop GCP VM 6. Update DNS or routing Observed downtime: 5–30 minutes. * * * ## 11\. Rollback Strategy If validation fails: * Do not delete source VM * Restore DNS to GCP * Maintain replication configuration * Reattempt cutover Never decommission the source environment until fully validated. * * * ## 12\. Cost and Scale Considerations ### AWS Costs * Staging replication servers * EBS volumes * Snapshots * NAT (if used) * Data transfer ### GCP Cost * Network egress (primary cost driver) Large parallel migrations may: * Increase staging cost * Increase EBS consumption * Saturate bandwidth * Trigger API throttling Recommendation: Execute migrations in controlled waves. * * * ## 13\. When This Approach Makes Sense Suitable for: * Lift-and-shift * Data center exit * Legacy workload relocation * Time-constrained transitions Not suitable for: * Cloud-native redesign * Container migrations * Managed database modernization * Application refactoring * * * ## Final Engineering Conclusion AWS Application Migration Service is predictable when: * Access models are reconciled * OS compatibility is validated * Replication health and lag are monitored * Cutover is controlled * Rollback capability is preserved Most migration failures are not replication failures. They are planning failures. Cross-cloud VM migration is an operational engineering discipline — not a file transfer task.