A migration assessment answers three questions before anything moves. What do we actually have, how is it connected, and what is the right way to move each piece. Its job is to replace assumptions with evidence, because almost every migration that overruns does so on the basis of something the team did not know at the start.
This is a guide to what a good assessment covers, what tooling does the work, what you should receive at the end, and how to tell a useful assessment from an expensive inventory spreadsheet.
What an assessment is, and what it is not?
It is a structured discovery exercise with a defined output. It is not an audit, and it is not a proposal with a discovery section attached.
The distinction that matters is whether it ends in something you can act on. An assessment that hands you a list of servers has described your estate back to you. An assessment that hands you a per-workload strategy, a right-sized cost projection and a sequenced roadmap has told you what to do about it. Only the second one is worth paying for.
In Microsoft's Cloud Adoption Framework, assessment sits at the start of the migration journey, before any target architecture is committed.
What gets inventoried?
Five categories, and the fifth is the one most often skipped.
Servers and infrastructure
Every physical and virtual server. Operating systems, CPU, memory, storage, and critically the actual performance data measured over time rather than the nameplate specification. A server provisioned with 32 GB that never exceeds 6 GB is a right-sizing opportunity, and you only find it by measuring. Capture network configuration and appliances too, load balancers and firewalls included.
Applications
Catalog the applications with their technology stack, version and support status, integration points, owner, and business criticality. This is where the uncomfortable discoveries surface. End-of-support software, systems nobody documented, applications whose owner left two years ago.
Dependencies
The single highest-value output of the whole exercise. Dependencies determine which workloads have to move together, and migrating one half of a tightly coupled pair is a classic and entirely avoidable cause of outage.
Undocumented dependencies are the norm, not the exception. This is the part of the assessment that most reliably pays for itself.
Data platforms
Databases, warehouses and analytics workloads need evaluating on their own terms. Size, schema complexity, performance characteristics and how they feed reporting. Azure targets typically include Azure SQL, Azure Synapse and Microsoft Fabric.
Licensing and cost
Frequently skipped and it should not be. Capture the licensing position across operating systems, databases and middleware, plus what the estate currently costs to run. This surfaces opportunities such as bringing eligible licenses to Azure, and it keeps the business case honest. Azure consumption is billed by usage and varies by service, so an assessment should model expected spend rather than assume a flat saving.
Security and compliance belong in the assessment
If your target design has regulatory, data residency or audit obligations, they need to be established during assessment rather than discovered at cutover.
A compliance constraint found late is one of the most expensive things that can happen to a migration, because it can invalidate architecture decisions already built on. If data residency is in scope, the region decision has to be made here, and our guide to Azure regions and data residency covers what residency does and does not guarantee.
What tooling actually does the work?
Azure Migrate is Microsoft's first-party hub. Microsoft describes it as "a service that helps you decide on, plan, and execute your migration to Azure", with support for servers, databases, web apps, virtual desktops, and large-scale offline migration using Azure Data Box.
Discovery works two ways. The recommended route is the Azure Migrate appliance, a lightweight virtual appliance deployed on a server in your data center that collects configuration and performance data and continually sends it to the service. For air-gapped or restricted networks where an appliance is not feasible, the Azure Migrate Collector enables a snapshot discovery without continuous Azure connectivity. You can also import inventory data directly.
Dependency analysis exists to help you "understand the network dependencies between servers in your datacenter so that you can make high-fidelity migration plans without missing any critical dependency."
Sizing estimates cover Azure virtual machines, Azure SQL configuration, and Azure VMware Solution node counts.
Azure Migrate is the backbone, but it is not the whole job. It discovers and sizes. It does not tell you which applications are strategically worth keeping, which teams can absorb change, or what your compliance position requires. That analysis is human, and an assessment that is only a tool output is not an assessment.
Microsoft updates these capabilities over time, so confirm specifics against current documentation before relying on them.
The migration strategies and the number confusion
You will see this framework called the 5 Rs, the 6 Rs and the 7 Rs depending on who is writing. The People Also Ask box on this topic currently asks about the 7 Rs specifically. Here is the actual position.
Microsoft's Cloud Adoption Framework names eight rationalization options and does not attach a number to them, referring to them generically as the Rs of cloud migration.
|
Option |
What it means |
|---|---|
|
Retire |
Decommission a redundant or low value workload |
|
Rehost |
Move it as it is, minimal change |
|
Replatform |
Modernize the hosting environment, minimal code change |
|
Refactor |
Modernize the code to reduce technical debt |
|
Rearchitect |
Redesign architecture and code for cloud-native capability |
|
Replace |
Move to a SaaS alternative |
|
Rebuild |
Build a cloud-native replacement |
|
Retain |
Leave it where it is, for now |
Source: Microsoft Learn, cloud rationalization.
The various numbered versions circulating are mostly vendor abbreviations of this list, and different vendors drop different options. The reason the count matters is which ones get dropped.
Retire and Retain are usually the first two to disappear from a shortened list, and they are frequently the most valuable findings in an assessment. Discovering that fourteen servers can simply be switched off saves more than migrating them elegantly ever will. Discovering that a system should stay on-premises for another two years is a legitimate and useful answer.
An assessment that assigns every workload a migration path, with nothing retired and nothing retained, has not been rigorous. It has been optimistic.
What should you receive?
Judge an assessment on its deliverables. There should be five.
- A validated inventory and dependency map. Not a spreadsheet of server names, a map showing what talks to what.
- Right-sizing recommendations. Target Azure resources matched to measured demand rather than to existing provisioning.
- A total cost of ownership projection. Covering both the project effort and the ongoing Azure run rate, so the number can survive a finance review.
- A per-workload strategy. Every workload assigned one of the eight options above, with a reason.
- A sequenced roadmap. Workloads grouped into waves by dependency and risk, with a low-risk pilot first and defined milestones.
That last point is what makes the assessment usable outside the technical team. A roadmap with milestones and a costed projection is something you can take to a CFO or a board. An inventory is not.
How does it reduce risk?
Migration failures trace back to the same short list. An undocumented dependency. A fragile integration nobody flagged. A compliance constraint found at cutover. A workload sized on guesswork.
Every one of those is a discovery problem, and discovery is what an assessment is. The point is not to produce a plan, it is to produce a plan whose risks have already been named and assigned an owner and a treatment. Fewer surprises during execution, and a schedule leadership can actually rely on.
How long does it take?
It scales with the size and complexity of the estate.
The floor is set by measurement. Discovery has to run long enough to capture representative performance and dependency data, because a few days of sampling will miss month-end batch loads and quarterly peaks, and those are exactly the periods that determine sizing.
Against a full migration program, which runs from a few weeks to several months depending on environment size, workload complexity and approach, the assessment is an early and time-boxed portion. Our note on Azure migration cost and timeline sets out how the phases sit against each other.
What happens next?
The roadmap feeds execution. Workloads move in sequenced waves, then get validated and stabilized for performance, security and cost. The assessment defines the plan, the later phases carry it out. Where the landing zone fits is covered in our Azure landing zone guide, and the wider sequencing in the Azure migration planning playbook.
How does Centric run one?
As a Microsoft partner, Centric runs assessment as the opening of its assess and plan phase. Discovery across infrastructure, applications and data platforms, Microsoft tooling including Azure Migrate for dependency analysis and right-sizing, and translation of the findings into a per-workload strategy and a sequenced roadmap with milestones.
The output is built to be acted on. A costed plan rather than a static audit.
We run it as a no-obligation first step. The inventory, dependency map, TCO view and roadmap stand on their own as a planning artifact, useful whether you proceed with us, proceed later, or use the findings to sharpen an internal business case. The intention is to take the risk out of starting, so the decision to migrate gets made on evidence rather than pressure.
Frequently Asked Questions
What is a cloud migration assessment?
A structured discovery exercise that establishes what you have, how it interconnects, what it would cost to run in Azure, and how each workload should move, before anything in production is touched. It ends in a costed, sequenced plan rather than a report.
How do I prepare for a cloud assessment?
Three things speed it up materially. Identify application owners in advance, because chasing them is usually the longest pole. Grant the access the discovery tooling needs early, since appliance deployment and credentials often take longer than the discovery itself. And be honest about what is undocumented, because the assessment will find it either way and knowing early is cheaper.
What are the 7 Rs of cloud migration?
There is no single agreed list, which is why you see 5, 6 and 7 in different places. Microsoft's Cloud Adoption Framework names eight rationalization options, Retire, Rehost, Replatform, Refactor, Rearchitect, Replace, Rebuild, and Retain, and does not use a numeric label for them. Shortened versions usually drop Retire and Retain, which are often the most valuable options in an assessment.
What do you inventory in a migration assessment?
Five categories. Servers and infrastructure with measured performance data, applications with their stack and ownership, dependencies between workloads, data platforms, and the licensing and current cost position.
What is Azure Migrate?
Microsoft's first-party service for deciding on, planning and executing a migration to Azure. It covers servers, databases, web apps and virtual desktops, supports appliance-based and collector-based discovery, produces sizing estimates for Azure VMs and Azure SQL, and performs dependency analysis.
What is dependency mapping?
Working out which systems communicate with which, so you know what has to move together. It is the highest-value output of an assessment, because undocumented dependencies are the most common cause of migration outages.
Do I need an assessment before migrating?
For anything beyond a handful of simple workloads, yes. Skipping it is the most common reason migrations overrun on cost and time, because the things that cause overruns are precisely the things an assessment finds.
What is the deliverable?
A migration roadmap with milestones, supported by a validated inventory and dependency map, right-sizing recommendations, a TCO projection, and a per-workload strategy. Something you can budget against and defend to leadership.
Is the assessment really no-obligation?
Yes. The planning artifact stands on its own. You can proceed, proceed later, or use it to build an internal case.
Can Azure Migrate do the whole assessment on its own?
No. It handles discovery, sizing and dependency analysis well. It does not decide which applications are strategically worth keeping, which should be retired, what your compliance position requires, or how much change your teams can absorb. Those need people.
