What a cloud migration assessment should include

A migration assessment is the cheapest opportunity you will ever have to avoid an expensive mistake. It is also the deliverable most often reduced to a discovery-tool export with a cover page.

The test of a good assessment is simple: could someone who was not involved read it and make a funding decision? If the document tells you what you have but not what to do about it, it is an inventory, not an assessment.

Here is what it should contain.

1. An application inventory with dependencies, not just servers

Automated discovery tools are good at finding servers and reasonable at inferring network dependencies. They are poor at knowing that the invoicing job fails if the finance file share is unavailable at 2am, because nobody has documented that and it only breaks twice a year.

The inventory needs to be application-shaped rather than infrastructure-shaped:

• what the application does, in one sentence a business person recognises
• who owns it, and who to call when it breaks
• what it depends on, including scheduled jobs, file drops, SFTP endpoints and integrations nobody remembers building
• what depends on it
• its actual usage pattern, not its provisioned capacity

That last point matters commercially. Estimating cloud cost from provisioned capacity is how organisations end up paying more after a migration than before. Most on-premises estates are provisioned for a peak that occurs twice a year, and lifting that specification into a cloud invoice is a straightforward way to lose the business case.

2. A disposition per application, with reasoning

Every application needs a decision. The common taxonomy is retire, retain, rehost, replatform, refactor, repurchase and relocate. The label matters less than the reasoning behind it.

The two most valuable dispositions are the ones teams skip.

Retire. In most estates, somewhere between five and fifteen percent of applications have no active users. Nobody turns them off because nobody is certain, and the cost of being wrong feels higher than the cost of leaving them running. An assessment that identifies genuine retirement candidates, with evidence, pays for itself immediately: you migrate less, you pay for less, and you carry less risk.

Retain. Sometimes the right answer is that an application stays where it is for now. A system due for replacement in eighteen months should not be migrated twice. Saying so out loud is a sign the assessment is honest.

Each disposition needs the reasoning attached. "Rehost" is not an answer. "Rehost, because the vendor does not support a container deployment and the contract runs to 2029" is.

3. A target platform recommendation with the criteria shown

If the assessment recommends Azure or AWS without showing how it got there, treat it as a preference rather than a finding.

The criteria that actually decide it:

• existing commercial position — licensing already held, agreements in place, discounts negotiated
• team capability — what your people can operate confidently on day one, and what they would have to learn
• workload fit — some applications genuinely land better on one platform, particularly Windows and SQL Server estates, or workloads with a specific managed-service dependency
• data gravity — where the data already is, how much of it moves, and what governs it
• regulatory position — obligations that constrain region, residency or access
• exit cost — what it would take to leave, which nobody wants to discuss and everybody should

A recommendation is stronger, not weaker, for stating what would change it.

4. A landing zone design, not just a subscription list

The landing zone is the part that is expensive to retrofit. It should be designed before the first workload moves, and the assessment should say what it will look like:

• identity and access model, including privileged access
• subscription or account structure, and what determines which workload goes where
• network topology, connectivity back to on-premises, and egress paths
• policy and guardrails, expressed as what will be prevented rather than what will be recommended
• logging, monitoring and where telemetry is retained
• how environments are provisioned, and by whom

Both vendors publish detailed reference guidance for this. An assessment that ignores it and proposes something bespoke should explain why.

5. A cost model with its assumptions exposed

A single number is not a cost model. The assessment should produce:

• a run-rate estimate for the target state, with the sizing assumptions listed
• the one-off migration cost, including the people
• a comparison against the true current cost, which must include hardware refresh, data centre, licensing, support contracts and the staff time currently absorbed by keeping it running
• the point at which the two lines cross
• a sensitivity view: what happens if the estate is twenty percent larger than discovered, or if egress is higher than modelled

Cost models are usually wrong. That is acceptable. Cost models whose assumptions are not written down cannot be corrected when they turn out to be wrong, which is not.

6. A security and compliance position

The assessment should state, plainly:

• what the current security posture is, and which gaps migrate along with the workload
• what the target state controls will be
• what obligations apply, and which of them constrain the design
• what will be worse immediately after migration, and for how long

That last item is the honest one. A lift-and-shift migration frequently improves resilience and worsens the security posture temporarily, because the workload arrives before the monitoring does. Better to plan for that than to discover it.

7. A migration sequence with a reason for the order

Not a Gantt chart. A sequence, with the logic visible:

• which applications move first, and why they were chosen (usually low dependency, low consequence, high learning value)
• what has to be in place before each wave
• where the cutover risk concentrates
• what the rollback plan is for each wave, and whether it has been tested
• which waves can run in parallel and which genuinely cannot

The first wave should be chosen for what the team learns from it, not for the size of the win.

8. An operating model for afterwards

Migration changes who does what. The assessment should say how:

• who operates the platform, and whether that is a new capability or an existing one
• how cost is monitored and attributed once it is consumption-based
• how changes are made, and what approval they need
• what monitoring and alerting exists on day one, as distinct from what is planned
• what the support arrangement is, and what it covers

Organisations that skip this end up with a modern platform run with the previous operating model, which is where the "we migrated and nothing improved" conversation comes from.

Four warning signs of a weak assessment

It contains no retirement candidates. Either the estate is unusually well managed, or nobody asked.

Every application is rehosted. Rehosting everything is a valid strategy under time pressure, but as a finding it usually means the applications were never examined individually.

The cost model has no assumptions section. Then it cannot be checked, and it will not be revisited.

It recommends the platform the assessor sells most of. Not automatically wrong. Always worth asking what criteria produced it, and what would have produced the other answer.

The uncomfortable one

A good assessment sometimes concludes that you should not migrate yet. That the application portfolio needs rationalising first, or that the operating model cannot absorb the change this year, or that the business case does not hold at your scale.

That is a valid, valuable outcome. It costs the price of an assessment instead of the price of a migration.

If you want an outside read on your estate, our free discovery workshop covers the first pass, and our cloud modernisation practice runs the full assessment.