An AWS migration assessment is the "Assess" phase of the Migration Acceleration Program: 2–6 weeks of automated discovery, application-portfolio analysis, dependency mapping, and a TCO-backed business case that tells you what to migrate, in what order, how, what it costs, and what you save. Done right it ends with a wave plan you can fund and execute. AWS frequently pays for this phase — so a vetted partner can run it for you at little-to-no cost.
The phrase "migration assessment" gets used loosely. In AWS terms it has a precise meaning: it is the Assess phase of the Migration Acceleration Program (MAP), the first of three phases before any production workload moves.
MAP runs in three phases — Assess, Mobilize, and Migrate & Modernize. Assess answers "should we, what, and what will it cost?" Mobilize builds the landing zone and runs a pilot to prove the plan. Migrate & Modernize executes the production cutover wave by wave. An assessment that skips straight to "lift everything and shift" is not an assessment — it is a guess wearing a deck.
The Assess deliverable is a directional business case: a defensible estimate of total cost of ownership today versus on AWS, a per-application migration strategy (the 7 Rs), a dependency-aware sequence (the wave plan), and a rough order-of-magnitude on cost, timeline, and risk. It is decision-grade — enough for a CFO to approve a budget and an engineering lead to staff the first wave — without being so detailed that it takes six months to produce.
Crucially, Assess is the phase AWS most often funds. AWS wants the workload, so it underwrites the discovery and business-case work that de-risks the decision in its favour. In practice that means a qualified migration can get its assessment delivered by an AWS partner at little-to-no cost — the partner is funded through MAP and the APN, not by you. That is the CloudRoute hook: we route you to a partner who runs Assess as a funded engagement, so you reach a fundable plan without spending consulting dollars to find out whether to migrate at all.
If you are searching "AWS migration assessment," you are usually at one of two points: you have a board mandate to "move to the cloud" and need a real plan, or you have an estate (on-prem VMware, another cloud, a sprawl of EC2 you inherited) and you need to know what is worth migrating, what to retire, and what it costs. Both start the same way: discovery.
Every credible assessment starts by replacing tribal knowledge with measured data. You cannot disposition an application you cannot see, and the network diagram in someone's head is always wrong in the expensive places.
AWS provides a discovery stack for exactly this. The goal is a complete, evidence-based inventory of servers, applications, processes, utilization, and — most importantly — the network flows between them. Two collection modes run in parallel:
Agentless collector — a virtual appliance (OVA) deployed into VMware vCenter. It pulls inventory and performance for every VM without touching guests: CPU, memory, disk, and network utilization sampled over time. Ideal for large VMware estates where installing agents on hundreds of guests is politically and operationally painful.
Agent-based collector — a lightweight agent on individual hosts (Linux/Windows, physical or virtual). It captures process-level detail and, critically, TCP/IP connections between processes — the raw material for dependency mapping. You install agents where you need flow-level truth.
Both feed AWS Migration Hub, the single pane where the inventory is aggregated, grouped into applications, and tracked through the later phases. Discovery data can also be exported to Athena for custom queries — useful when you want to slice 400 servers by tag, owner, or utilization band.
Migration Evaluator is AWS's cost-modelling tool — it ingests the utilization data (its own lightweight collector, or imports from ADS / RVTools / CSV) and produces a right-sized AWS target with a defensible cost projection. It models On-Demand, Savings Plans, Reserved Instances, and BYOL vs. license-included options — the difference that decides whether an Oracle or SQL Server estate is cheaper on Aurora/RDS or on EC2.
This is the engine of the TCO model. Right-sizing is where the savings come from: most on-prem fleets are provisioned for peak plus a fear margin and run at 15–25% average utilization. Migration Evaluator maps observed demand to the smallest instance that fits, which is typically where the run-as-is vs. AWS gap opens up.
Not every estate is greenfield for AWS tooling. Migration Evaluator and ADS accept imports from VMware RVTools exports, Microsoft MAP Toolkit, and partner discovery platforms (Flexera, Device42, and similar CMDB/dependency tools). For Windows-heavy estates, Azure Migrate-style exports can be reconciled in. The principle holds regardless of tool: collect 2–4 weeks of utilization so peaks and batch cycles are captured, not a single quiet afternoon.
Run discovery for at least two full weeks, ideally including a month-end or a known peak (billing run, payroll, retail event). A 48-hour snapshot misses the batch jobs and the spikes that drive instance sizing — and undersized targets are how a "20% cheaper" business case turns into a 20%-over bill on day 30.
Once you have an inventory grouped into applications, you assign each one a migration strategy. AWS's framework is the 7 Rs. The assessment's job is to put every application into exactly one bucket, with a reason.
The 7 Rs are not equally common. Most portfolios skew heavily toward Rehost and Replatform for the first waves, with Refactor reserved for the few applications where modernization pays for itself. Retire is the quiet winner — assessments routinely find 10–25% of "servers" are zombies nobody will admit to owning, and the cheapest migration is the one you do not do.
Retire — decommission. No traffic, no owner, or superseded. Pure savings; remove from scope entirely.
Retain — leave in place (for now). Hard regulatory pins, a mainframe mid-contract, or an app slated for sunset within 12 months. Revisit next wave.
Rehost — lift-and-shift. Move the VM as-is using AWS Application Migration Service (MGN). Fastest path; minimal code change; you optimize after landing. The default for the long tail.
Relocate — move the hypervisor, not the VM. VMware Cloud on AWS lets you vMotion vSphere workloads with no guest changes. Right when you want speed and to keep VMware operations intact.
Repurchase — drop and replace with SaaS. A self-hosted CRM, wiki, or email becomes a subscription. Removes the workload from migration scope but adds a data-export task.
Replatform — lift-tinker-shift. Keep the app, swap the undifferentiated heavy lifting: self-managed Postgres → RDS/Aurora, self-managed Kubernetes → EKS, app servers → managed runtimes. The highest-ROI bucket for most teams.
Refactor — re-architect. Break a monolith into services, go event-driven or serverless. Highest cost and risk; reserved for applications where the business case (scale, agility, cost) clearly justifies it. Rarely a first-wave move.
Most successful programs Rehost or Replatform first, then Refactor selectively once the workload is live on AWS and the team has operational muscle memory. Trying to Refactor everything during the migration is the classic way to blow the timeline and the budget. The assessment should flag Refactor candidates but schedule them as post-migration modernization, not as blockers to the cutover.
This is the step that separates a real assessment from a spreadsheet. An application does not migrate alone; it talks to databases, queues, auth services, file shares, and a long tail of integrations nobody documented. Move it without its dependencies and you take production down at cutover.
Dependency mapping uses the observed TCP/IP connection data from the ADS agents (and, for agentless estates, flow logs and partner tooling) to build a graph of which servers talk to which, on what ports, how often. From that graph you cluster tightly-coupled applications into move groups — sets of components that must migrate together or stay synchronized during a phased cutover.
The map exposes the expensive surprises early: the reporting app that quietly hits the production database, the shared authentication service half the estate depends on, the on-prem file share three "cloud-ready" apps still mount, the hard-coded IP nobody remembers setting. Each is a cutover incident waiting to happen if it surfaces during the migration instead of during the assessment.
Dependency data also drives the migration mechanics: which workloads can tolerate a replication-and-cutover window with AWS MGN, which need AWS Database Migration Service (DMS) with continuous change-data-capture to keep a database in sync until switchover, and which require DataSync or Transfer Family to move bulk file data ahead of time. Heterogeneous database moves (Oracle → Aurora PostgreSQL, SQL Server → Aurora) also pull in the Schema Conversion Tool (SCT) — and the assessment should size that schema-conversion effort honestly, because it is consistently the hardest, most underestimated part of any migration.
Discovery tells you about the workloads. The Migration Readiness Assessment tells you about the organization. Both have to be ready, and the MRA is where most "the tech was fine but the program stalled" failures get caught in advance.
The MRA scores readiness across the six perspectives of the AWS Cloud Adoption Framework (CAF): Business, People, Governance, Platform, Security, and Operations. It is typically run as a facilitated workshop (often a day or two) with the relevant stakeholders, producing a heat-map of strengths and gaps and a prioritized set of work-streams to close them before — or in parallel with — the migration.
The gaps it surfaces are rarely technical-only. A platform team with no landing-zone experience, a security org with no cloud guardrails, an operations group with no observability story, a finance team with no FinOps practice for variable cloud spend — any of these will stall a migration that the discovery data says is "ready." The MRA converts those into named work-streams with owners.
The MRA output is not a grade you pass or fail — it is the input to the Mobilize phase. Every "amber" or "red" cell becomes a foundational work-stream (build the landing zone, stand up guardrails, train the on-call rotation) that runs before the first production wave so the migration lands on solid ground.
This is the deliverable the budget hinges on. The assessment converts the discovery and right-sizing data into a defensible TCO comparison: the fully-loaded cost of staying put versus the cost of running the same workloads on AWS, plus the one-time cost of getting there.
A credible TCO model is honest about both sides. The "run-as-is" side is not just the AWS-equivalent bill — it includes hardware refresh cycles, data-center space/power/cooling, hypervisor and OS licensing, storage arrays, network gear, the maintenance contracts, and the staff time spent racking, patching, and babysitting all of it. Teams routinely underweight the run-as-is cost because most of it is buried in capex and headcount nobody attributes to "infrastructure."
The AWS side is the right-sized target from Migration Evaluator, costed with the commercial levers applied: Savings Plans / Reserved Instances for steady-state compute, BYOL where licensing favours it, the storage-tier mix (gp3 vs. io2, S3 lifecycle to Glacier), and the operational savings from managed services (no DBA toil on RDS, no cluster ops on EKS Fargate). The model should show steady-state monthly run cost and the savings curve as Reserved/Savings-Plan coverage ramps.
Then the one-time costs: the migration labor (per wave), data-transfer and replication, dual-running during cutover windows, schema-conversion effort for heterogeneous databases, and training. Net it out and you get a break-even point — the month the cumulative AWS savings overtake the migration investment. For typical mid-market estates the directional savings land in the 20–40% range against a fully-loaded run-as-is baseline, with break-even commonly inside 12–24 months. Hedge these as representative ranges, not promises — the real number falls out of your specific utilization and licensing.
The business case improves further when MAP funding is in scope. AWS often funds the Assess phase outright (the assessment is delivered at $0), and for qualifying migrations credits a meaningful share of the Mobilize and Migrate costs — scaled to the migration size, typically tied to a post-migration AWS-spend commitment. That moves a chunk of the one-time migration cost off your side of the ledger and pulls break-even forward. Honest framing: MAP funding applies to qualifying migrations; where it does not, this is still a vetted-partner engagement that de-risks the cutover.
All four streams converge into the single artifact the rest of the program runs on: the wave plan. It groups applications into migration waves, orders them by dependency and risk, and attaches a strategy, owner, and rough timeline to each.
A wave is a batch of applications migrated together over a defined window. Sequencing is driven by the dependency map (move groups stay together), by risk (low-risk, low-coupling apps go first to build momentum and prove the runbook), and by business priority. The classic shape is a small pilot wave during Mobilize, then progressively larger production waves.
Each wave entry carries the per-app 7-R disposition, the tooling (MGN for rehost, DMS+SCT for database moves, DataSync for bulk file data), the cutover approach (replicate-then-switch vs. continuous sync), a rollback plan, and a maintenance-window estimate. This is what makes the plan executable rather than aspirational — an engineer can read a wave and know exactly what to do.
Wave 0 — Pilot (Mobilize): 1–3 low-risk, low-dependency applications. Proves the landing zone, the runbook, and the cutover mechanics. 2–4 weeks.
Wave 1 — Quick wins: stateless and loosely-coupled apps, mostly Rehost/Relocate. Builds momentum and team confidence.
Waves 2–N — Core systems: the coupled move groups and the database tier, where Replatform and DMS+SCT effort concentrates. Sequenced so each wave's dependencies are already live.
Tail — Retire / Refactor backlog: decommission the zombies, and schedule the Refactor candidates as post-migration modernization once the estate is stable on AWS.
A common worry is that "assessment" means a vague slide deck. A real MAP Assess deliverable is a concrete, multi-part package you can hand to finance, engineering, and leadership and act on immediately.
Together these are enough for a CFO to approve a migration budget and an engineering lead to staff Wave 0 the following week. That is the bar for "decision-grade." And because AWS frequently funds Assess under MAP, a CloudRoute-matched partner can produce this entire package as a funded engagement — you reach a fundable plan without spending your own consulting budget to get there.
The assessment is only as good as the data underneath it. Here is what each tool in the AWS discovery-and-assessment stack does, what it produces, and when you reach for it. A real Assess engagement uses several of these together, not one.
| Tool | What it does | Collection mode | Primary output | When to use |
|---|---|---|---|---|
| Application Discovery Service — agentless | VM inventory + utilization from vCenter | OVA appliance in VMware (no guest agents) | Server inventory, utilization, basic dependencies | Large VMware estates where agents are impractical |
| Application Discovery Service — agent | Process-level detail + TCP/IP connection capture | Lightweight agent per host | Process inventory + flow data for dependency mapping | Anywhere you need flow-level dependency truth |
| Migration Evaluator (TSO Logic) | Right-sizing + cost / TCO modelling | Own collector, or import ADS / RVTools / CSV | AWS right-sized target + cost projection (On-Demand / SP / RI / BYOL) | Building the business case and break-even |
| AWS Migration Hub | Aggregates discovery, groups apps, tracks progress | Console (consumes ADS / partner data) | Single-pane inventory + migration-status tracking | The hub of record across all MAP phases |
| Migration Hub Strategy Recommendations | Analyzes apps, suggests 7-R strategy + tooling | Collector analyzes running apps / source | Per-app strategy recommendation | Accelerating the 7-R disposition at scale |
| Partner / 3rd-party (Flexera, Device42, RVTools) | CMDB, license, and dependency discovery | Agent / agentless per vendor | Dependency graphs, license positions, import to ADS/Evaluator | Existing CMDB data or Windows/license-heavy estates |
Situation: Board mandate to "get out of the data centers" ahead of a forced hardware refresh, but no inventory anyone trusted, no idea which of the 220 servers were actually in use, and a finance team that would not approve a migration budget without a defensible TCO. An internal "lift everything" estimate from a reseller looked expensive and nobody believed the numbers.
What CloudRoute did: CloudRoute routed the inquiry within 24 hours to an AWS Advanced partner with insurance + VMware migration track record. The partner registered a MAP Assess engagement (AWS-funded, $0 to the carrier), deployed the ADS agentless collector into vCenter plus agents on the database and core-app tier, and ran Migration Evaluator over a four-week window spanning a month-end policy-renewal peak. Output: a 7-R register, a dependency map, an MRA workshop, and a TCO model with MAP funding applied.
Outcome: Discovery found 38 servers (17%) with no meaningful traffic — retired outright. Disposition: ~70% Rehost (MGN), ~20% Replatform (SQL Server → RDS, self-managed apps → managed runtimes), 6 Refactor candidates deferred to post-migration, the Oracle tier flagged for a SCT+DMS conversion to Aurora PostgreSQL with the schema effort sized honestly. The business case showed ~31% lower fully-loaded run cost vs. the refresh-and-stay baseline, break-even at month 16, with MAP credits covering a large share of the migration labor. Finance approved a four-wave plan; Wave 0 pilot started three weeks after sign-off. The carrier paid $0 for the assessment.
assess window: 4 weeks · apps profiled: 220 · servers retired: 38 · directional savings: ~31% · cost to customer for Assess: $0
CloudRoute routes you to a vetted AWS partner who runs the MAP Assess — discovery, 7-R disposition, dependency map, TCO, and a fundable wave plan. AWS often funds this phase, so for qualifying migrations the assessment costs you $0.