"AWS migration services" means two different things: the AWS-native tool suite (MGN, DMS, SCT, Migration Hub, DataSync, Transfer Family) and the partner-delivered services that actually operate them (assessment, landing zone, cutover, modernization, optimization). This page maps both — what each tool is for, when to reach for it, how they fit together — and shows how a matched AWS partner runs the migration for you, MAP-funded toward little-to-no cost on qualifying workloads.
The phrase collapses two very different things. One is a free toolbox AWS hands you. The other is the human-delivered service that uses the toolbox to land your workloads safely. Conflating them is why most DIY migrations slip.
Someone searching "AWS migration services" is usually one of two people. The first is an engineer who needs to know which AWS tool moves a server, a database, or a petabyte of files — the native suite. The second is a CTO or VP Eng who needs the whole migration done — scoped, cut over, optimized — without pulling the platform team off the roadmap. This page gives both.
The AWS-native tools (MGN, DMS, SCT, Migration Hub, Application Discovery Service, DataSync, Transfer Family) are good and free to use — you pay only for the AWS resources they spin up. But a tool does not decide your strategy, design your account structure, sequence your cutover waves, or own the 2 a.m. rollback if replication lags. That work is the service — driven by either your team or a partner.
The honest DIY tradeoff: the tools have real learning curves (DMS heterogeneous migrations and SCT especially), and the failure modes — data drift during a long cutover, an under-built landing zone retrofitted for compliance later, an app rehosted that should have been replatformed — are expensive to discover in production. A partner-delivered service is where those calls are made by people who've made them a hundred times, and AWS funds it. The rest of this page is a menu: Sections II–IV are the native tools, V–VI the partner-delivered phases, VII the MAP funding tie-in.
You cannot migrate what you cannot see. Before MGN or DMS touches anything, two tools build the inventory and the control plane: Application Discovery Service maps the estate, Migration Hub tracks the whole program.
Every credible migration starts with discovery, and AWS gives you two free tools for it. Skipping this is the most common reason migrations blow their estimate — you find the forgotten dependency during cutover instead of during planning.
What it does: Collects server inventory, configuration, running processes, and network connections from your on-premise or existing-cloud environment, so you can group servers into applications and see what talks to what.
Two modes: the agentless collector (an OVA appliance for VMware vCenter — VM specs + utilization, no per-server install) and the agent-based collector (a per-host agent that also captures running processes and TCP/UDP connections — the dependency map you actually need to sequence waves).
When to use it: Any migration where you aren't certain which servers belong to which application, or where there are undocumented dependencies (i.e. almost every on-prem and legacy estate). Data flows into Migration Hub for grouping and the TCO view.
Honest limit: 2–6 weeks of collection is normal to capture monthly batch jobs and quarter-end spikes. Rushing discovery to a few days is how you miss the reporting job that only runs on the 1st.
What it does: Aggregates discovery data and live status from MGN, DMS, and partner tools into one console. Per application, you see what's discovered, replicating, cut over, and validated across every wave. In 2026 it also folds in Strategy Recommendations (suggests a 7-Rs disposition + target like ECS/App Runner/Aurora) and Refactor Spaces (incremental strangler-fig refactoring).
When to use it: Always, on multi-application migrations. It's the program-management surface — the report you show the steering committee and where a partner runs the wave plan from.
A 3–4 week discovery + assessment phase is where the migration estimate gets accurate and the nasty surprises surface on a slide instead of in production. Under MAP, the Assess phase (TCO model + readiness + 7-Rs dispositions) is typically AWS-funded — so the riskiest-to-skip phase is also the one that costs you nothing.
Once you know what to move, three tool families do the moving: MGN for whole servers, DMS + SCT for databases, and DataSync / Transfer Family for files and object data. Pick the wrong one and you either do far more manual work than necessary or introduce a longer cutover window than the workload can tolerate.
What it does: Block-level, agent-based replication of an entire server (OS, apps, config, data) into AWS. It continuously syncs the source into a staging area, then launches a production EC2 instance from the latest replica. This is AWS's recommended primary rehost tool (it succeeded the retired CloudEndure/SMS path).
When to use it: The 7-Rs Rehost ("lift-and-shift") and as the engine under Replatform. Ideal to move a server as-is with a cutover measured in minutes — continuous replication means the final cutover is "boot the already-replicated instance and flip DNS." You test-launch into an isolated subnet first, validate, then cut over in a short window.
Honest limit: MGN gives you the same server on AWS — same OS, same inefficiencies. It's the fast on-ramp, not modernization; right-sizing and replatforming happen after (or selectively instead).
What it does: The same MGN service applied to a VMware vSphere estate — agent-based replication of vCenter-managed VMs straight into EC2, for teams that want off the hypervisor layer entirely.
Decision rule: Want to leave VMware behind → MGN for VMware into native EC2 (a Rehost). Need to keep vSphere semantics short-term (licensing, ops muscle memory, a hard deadline) → Relocate the VMs into VMware Cloud on AWS, then modernize later.
What DMS does: Migrates databases with the source staying online. Its change-data-capture (CDC) mode does a full load then streams ongoing changes, so the cutover window stays small even on busy databases.
Homogeneous vs. heterogeneous: Homogeneous (PostgreSQL → RDS PostgreSQL, MySQL → Aurora MySQL) is straightforward — DMS handles it largely on its own. Heterogeneous (Oracle → Aurora PostgreSQL, SQL Server → Aurora) is the hard part: the engines differ, so you first run SCT to convert schema, stored procedures, and functions, fix what it flags as manual, then DMS moves the data.
When to use SCT: Only for heterogeneous migrations (changing the engine — usually to escape Oracle/SQL Server licensing for Aurora). Its assessment report grades how much converts automatically vs. needs hand-conversion — the most useful input to a realistic database-migration estimate.
Honest limit — where migrations get hard: Heterogeneous DB effort lives almost entirely in the application tier (PL/SQL → PL/pgSQL, query rewrites, ORM behavior, edge-case data types), not in DMS itself. Budget for application changes and a parallel-run validation period, not just the data copy.
DataSync — what it does: High-throughput, managed transfer of large file/object datasets (NFS, SMB, HDFS, object stores) into S3, EFS, or FSx, with integrity checks and scheduling. The tool for the petabyte of NAS data or analytics datasets sitting alongside the apps you're moving.
Transfer Family — what it does: Fully managed SFTP/FTPS/FTP (and AS2) endpoints in front of S3/EFS. When external partners push files to you over SFTP, you keep that exact interface while the storage moves to AWS — no client-side change for anyone sending you files.
When to use which: Moving your bulk data in → DataSync. Replacing an SFTP/file-exchange server while preserving the protocol → Transfer Family. They're complementary. (For offline-scale or low-bandwidth cases the Snow Family ships the data physically, but DataSync over Direct Connect or VPN covers most migrations.)
The tools aren't a menu you pick one from — they chain. Here is the canonical sequence a senior team runs and where each tool plugs in; the value of a partner is largely in orchestrating this cleanly across many applications at once.
Migration Hub sits across all of this as the tracking layer. The pattern that keeps migrations safe — small reversible waves with a warm rollback — is a delivery discipline, not a tool feature.
The tools are free; the expertise is the product. Partner-delivered AWS migration services are five phases that wrap the toolbox: assessment, landing zone, cutover, modernization, and post-migration optimization.
A vetted partner doesn't just operate MGN and DMS; they own the strategy, the foundation, the cutover risk, and the cost outcome. These five phases map cleanly onto AWS's MAP structure (Assess → Mobilize → Migrate & Modernize), which matters for funding (Section VII).
The partner runs Application Discovery Service, builds the inventory + dependency map, and produces a per-application 7-Rs disposition: Retire (turn it off — typically 10–20% of an old estate is dead weight), Retain, Rehost (lift-and-shift via MGN), Relocate (VMware Cloud on AWS), Repurchase (move to SaaS), Replatform (lift-tinker-shift — e.g. self-managed DB → RDS), or Refactor (re-architect, selectively, where ROI is clear).
They also build the TCO model (current run-cost vs. projected AWS cost) and a wave plan sequencing applications by dependency and risk. This is the deliverable that turns "we should move to AWS" into a costed, scheduled program. Under MAP, this whole phase is typically AWS-funded.
Before production workloads land, the partner builds a secure, multi-account landing zone: organizational structure (separate prod/non-prod/security/logging accounts), networking (VPCs, Direct Connect or VPN to the source, Transit Gateway), centralized IAM/SSO, logging and guardrails, and baseline cost controls — typically AWS Control Tower plus infrastructure-as-code. Getting this right up front is the difference between a migration that scales cleanly and one painfully retrofitted for compliance six months later.
The partner also runs a pilot here — one low-risk application migrated end-to-end to prove the tooling, the runbook, and the rollback before the harder waves.
The wave-by-wave execution: replicate with MGN/DMS, test-launch, validate, cut over in a planned window, keep rollback warm. The partner owns the runbook, the maintenance-window comms, the data-integrity validation, and the rollback decision. A well-run cutover is deliberately boring: every wave rehearsed in a test launch, every cutover reversible, the production switch a short scripted window rather than an all-hands weekend.
After (or alongside) the lift, the partner modernizes where it pays off: containerizing onto ECS/EKS or App Runner, moving self-managed databases to Aurora/RDS, swapping cron boxes for Lambda + EventBridge. The discipline is selective — modernize where managed services cut cost or toil materially, not everything at once. MAP's Modernize track funds qualifying modernization, so this phase often carries its own credit allocation.
The phase most DIY migrations skip — and the one that protects the business case. Right-sizing over-provisioned instances (the lift usually moves yesterday's over-spec), committing to Savings Plans / Reserved Instances once usage is stable, cost allocation and anomaly alerts, and tuning the operational baseline (monitoring, backups, runbooks).
Without it, a migration can land and quietly cost more than the data center it replaced. With it, the phase-1 TCO model actually materializes. See cost optimization and the landing-zone build for the operational side.
| Tool | What it does | Use it when | 7-Rs fit | Cutover profile |
|---|---|---|---|---|
| Application Discovery Service | Inventories servers, configs, processes + dependency map | You don't fully know what you have or what depends on what | Pre-step to all | N/A (planning) |
| Migration Hub | Single console tracking discovery + every migration | Any multi-app program — the control plane | All | N/A (tracking) |
| Application Migration Svc (MGN) | Block-level server replication → EC2 | Lift-and-shift whole servers with minimal change | Rehost / Replatform | Minutes (continuous sync) |
| MGN for VMware | Replicates vSphere VMs → native EC2 | Leaving VMware behind for native EC2 | Rehost | Minutes |
| Database Migration Svc (DMS) | Migrates DBs with full-load + CDC, source stays online | Any database move; small cutover window needed | Replatform / Refactor | Small (CDC-driven) |
| Schema Conversion Tool (SCT) | Converts schema + procedures across DB engines | Heterogeneous DB (Oracle/SQL Server → Aurora) | Replatform / Refactor | N/A (pre-DMS) |
| DataSync | High-throughput file/object transfer → S3/EFS/FSx | Moving large file/NAS/object datasets | Supports Rehost/Replatform | Scheduled / one-time |
| Transfer Family | Managed SFTP/FTPS/AS2 in front of S3/EFS | Replacing an SFTP server, keeping the protocol | Replatform | Cutover = DNS swap |
The tools are free, so why pay for a service? Because the tools aren't the risk — the strategy, the landing zone, and the cutover are. And the funding math usually makes the partner route the cheaper one.
Plenty of teams self-deliver with the native tools, and for a small, homogeneous, well-understood estate that's a fine call. The honest list of where DIY goes wrong: an under-built landing zone that needs an expensive compliance retrofit; a server rehosted that should have been replatformed or retired; a heterogeneous database migration where SCT's manual-conversion backlog was underestimated by an order of magnitude; a long cutover where data drifted; and the optimization phase that never happens, so the new bill quietly exceeds the old one. A partner-delivered service de-risks each of those — the calls are made by people who've made them before, the cutover is run by a team that owns the rollback, and your platform team stays on the roadmap.
Then there's the money. Under MAP, AWS funds the assessment and credits a large share of the migration and modernization cost for a qualifying partner-filed engagement — frequently meaning little-to-no out-of-pocket. That's the inversion most people miss: the funded, done-for-you route is often cheaper than DIY, not more expensive.
CloudRoute doesn't run your migration — we route you to a vetted AWS partner who does, matched to your source (Heroku, GCP, Azure, VMware, on-prem, Oracle) and scale. The partner files MAP so the assessment is funded and the migration is credit-offset on qualifying workloads. See the AWS Migration hub and the migration service detail.
Day 0 — Inquiry. You tell CloudRoute three things: where you're migrating from (Heroku, GCP, Azure, VMware, on-prem, a specific database), rough estate size, and your timeline driver (lease expiry, a license renewal, a scaling wall). Two minutes.
Day 0–2 — Matched + scoped. CloudRoute routes you to a vetted AWS partner whose track record matches your source and scale — one who has done your exact kind of move (Oracle → Aurora, a VMware exit) before. They scope the high-level estate, confirm MAP eligibility, and frame the Assess phase. The assessment is typically AWS-funded, so this is low-risk to start.
Week 1–3 — Assess. Application Discovery Service runs; the partner produces the 7-Rs dispositions, the TCO model, and a wave plan. You now have a costed, scheduled migration instead of a vague intention — and a clear view of what MAP will fund.
Then — Mobilize → Migrate & Modernize. Landing zone, pilot, then wave-by-wave cutover, modernization, and optimization. Each phase carries its own MAP funding for qualifying workloads.
Same AWS tools underneath. The difference is who owns strategy, the landing zone, the cutover risk, the optimization — and who pays.
| Variable | DIY with AWS tools | Partner-delivered (MAP-funded) |
|---|---|---|
| AWS tool cost | Free (pay for resources) | Free (pay for resources) |
| 7-Rs strategy + dispositions | You decide, first time | Partner who's done it 100× |
| Landing zone design | You build (retrofit risk) | Control Tower + IaC, built right up front |
| Cutover + rollback ownership | Your on-call team | Partner owns the runbook |
| Heterogeneous DB (SCT) effort | Easy to under-estimate | Scoped from the SCT assessment report |
| Post-migration optimization | Often skipped | Built-in FinOps phase |
| Typical timeline | Months (learning curve) | Weeks (parallel waves) |
| Assessment cost | Your time | AWS-funded under MAP |
| Net cost (qualifying migration) | Engineering opportunity cost | Little-to-no out-of-pocket |
Situation: Lease expiry forced the timeline — off the data center in two quarters. The estate was ~70 VMware VMs plus a heavily-used Oracle database with thousands of lines of PL/SQL, and a 40 TB file share feeding analytics. The 6-person platform team was fully committed to the product roadmap and had never run a migration this size; the Oracle license renewal was the other clock ticking.
What CloudRoute did: Routed within 2 days to an EU partner with a VMware-exit + Oracle→Aurora track record. The partner filed MAP; the AWS-funded Assess phase ran Application Discovery Service for 3 weeks and produced 7-Rs dispositions: 11 VMs retired, ~50 rehosted via MGN for VMware, the rest replatformed. Oracle → Aurora PostgreSQL was scoped from the SCT report (PL/SQL conversion was the critical path), DMS handled the data with CDC, DataSync moved the 40 TB share to S3. Cutover ran in 6 reversible waves over 9 weeks.
Outcome: Off the data center two weeks early, Oracle licensing dropped at renewal, and the optimization phase right-sized the fleet and added Savings Plans. MAP funding covered the assessment in full and credit-offset the large majority of the migration + modernization spend — the customer's out-of-pocket on the partner engagement was effectively $0. CloudRoute was paid by the partner.
estate: ~70 VMs + Oracle + 40 TB · waves: 6 over 9 weeks · MAP: assessment funded + migration credit-offset · net cost to customer: ~$0
CloudRoute routes you to one vetted AWS partner who runs the whole migration on the native tool suite — assessment, landing zone, cutover, modernization, optimization — and files MAP so qualifying workloads migrate at little-to-no cost. One match. Fixed scope. Funded path.