Discovery, MGN, VMware Cloud and the 7 Rs

By the end of this lesson you will be able to

• Name the 7 Rs of migration (retire, retain, relocate, rehost, replatform, repurchase, refactor), say what each one changes, and match each to its AWS tool.
• Plan a data centre move with AWS Application Discovery Service: choose between the Agentless Collector and the Discovery Agent, find hidden dependencies, and group servers into applications and waves.
• Explain how AWS Application Migration Service (MGN) rehosts servers: replication agent, staging area, continuous block-level replication, test launch, cutover, finalize and archive, and what each step costs in downtime and money.
• Tell MGN from Elastic Disaster Recovery, VM Import/Export and VMware Cloud on AWS, and pick the right one from the keywords of a question.
• Use VM Import/Export to bring OVA, VMDK, VHD and raw images in as AMIs and send EC2 instances back out, and know its limits.
• Know the 2024–26 changes: Migration Hub and Application Discovery Service closed to new customers, AWS Transform, MGN’s new name, Amazon EVS, and Amazon Linux 2’s end of support, and which answer the exam still expects.

#Why moving servers needs a plan

Moving one server to AWS is easy. Moving a data centre is not: a Dhaka bank may run 300 servers, some nobody remembers, some that only work if another server is reachable, some with licences tied to old hardware. Moving them one by one, in the wrong order, breaks things on salary day.

So AWS describes a migration in three phases:

1. Assess: what do we have, what would it cost in AWS, is it worth it? (A business case: Migration Evaluator, Application Discovery Service.)
2. Mobilize: detailed discovery of servers and dependencies, a decision per application (the 7 Rs below), a landing zone (accounts, network, security), and a plan of waves: groups of applications that move together.
3. Migrate and modernize: actually move each wave with the right tool (MGN for servers, DMS for databases in lesson 23.3, Snowball or DataSync for bulk data in lesson 23.5), then improve.

The exam asks about this in three ways: “which strategy” (the 7 Rs), “how do we plan” (Application Discovery Service), and “how do we move servers” (MGN, VM Import/Export, VMware Cloud on AWS). This lesson takes them in that order.

#The 7 Rs: seven ways to move an application

For every application, the team picks one of seven strategies. AWS’s list grew from Gartner’s 5 Rs to AWS’s 6 Rs, and then to 7 Rs when relocate was added. They are listed here from least to most change.

The look-alikes the exam plays with:

• Rehost vs replatform. Rehost changes nothing in the server: MGN copies the whole disk, OS included. Replatform keeps the code but changes the platform under it: a managed database (RDS, lesson 7.1) instead of MySQL on a VM, or Elastic Beanstalk instead of a hand-built Tomcat server.
• Replatform vs refactor. Replatform is a small optimisation; refactor is a redesign (a monolith split into Lambda functions or ECS services). Refactor costs the most up front and is chosen when the business needs scale, agility or features the old design cannot give.
• Rehost vs relocate. Rehost turns each server into an EC2 instance. Relocate moves VMware VMs to VMware running on AWS: no conversion, the same vCenter, the same operations.
• Retire vs retain vs repurchase. Retire: nobody needs it. Retain: it is needed, but stays where it is for now. Repurchase: it is needed, but as somebody else’s SaaS.

Try it: each case below hides a look-alike. Pick an R first, then read why the other one is wrong.

#Step 1: discover what you have

#Why discovery comes first

A migration plan built from an old spreadsheet goes wrong in three ways: a server nobody listed is left behind, a server is moved without something it depends on, and every server is given an EC2 instance as big as the old hardware even though it ran at 5% CPU. Discovery fixes all three with measured data.

AWS Application Discovery Service collects information about your on-premises servers so you can plan a migration:

• Configuration: hostname, OS, CPU count, memory, disks, IP and MAC addresses.
• Utilization: CPU, memory, disk and network use over time, so EC2 instances can be right-sized, not copied size for size.
• Dependencies: which processes run, and which server talks to which, on what port. This is the most important part for planning, because dependent servers must move in the same wave.

The data is stored encrypted in your home Region and shown in AWS Migration Hub, where you group servers into applications and plan waves. You can also export it (continuous export streams agent data to S3, where Athena can query it) or start from a CSV import of an existing inventory.

#Agentless Collector vs Discovery Agent

There are two ways to collect, and the difference is exactly what the exam tests:

The older Agentless Discovery Connector in the slides was replaced by the Agentless Collector; since 17 November 2025 the service no longer accepts data from Discovery Connectors.

#Step 2: rehost with AWS Application Migration Service (MGN)

#What MGN is

AWS Application Migration Service (MGN) is AWS’s main tool for rehost (lift-and-shift) migrations. It takes physical servers, virtual machines on any hypervisor (VMware, Hyper-V and others) and servers in other clouds and turns them into EC2 instances that boot natively on AWS, with no change to the application code. It supports a wide range of Windows and Linux versions and the databases and applications running on them (SAP, Oracle and SQL Server are common).

Its family tree matters for the exam:

• CloudEndure Migration: the company AWS bought in 2019; MGN is the “AWS evolution” of its replication technology.
• AWS Server Migration Service: the older, VM-only, snapshot-based tool. AWS discontinued it on 31 March 2022; MGN replaces it.
• AWS Transform MGN: since June 2026, the new name of the same service, reflecting its role as the replication engine behind AWS Transform. The console, the API and the aws mgn commands are unchanged, and exam questions still say “Application Migration Service (MGN)”.

#How the replication works

1. Install the AWS Replication Agent on each source server. It talks to the MGN service over TCP 443.
2. MGN builds a staging area in a subnet you choose: a few small, cheap replication servers and low-cost EBS volumes, one per source disk. Full-size servers are not running; that is why replication is cheap.
3. Initial sync: the agent copies every block of every disk to the replication servers over TCP 1500, encrypted in transit. The source server keeps working the whole time.
4. Continuous block-level replication: after the initial sync, only changed blocks are sent, so the staging copy stays seconds behind the source.
5. When you launch, MGN converts the disks so they boot on EC2 (drivers, boot loader, network) and creates the instance from your launch settings.

#Test, cutover, finalize

1. 1. Set the launch settings

   Each source server has an EC2 launch template (subnet, security groups, instance type, IAM role, tags; launch templates are explained in lesson 4.3) and MGN options such as right-sizing (pick an instance type from the source’s CPU and memory) and post-launch actions: Systems Manager documents that run on the new instance, for example installing the CloudWatch agent or removing old on-premises tools.

2. 2. Launch test instances

   A test launch creates EC2 instances from the latest replicated state while replication continues and the source keeps serving users. The team checks the application. If the test fails (wrong subnet, missing security group rule, a licence tied to the old hardware), fix it now: nothing is lost and no user noticed.

3. 3. Mark ready, then cut over

   After the test passes, the server is marked ready for cutover. In the cutover window: stop the application on the source, let the last blocks arrive, launch the cutover instance, switch DNS or the load balancer. Downtime is only this window, usually minutes.

4. 4. Finalize and archive

   When the new instance has run well for a while, finalize the cutover: replication stops and MGN deletes the staging resources, so their cost stops. Then mark the server as archived. Until you finalize, the untouched source is your rollback.

#What MGN costs

Every source server gets 2,160 free hours of MGN, which is 90 days of continuous replication, counted from when the agent is installed. Most servers finish well within that. After that, MGN charges per server per hour of replication. Separate from the service fee, you always pay for the AWS resources it creates: the replication servers and staging EBS volumes, and the test and cutover EC2 instances and their volumes. Finalizing promptly is how you stop the staging cost.

#MGN or Elastic Disaster Recovery?

MGN and AWS Elastic Disaster Recovery (DRS) (lesson 23.2) are built on the same CloudEndure replication technology: an agent, a staging area, continuous block-level replication, launch on EC2. They do different jobs.

The notes’ exam keyword “migrate physical/virtual servers to AWS for DR” mixes the two: migration → MGN, recovery → DRS.

#VM Import/Export

VM Import/Export moves virtual machine images between your virtualization environment and EC2, through S3. It is a free feature; you pay only for the S3 storage and the EBS snapshots and instances it creates.

Import (ec2 import-image, or import-snapshot for a single disk):

• Accepted formats: OVA (a whole VM, can hold several disks), stream-optimized VMDK (VMware vSphere), VHD and VHDX (Hyper-V, also Azure and Citrix Xen) and raw images.
• Flow: export the VM from your hypervisor → upload the file to S3 → call import-image with a service role named vmimport that may read the bucket → the service converts it → you get an AMI (or an EBS snapshot) and launch instances from it (AMIs, lesson 4.3).
• Limits: only operating systems on the supported list (most Windows Server and Linux versions); no VMs created by physical-to-virtual conversion; no Arm-based images.

Export (ec2 create-instance-export-task, or export an AMI):

• Output formats: OVA, VMDK or VHD, written to an S3 bucket in the same account (SSE-S3 or unencrypted; not SSE-KMS).
• You cannot export an instance that contains AWS-provided third-party software (Windows or SQL Server from AWS AMIs, Marketplace images), one with encrypted EBS snapshots, more than one disk or more than one network interface, or volumes over 1 TiB.

When to use it rather than MGN: a one-off image (a vendor appliance shipped as an OVA, a golden VM built on premises), a DR repository of VM images kept in AWS (see the slides’ use case), or taking a workload back on premises. When the servers are live, numerous, physical, or must keep running until cutover, use MGN.

#VMware Cloud on AWS

#What it is

Many companies have run VMware for years: vSphere (the hypervisor and its hosts), vCenter (management), vSAN (storage) and NSX (networking), and their IT team knows these tools well. VMware Cloud on AWS runs that same VMware stack, as a software-defined data center (SDDC), on dedicated AWS bare-metal hosts in an AWS Region. VMware (now Broadcom) operates the stack; AWS provides the hardware.

• Same tools, no retraining. The team manages the SDDC with the same vCenter, often linked to the on-premises one.
• No conversion. VMs move as VMware VMs. With VMware HCX they can move live with vMotion (no reboot, same IP address on a stretched network) or in bulk (replicate, then reboot once at a planned time).
• AWS services next door. The SDDC is connected to a VPC in your own account, so VMs can use S3, RDS, FSx, Redshift and other services privately (FSx already lists VMware Cloud on AWS as a client, lesson 12.2).

Use cases, in the slides’ order: migrate vSphere workloads to AWS (this is the relocate R), extend a data centre and run production across private and public VMware clouds (hybrid), and keep a disaster recovery site on AWS.

#Choosing the tool from the question

A typical full answer combines them: discover with Application Discovery Service, rehost the application servers with MGN, move the database with DMS, ship the file archive on Snowball, and connect the sites with Site-to-Site VPN or Direct Connect while the waves run.

#What goes wrong

• Hidden dependencies. A server moved without one it calls (an SMS gateway, a licence server, a file share) fails in production. Run Discovery Agents long enough to see monthly and quarterly jobs, then move dependent servers in the same wave.
• Sizing copied, not measured. Old 32-core hosts copied to 32-vCPU instances waste money. Use utilization data and MGN right-sizing, then adjust after cutover.
• Wrong launch settings. A default launch template puts the instance in the wrong subnet or security group; the test launch catches it. Never skip the test.
• Replication lag at cutover. A slow or shared link, or a source that writes faster than the link carries, keeps lag high, so the cutover window grows. Sync weeks ahead, add bandwidth (VPN or Direct Connect), cut over on a quiet day.
• Licences and hardware ties. Software licensed to a MAC address, a dongle or a host ID may refuse to start on EC2. Check with the vendor before cutover; consider Dedicated Hosts for bring-your-own-licence rules.
• Forgetting to finalize. Staging servers and volumes keep costing money after cutover until you finalize, and the 90 free days of MGN run out for servers left replicating.
• Wrong tool. VM Import for physical servers (not supported), VMware Cloud on AWS for Hyper-V (needs VMware), DRS for a one-time migration (it is for recovery), Server Migration Service in a new design (discontinued).

#Try it yourself

These commands use AWS CLI v2. The account, IDs and names are examples. MGN must be initialized in the Region once (from the console) before the aws mgn commands work.

# 1. Application Discovery Service: see the agents and start collecting
aws discovery describe-agents --region ap-southeast-1
# { "agentsInfo": [ { "agentId": "o-0123456789abcdef0", "hostName": "payroll-app",
#     "agentType": "EC2", "health": "HEALTHY", "collectionStatus": "STOPPED" }, ... ] }
aws discovery start-data-collection-by-agent-ids --agent-ids o-0123456789abcdef0
aws discovery start-continuous-export      # agent data streams to S3, ready for Athena
# { "exportId": "export-1234567890abcdef0", "s3Bucket": "aws-application-discovery-service-111122223333-example",
#   "dataSource": "AGENT", "startTime": "2026-11-01T10:00:00Z" }

# 2. MGN: list source servers and their lifecycle state
aws mgn describe-source-servers --region ap-southeast-1 \
  --query 'items[].{id:sourceServerID,host:sourceProperties.identificationHints.hostname,state:lifeCycle.state}'
# [ { "id": "s-1234567890abcdef0", "host": "results-01", "state": "READY_FOR_TEST" } ]

# 3. Launch a test instance, then mark the server ready for cutover once the test passes
aws mgn start-test --source-server-ids s-1234567890abcdef0
aws mgn change-server-life-cycle-state --source-server-id s-1234567890abcdef0 \
  --life-cycle state=READY_FOR_CUTOVER

# 4. Cut over, then (after a quiet week) finalize and archive
aws mgn start-cutover --source-server-ids s-1234567890abcdef0
aws mgn finalize-cutover --source-server-id s-1234567890abcdef0
aws mgn mark-as-archived --source-server-id s-1234567890abcdef0

# 5. VM Import: bring an OVA from S3 in as an AMI and watch the task
aws ec2 import-image --description "billing appliance" \
  --disk-containers '[{"Format":"ova","UserBucket":{"S3Bucket":"vm-images-example","S3Key":"billing.ova"}}]'
# { "ImportTaskId": "import-ami-0123456789abcdef0", "Status": "active", "Progress": "1" }
aws ec2 describe-import-image-tasks --import-task-ids import-ami-0123456789abcdef0 \
  --query 'ImportImageTasks[0].[Status,StatusMessage,ImageId]'
# [ "completed", null, "ami-0abcd1234example" ]

# 6. VM Export: send an imported instance back out as an OVA
aws ec2 create-instance-export-task --instance-id i-0abcd1234example --target-environment vmware \
  --export-to-s3-task DiskImageFormat=VMDK,ContainerFormat=ova,S3Bucket=vm-images-example,S3Prefix=exports/
# { "ExportTask": { "ExportTaskId": "export-i-0123456789abcdef0", "State": "active" } }

Remember to finalize or disconnect test servers in MGN and delete test AMIs and snapshots when you finish, or the staging resources keep billing.

#Summary

Key takeaways

• The 7 Rs: retire (switch off), retain (keep for now), relocate (VMware to VMware Cloud on AWS), rehost (lift and shift with MGN), replatform (swap a part for RDS or Beanstalk), repurchase (buy SaaS), refactor (rebuild cloud-native).
• Application Discovery Service plans the move: configuration, utilization and, with the Discovery Agent, processes and network dependencies; the Agentless Collector gives VMware inventory and performance without agents. Results are grouped in Migration Hub.
• MGN rehosts physical, virtual and cloud servers to EC2: agent → staging area (cheap replication servers and EBS) → continuous block-level replication → test → cutover (minutes of downtime) → finalize → archive. 90 days free per server; staging and instances are billed.
• MGN replaced CloudEndure Migration and Server Migration Service (discontinued March 2022); since June 2026 it is also called AWS Transform MGN. MGN migrates, DRS protects: same technology, different job.
• VM Import/Export turns OVA, VMDK, VHD/VHDX and raw images in S3 into AMIs, and exports instances as OVA, VMDK or VHD; no physical-to-virtual images, no export of AWS-licensed Windows.
• VMware Cloud on AWS keeps vCenter, vSphere, vSAN and NSX on AWS bare metal, moves VMs live with HCX and vMotion, and is the answer for “keep VMware tools, no retraining”. AWS stopped reselling it in 2024; Amazon EVS (2025) runs VMware Cloud Foundation in your VPC.
• Since November 2025, Migration Hub and Application Discovery Service are closed to new customers, with AWS Transform as the successor; the exam answer for discovery is still Application Discovery Service.

Self-check: server migration30 questions