The AWS migration assessment: discovery, 7-R disposition, and a decision-grade business case.

IWhat an AWS migration assessment actually is — and where it sits in MAP

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.

AWS says MAP helps offset initial migration costs, and MAP is filed by a partner. Your matched partner files it when the migration qualifies and AWS approves. For startups this is typically $50K to $150K. Depends on the workload; AWS approves. What it covers, including assessment work, is agreed per engagement. CloudRoute matches you with one vetted partner who runs Assess and tells you up front whether MAP is likely to apply.

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.

IIDiscovery — inventorying the estate with data, not interviews

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.

The goal is a complete, evidence-based inventory of servers, applications, processes, utilisation and, most importantly, the network flows between them. Note: AWS Application Discovery Service and Migration Hub closed to new customers on November 7, 2025. Existing customers can keep using them; new customers use AWS Transform or partner discovery tools. The collection modes below describe the approach either way:

IIIPortfolio analysis — a 7-R disposition for every application

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 lean toward Rehost and Replatform for the first waves, with Refactor reserved for the few applications where modernisation pays for itself. Retire is the quiet winner: assessments often find servers nobody uses or owns, and the cheapest migration is the one you do not do.

IVDependency mapping — turning network flows into a safe sequence

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.

VThe Migration Readiness Assessment (MRA) — are you ready to run this?

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.

• Business: Is there a funded mandate, a business case owner, and agreed success metrics (cost, agility, resilience)? Without this the program drifts.
• People: Skills and roles. Who owns the landing zone, who runs the cutovers, what training/certification is needed, and where do partners fill the gap.
• Governance: Funding model, prioritization, change control, and how migration progress is tracked and reported to leadership.
• Platform: Landing-zone design, account structure, networking, and target architecture patterns. This is the Mobilize-phase pre-work the MRA scopes.
• Security: Identity, guardrails, encryption, logging, and compliance posture (SOC 2, HIPAA, PCI, GDPR, regional residency). Gaps here become Mobilize work-streams.
• Operations: Monitoring, incident response, backup/DR, and the operating model for a hybrid estate during the migration window.

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.

VIThe business case and TCO model — run-as-is vs. AWS

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: migration labor per wave, data transfer and replication, running both environments during cutover, schema conversion for engine changes, and training. Net it out and you get a break-even point: the month cumulative AWS savings overtake the migration investment. For reference, AWS states on its MAP page that customers migrating legacy applications achieve an average of 31% infrastructure savings. Your number comes from your own utilisation and licensing, not an average.

VIIWave planning — the sequenced roadmap you can fund and execute

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.

VIIIWhat the assessment deliverable actually looks like

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". A CloudRoute-matched partner can produce this package and, if the migration qualifies, file MAP funding for the work that follows.

• Discovered inventory: every server and VM with utilisation, grouped into applications, exported from your discovery tool (and queryable in Athena).
• 7-R disposition register — every application mapped to one of the 7 Rs with the rationale, plus the Retire list (the immediate savings).
• Dependency map — the application/move-group graph from observed network flows, with the high-risk couplings called out.
• TCO / business case — run-as-is vs. AWS, one-time migration cost, savings curve, break-even, and MAP funding applied where it qualifies.
• MRA scorecard — CAF six-perspective heat-map with prioritized readiness work-streams and owners.
• Wave plan — sequenced waves with per-app strategy, tooling, cutover/rollback approach, and timeline estimates.
• Mobilize scope — the landing-zone and foundational work the assessment recommends doing first, ready to fund as the next MAP phase.