Cargando...
Cargando...
Automate rehosting of physical, virtual, and cloud servers to AWS with minimal downtime and zero application changes
AWS Application Migration Service (MGN) is the primary AWS service for lift-and-shift (rehost) migrations, enabling you to migrate physical servers, virtual machines, and cloud instances to AWS without modifying the source applications. It uses continuous block-level replication to keep source servers in sync with AWS until cutover, minimizing downtime to minutes. MGN replaces the older CloudEndure Migration service and is the recommended migration path for large-scale rehosting scenarios.
Automate large-scale rehosting migrations to AWS by continuously replicating source servers and enabling rapid, low-downtime cutovers without requiring application refactoring or schema conversion
Use When
Avoid When
Continuous block-level replication
Replicates all storage changes in real-time to a staging area in AWS, enabling near-zero RPO
Automated launch templates
Generates EC2 launch templates based on source server specs; can customize instance type, VPC, subnet, security groups before launch
Test mode (non-disruptive testing)
Launch test instances from replicated data without interrupting source server or replication — critical for validation before cutover
Integration with AWS Migration Hub
Track migration progress centrally across all migration tools in a single pane of glass
Post-launch actions (automation)
Run SSM documents or custom scripts automatically after launch for configuration, patching, or validation
Multi-region support
Replicate to any supported AWS Region; useful for migrating to geographically appropriate regions
Application grouping (wave planning)
Group servers into applications and migration waves for orchestrated, ordered cutovers
Database schema conversion
MGN does NOT convert schemas — use AWS SCT + DMS for database migrations; this is a top exam misconception
Application discovery / dependency mapping
MGN does NOT discover servers — use AWS Application Discovery Service (ADS) before MGN for inventory and dependency mapping
Cross-account replication
Supports replicating source servers to a different AWS account than where the agent is registered
Agentless replication (vCenter)
MGN supports agentless replication for VMware vCenter environments using the MGN vCenter client, in addition to agent-based replication
Bandwidth throttling
Replication bandwidth can be throttled to avoid saturating production network links
CloudWatch metrics and alarms
Replication lag, backlog, and health metrics published to CloudWatch for monitoring
Centralized Migration Tracking
high freqMGN automatically reports migration status to AWS Migration Hub, providing a single dashboard to track all servers across multiple migration tools (MGN, DMS, etc.) in one place. Use this pattern for enterprise migrations with mixed workload types.
Discover-then-Migrate Pipeline
high freqADS (with Discovery Agent or Agentless Collector) discovers on-premises servers, maps dependencies, and exports inventory to Migration Hub. MGN then handles the actual replication and cutover. ADS does NOT migrate — it only discovers. This two-phase pattern is the recommended AWS migration approach.
Application + Database Migration (Separate Tools)
high freqMGN migrates the application servers (OS, application binaries, configuration) via block-level replication. DMS separately handles database replication, especially for heterogeneous database migrations. These two services are complementary, not interchangeable — a critical exam distinction.
Target Launch Configuration
high freqMGN launches test and cutover instances as standard EC2 instances using customizable launch templates. You choose instance type, VPC, subnet, security groups, and IAM instance profile. The resulting servers are plain EC2 instances — no MGN dependency post-cutover.
Complementary Data Transfer
medium freqDataSync handles file-level data transfer (NFS, SMB shares, S3) while MGN handles server replication (block-level). For migrations involving both application servers AND large file shares, use MGN for servers and DataSync for file data. They solve different problems and are not interchangeable.
Post-Launch Automation
medium freqMGN's post-launch actions framework executes SSM documents automatically after a server is launched in AWS. Use this to install agents, apply patches, configure monitoring, or run validation scripts without manual intervention after cutover.
Infrastructure-as-Code Launch Templates
low freqMGN launch templates can be managed and versioned using CloudFormation, enabling consistent, repeatable infrastructure configuration for migrated servers. Useful in large-scale migrations where standardization is required.
MGN = Rehost (lift-and-shift) ONLY. It replicates servers as-is at the block level. It does NOT convert applications, modernize code, convert database schemas, or discover infrastructure. Any question asking about schema conversion, application refactoring, or server discovery is pointing to a DIFFERENT service.
The 90-day free tier per source server is a PRICING TRAP. MGN is free for 90 days per server, then charges apply. Exam questions about cost-optimizing migrations often hinge on knowing this window. Always plan cutovers within 90 days to minimize MGN service costs.
MGN and AWS Application Discovery Service (ADS) are SEQUENTIAL, not interchangeable. ADS discovers and maps dependencies BEFORE migration. MGN replicates and migrates AFTER discovery. Questions that describe 'discovering server dependencies' should map to ADS, not MGN.
For database migrations, MGN + DMS is the correct combined answer. MGN handles the application server layer; DMS handles database replication (especially heterogeneous). A question describing migrating 'an Oracle database to Aurora PostgreSQL' needs DMS + SCT, NOT MGN.
MGN = Rehost (lift-and-shift) ONLY. It does NOT do schema conversion (DMS+SCT), server discovery (ADS), application assessment (Migration Evaluator), or file transfer (DataSync). Any exam scenario involving these capabilities points to a different service.
The 90-day free window per server is the #1 MGN pricing fact. After 90 days, per-server charges apply. For cost-optimized migrations, complete cutovers within this window. Hidden costs include EC2 replication servers and EBS staging volumes — always account for these in TCO calculations.
The correct full migration stack for mixed workloads: ADS (discover) → Migration Hub (track) → MGN (rehost app servers) + DMS/SCT (migrate databases) → Systems Manager (post-launch automation). MGN is one piece, not the whole puzzle.
MGN replaces CloudEndure Migration — if you see CloudEndure in exam questions, treat it as legacy. MGN is the current AWS-native recommended service for large-scale rehosting. CloudEndure Migration is no longer the recommended path.
MGN supports BOTH agent-based replication (install agent on source server) and agentless replication (via VMware vCenter connector). For VMware environments, agentless is often preferred. Know both modes exist — exam questions may test which is applicable for a given scenario.
Cutover time is MINUTES, not hours. This is a key differentiator when exam questions ask you to choose a migration approach with minimal production downtime. MGN's continuous replication means the AWS copy is always nearly up-to-date, so cutover only requires a brief sync and DNS/load balancer switch.
Hidden costs in MGN: (1) EC2 replication server instances in your account, (2) EBS staging area volumes, (3) data transfer costs for replication traffic, (4) EC2 costs for test and cutover instances. Exam questions on migration TCO often test whether you account for ALL these costs, not just the MGN service fee.
AWS Migration Hub is the TRACKING layer — it aggregates status from MGN, DMS, and other tools. If a question asks 'how do you get a single view of all migration progress across tools,' the answer is Migration Hub, not MGN itself.
Post-launch actions in MGN use AWS Systems Manager (SSM) documents. This enables automated post-migration configuration (install monitoring agents, apply patches, configure software) without manual steps. For exam scenarios requiring automated post-migration configuration, MGN + SSM is the correct pattern.
Common Mistake
AWS Application Migration Service can migrate databases, including converting schemas from one database engine to another (e.g., Oracle to PostgreSQL)
Correct
MGN performs block-level server replication and has NO understanding of database schemas or query languages. Database migration requires AWS Database Migration Service (DMS) for data replication and AWS Schema Conversion Tool (SCT) for schema conversion. MGN only migrates the OS and application layer.
This is the #1 exam trap for MGN. The word 'migration' in the service name causes candidates to assume it handles all migration types. Remember: MGN = server replication only. Any database schema work → DMS + SCT. Exam questions often present a scenario with both app servers AND a database, expecting you to select BOTH MGN (for servers) AND DMS (for database).
Common Mistake
AWS Application Migration Service includes server discovery and dependency mapping capabilities, so you can use it as the first step in a migration project
Correct
MGN does NOT discover servers or map application dependencies. Discovery must be performed FIRST using AWS Application Discovery Service (ADS) with either the Discovery Agent (detailed data) or Agentless Collector (VMware). Only after understanding your inventory and dependencies should you configure MGN to begin replication.
Candidates see 'Application Migration Service' and assume it covers the full migration lifecycle. In reality, MGN starts at the replication phase. The correct sequence is: Discover (ADS) → Plan (Migration Hub) → Migrate (MGN/DMS) → Optimize. Missing this sequence leads to wrong answers on questions about migration phases.
Common Mistake
Moving servers to AWS with MGN automatically reduces software licensing costs because cloud licenses are cheaper
Correct
MGN performs a lift-and-shift migration — it moves the existing server and its software as-is to EC2. Existing software licenses (Windows Server, SQL Server, Oracle, etc.) still apply and may require Bring Your Own License (BYOL) agreements. Licensing costs do NOT automatically decrease. In some cases, they may increase if not properly planned (e.g., moving from per-socket to per-vCPU licensing).
This misconception appears in cost-optimization questions. MGN reduces migration complexity and downtime, but licensing is a separate concern. For licensing optimization, candidates should know about AWS License Manager, Dedicated Hosts for BYOL, and the difference between license-included and BYOL EC2 instances.
Common Mistake
MGN and AWS DataSync are interchangeable — both can be used to migrate servers and their data to AWS
Correct
MGN and DataSync serve completely different purposes. MGN performs block-level server replication (entire OS + applications + data) for rehosting servers. DataSync transfers files and objects between storage systems (NFS, SMB, S3, EFS, FSx). DataSync cannot migrate a running server; MGN cannot selectively sync file shares. They are complementary, not interchangeable.
Both services involve 'moving data to AWS' which causes confusion. The key differentiator: MGN = entire server replication (block-level), DataSync = file/object data transfer. Use both together when a migration involves servers (MGN) AND separate file shares or NAS storage (DataSync).
Common Mistake
Optimizing network bandwidth is the most impactful way to reduce total migration costs when using MGN
Correct
While bandwidth optimization (throttling, compression, Direct Connect) does reduce data transfer costs, the bigger cost drivers in MGN migrations are EC2 instance costs for replication servers, EBS staging volume costs, and most importantly, the TARGET EC2 instance types chosen for migrated servers. Right-sizing the target instances has a far greater long-term cost impact than bandwidth optimization.
Bandwidth is a one-time migration cost; EC2 instance costs for migrated servers are ongoing. Exam questions testing cost optimization expect you to prioritize right-sizing (using AWS Compute Optimizer recommendations post-migration) over network-level optimizations. Bandwidth matters, but it's not the dominant cost lever.
Common Mistake
AWS Application Migration Service provides an assessment of application compatibility and readiness for AWS before migration
Correct
MGN does NOT assess application compatibility or provide migration readiness reports. For migration assessment, use AWS Migration Evaluator (formerly TSO Logic) for business case analysis, AWS Application Discovery Service for dependency mapping, or the AWS Well-Architected Tool for architecture review. MGN's role begins AFTER the assessment phase.
The word 'assessment' in migration contexts is associated with multiple services. Remember: Assessment = Migration Evaluator / ADS. Replication = MGN. Tracking = Migration Hub. Each tool has a distinct phase in the migration lifecycle.
MGN = 'Move Gently Now' — it moves servers gently (without changes) to AWS. No schema changes, no code changes, no discovery — just gentle block-level replication.
The MGN lifecycle: DART — Discover (ADS), Assess (Migration Evaluator), Replicate (MGN), Track (Migration Hub). MGN is only the 'R' step.
MGN vs DMS: 'MGN Moves the Machine; DMS Deals with the Data (schema)' — MGN handles the server OS+app layer; DMS handles database records and schema conversion.
90-day rule: 'MGN gives you 90 days free — don't be late, or you'll pay by the plate (per server per hour)'
CertAI Tutor · SAA-C03, SAP-C02, DEA-C01, SCS-C02, CLF-C02 · 2026-02-22