Migration & Transfer
Moving servers, databases, and large datasets from on-premises environments into AWS.
AWS Application Discovery Service
Collects inventory, utilization, and dependency data from on-premises servers so you can plan a migration.
- Discovery only — it measures your data center, it never moves a workload
- Agentless Collector: OVA deployed once into VMware vCenter, any guest OS, ~60-min samples — no running processes, no network dependencies
- Discovery Agent: installed per server (Windows/Linux, VM or physical), ~15-sec samples, adds running processes and TCP connections — and it's the only source that exports to Athena
- Everything lands in your Migration Hub home Region — set the home Region first or nothing collects. Quotas: 1,000 active agents, 400 servers per application
- Reality check: closed to new customers since 7 Nov 2025, superseded by AWS Transform (Migration Hub closed the same day). Exams still test the classic model
Exam triggers
Phrases and scenarios that point here.
- "We don't know what's running in our data center", "assess before migrating", "map dependencies" → Application Discovery Service
- Right-size EC2 from real on-prem CPU/RAM usage rather than matching old specs → discovery data feeds the sizing
- Needs running processes or server-to-server connections → Discovery Agent, not Agentless Collector
- VMware vCenter, hundreds of VMs, "can't install anything on each host" → Agentless Collector
Not this service
- Actually moving the servers → AWS Application Migration Service (MGN)
- One console to track migration progress across tools → AWS Migration Hub
- A cost/TCO business case for finance → Migration Evaluator
Use cases
- A retailer with a 400-VM VMware estate and a CMDB nobody trusts — one collector appliance produces a real inventory in days instead of chasing spreadsheets from six teams
- Right-sizing before lift-and-shift: the boxes were bought for peak 2017 traffic, so actual utilization picks the EC2 family instead of copying old specs 1:1
- Untangling a legacy app with no owner — agent-collected TCP connections expose the forgotten license server it calls nightly, so it isn't stranded on-prem in wave 1
- Building migration waves: group servers that talk to each other into one application so they move together, instead of stretching a chatty dependency across the WAN mid-cutover
- Feeding a cost model — export utilization time-series to Athena or Excel and price the same fleet on EC2 before anyone signs the business case
Commonly confused with
Verified against AWS documentation · 2026-09-09
AWS Application Migration Service (MGN)
Automated lift-and-shift service that replicates whole servers into AWS and relaunches them as EC2 instances.
- Rehost, don't rewrite — an agent copies each disk block-by-block into a staging area, then MGN converts the replica into a bootable EC2 instance
- The source server keeps running the whole time; replication is continuous, so cutover is a final sync and a DNS switch — minutes, not a lost weekend
- Test instances launch from the replica as often as you like without touching the source, which stays live as your rollback
- Limits: free for 2,160 replication-hours (~90 days) per server, 150 concurrently replicating servers by default, x86 Windows/Linux only
- Reality check: AWS renamed this "AWS Transform MGN" in 2026 — same API, same service. The CLF-C02 exam guide still calls it AWS Application Migration Service
Exam triggers
Phrases and scenarios that point here.
- "Lift and shift", "rehost", "migrate as-is", "no application changes", "minimal downtime"
- Physical servers, VMware, Hyper-V, or another cloud need to become EC2 instances → MGN
- Data center lease expiring, hundreds of mixed servers, no time to re-architect → MGN
- Must prove the app runs on AWS before committing → MGN test instances, then cutover
Not this service
- Moving database contents, or switching engines (Oracle → Aurora) → DMS
- Only tracking migration progress across tools and teams → Migration Hub
- Inventorying and dependency-mapping the data center first → Application Discovery Service
- Copying files or objects rather than whole servers → DataSync, or Snow Family when the pipe is too slow
- Keeping a warm standby for disaster recovery instead of a one-way move → Elastic Disaster Recovery (DRS)
Use cases
- Data center lease ends in six months and 300 mixed Windows/Linux VMs have to be on EC2 before the doors close — no budget to rewrite any of them
- A vendor application nobody has the source code for, built by people who left years ago; the running server is the only documentation, so you move the server itself
- Leaving another cloud provider — replicate the VMs into AWS while they keep serving live traffic, then cut over on a quiet Sunday night
- Post-acquisition consolidation: moving EC2 instances between Regions or into the parent company's account using the same agent-based flow
- Rehearsing the cutover — launch test instances, let the app team log in and break things, delete them, repeat, all without the source server noticing
Commonly confused with
Verified against AWS documentation · 2026-09-09
AWS Database Migration Service
Managed service that moves databases into AWS and keeps them in sync until you cut over.
- The source database stays online and serving traffic — you cut over only once the target has caught up
- Same engine (MySQL → RDS MySQL) is a straight data move; different engines (Oracle → Aurora PostgreSQL) need schema conversion first, via DMS Schema Conversion or the downloadable AWS SCT
- Three task types: full load (one-time copy), CDC (ongoing changes only), full load + CDC (copy, then stay in sync)
- Runs on a replication instance you size and manage, or DMS Serverless which picks and scales capacity for you
- Reality check: DMS Fleet Advisor, the fleet discovery feature, hit end of support on 20 May 2026 — pre-2026 study material still lists it
Exam triggers
Phrases and scenarios that point here.
- "Migrate a database to AWS" + "minimal downtime" → DMS
- Source and target engines differ → convert the schema first (DMS SC or AWS SCT), then DMS moves the data
- "Keep both databases in sync during cutover" / phased migration → DMS with CDC
- Continuously replicate production tables into Redshift or S3 for analytics → DMS, not a nightly export script
Not this service
- Moving whole servers or VMs, not just their data → AWS Application Migration Service (MGN)
- Copying files, file shares, or S3 objects → AWS DataSync
- Petabytes with no network that can carry them → AWS Snow Family
- Tracking overall migration progress across teams and tools → AWS Migration Hub
Use cases
- Weekend cutover of a self-managed MySQL on EC2 into RDS — full load runs Friday night, CDC keeps it current, you swap the connection string Sunday
- Escaping commercial database licensing: SCT converts the Oracle schema to Aurora PostgreSQL, DMS moves the rows
- Standing up a reporting copy — replicate live tables into Redshift or S3 so analysts stop hammering the transactional database
- Data centre exit: consolidating a dozen small on-prem databases into a handful of RDS instances without rewriting the apps
- Running old and new systems side by side during a phased rewrite, with CDC keeping both databases current until the last service moves
Commonly confused with
Verified against AWS documentation · 2026-09-09
AWS Elastic Disaster Recovery
Continuously replicates your servers into AWS so you can boot them as EC2 instances minutes after your primary site dies.
- An agent on each source server streams block-level changes into a low-cost staging area in your AWS account — EBS volumes and small replication servers, not an idle copy of production
- RPO in seconds, RTO in minutes; DRS converts the disks to boot natively on EC2 at launch time, so there's no replatforming
- Sources: on-prem physical servers, VMware/Hyper-V, another cloud, or EC2 instances in another Region or AZ
- Point-in-time recovery — launch from an earlier snapshot instead of the latest state (default 7 days of daily points, adjustable 1–365)
- Naming check: DRS is the successor to CloudEndure Disaster Recovery, retired for most customers in 2024 — older study material still says CloudEndure
Exam triggers
Phrases and scenarios that point here.
- "Minimize downtime and data loss", "RPO of seconds", "RTO of minutes", "disaster recovery to AWS"
- On-premises servers must come back up in AWS without rebuilding or re-architecting them → DRS
- DR standby required, but paying for a duplicate running environment is not → DRS staging area, not a hot standby
- Ransomware or data corruption, need to roll back to a known-good moment → DRS point-in-time recovery
- "Test the DR plan regularly without disrupting production" → DRS drills
Not this service
- Restorable copies of data, hours of RPO/RTO acceptable → AWS Backup
- One-way move to AWS with the source decommissioned afterwards → AWS Application Migration Service (MGN)
- Routing traffic and checking readiness for an app already running in multiple Regions → Route 53 Application Recovery Controller
Use cases
- A distributor running its warehouse system on two racks in the back office keeps a warm copy in a Region, so a burst pipe upstairs costs hours of downtime instead of weeks
- Quarterly DR drills for auditors — launch the whole recovery fleet into an isolated VPC, capture the proof, delete it, and production never notices
- Ransomware rollback — recover to a point in time from before the encryption started, rather than discovering last night's backup is already infected
- Cross-Region cover for EC2 workloads built single-Region that can't be re-architected for active-active before the compliance deadline
- Legacy Windows boxes nobody wants to touch — DRS copies the disks as-is, so nobody has to reinstall an app whose original engineer left in 2014
Commonly confused with
Verified against AWS documentation · 2026-09-09
AWS Migration Hub
Single dashboard to discover on-premises servers, group them into applications, and track migration progress across every tool you're using.
- Tracks migrations, doesn't perform them — MGN, DMS, and partner tools do the moving; Migration Hub just aggregates their status
- Discovery data comes from Application Discovery Service; you group discovered servers into applications, then track progress per application
- Home Region: one Region stores all tracking data, but you can migrate into any Region — changing the home Region afterward requires an AWS Support ticket
- Reality check: closed to new customers since Nov 7, 2025, replaced by AWS Transform. Existing migrations run unaffected, and CLF-C02 still expects you to know it
Exam triggers
Phrases and scenarios that point here.
- "Single pane of glass", "central dashboard", "visibility across migration tools", "track progress in one place"
- Several teams using different migration tools, leadership wants one status view → Migration Hub
- Migrations landing in multiple Regions, one console to watch them → home Region aggregates all of it
- "What servers do we have and what talks to what?" before any migration → Application Discovery Service feeding Migration Hub
Not this service
- Actually moving servers → Application Migration Service (MGN); moving databases → Database Migration Service (DMS)
- Building the cost case before committing to migrate → Migration Evaluator
- Starting a brand-new migration program today → AWS Transform
Use cases
- A data centre exit where the Windows team uses MGN, the DBA team uses DMS, and the steering committee needs one number for 'how far along are we' — Migration Hub is that screen
- Wave planning: group the twelve servers behind one ERP into a single application, migrate the wave, mark it complete, move to the next — instead of chasing individual hostnames
- A regional rollout where the EU app lands in Frankfurt and the APAC app lands in Singapore, both watched from one home Region console
- Catching the forgotten license server in discovery data before it takes down the application at cutover weekend
- Giving finance or an auditor portfolio-level progress instead of three tool-specific spreadsheets that never quite reconcile
Commonly confused with
Verified against AWS documentation · 2026-09-09
AWS SCT
Downloadable tool that converts database schema and code from one engine to another before the data moves.
- SCT converts the structure — tables, views, stored procedures, functions, triggers. DMS moves the rows
- Only needed for heterogeneous migrations (Oracle → Aurora PostgreSQL). Same engine both sides needs no conversion
- Assessment report grades the job up front and marks exactly what won't convert automatically
- Reality check: AWS now points you to DMS Schema Conversion (managed, in-console) first — SCT is the download for paths it doesn't cover
Exam triggers
Phrases and scenarios that point here.
- "Different database engine", "heterogeneous migration", "Oracle to PostgreSQL" → SCT + DMS
- Stored procedures, views, or triggers must come across → SCT, not DMS alone
- "Estimate the migration effort before committing" → SCT assessment report
- Same engine on both sides (MySQL → RDS MySQL) → DMS alone, SCT is the wrong answer
Not this service
- Moving the actual data → AWS DMS
- Migrating whole servers or VMs, not databases → AWS Application Migration Service
Use cases
- A team sitting on Oracle with 900 PL/SQL stored procedures wants Aurora PostgreSQL — SCT converts what it can and hands back a list of what a human has to rewrite
- Scoping a migration before anyone promises a date: run the assessment report to turn "how hard is this?" into a count of objects and hours
- Teradata or Netezza warehouse → Redshift, with SCT data extraction agents pulling data locally and staging it through S3 (or onto a Snowball device when the pipe is too slow)
- Escaping commercial database licensing — convert SQL Server to Aurora PostgreSQL so the license line disappears from the bill
- Converting embedded SQL inside Java, C#, or C++ application code so the app doesn't break the day the database underneath it changes
Commonly confused with
Verified against AWS documentation · 2026-09-09
Migration Evaluator
Free pre-migration assessment that turns your on-premises inventory into a projected AWS bill and a business case.
- Free, assessment-only (formerly TSO Logic) — it prices and justifies a migration, it never moves a server
- Two ways in: agentless collector (one Windows VM, read-only over WMI/SNMP/vSphere/T-SQL) or upload inventory you already have
- Quick Insights = fast projected EC2, EBS and OS licence costs; Business Case = deeper report built with an AWS Migrations SA
- Prices from measured utilisation, not provisioned specs — so it right-sizes instead of copying oversized on-prem servers
Exam triggers
Phrases and scenarios that point here.
- "Build a business case", "justify the move to leadership", "TCO before we commit"
- "What would our on-prem servers cost on AWS?" — asked before anything has moved
- Windows/SQL Server-heavy estate and licensing is the cost question → models BYOL vs licence-included
- "Complimentary", "no cost", "free" attached to a migration assessment → Migration Evaluator
Not this service
- Costing an architecture you're designing but don't run yet → AWS Pricing Calculator
- Actually rehosting the servers → AWS Application Migration Service (MGN)
- Server dependency mapping and migration progress tracking → Application Discovery Service + Migration Hub
Use cases
- A CFO won't approve a data centre exit until someone shows what the same 400 VMs cost on AWS — this produces that number from measured usage instead of a spreadsheet guess
- Data centre lease renews in 18 months and the team needs a defensible cost comparison before signing or walking away
- A retailer whose estate is mostly Windows and SQL Server wants the licensing decision made on modelled numbers rather than vendor pressure
- Servers were sized for a peak that never came back — the report exposes the gap between provisioned and used, so the AWS estimate isn't a like-for-like copy of oversized hardware
- A company already runs third-party discovery tooling (or Application Discovery Service) — upload those exports instead of installing anything new
Commonly confused with
Verified against AWS documentation · 2026-09-09