The assessment decides whether each workload is rehosted, replatformed, refactored or retired. Skipping it is why migrations overrun.
Start with a complete list of what actually runs, which is rarely the list anyone has. Combine configuration management data, network flow logs and conversations with the teams who own the systems.
Expect to find workloads nobody can name an owner for. Those are candidates for retirement and represent the cheapest win in the programme.
The scores drive the decision, and writing them down means the decision can be reviewed rather than relitigated.
Rehosting moves it as it stands: fastest, cheapest, and it carries existing inefficiency forward. Replatforming swaps components for managed equivalents and usually offers the best return. Refactoring is justified where the workload is strategically important and its architecture genuinely blocks the business.
Retiring and replacing with a commercial product are legitimate outcomes and are frequently overlooked because the programme is framed as a migration.
Move something low-risk first to prove the runbook under real conditions. Then order by dependency, so a workload never moves before the things it depends on.
Resist the temptation to start with the most valuable system to demonstrate progress. The first wave exists to find the flaws in your process, and you want to find them cheaply.
An assessment produces uncomfortable findings: systems nobody owns, licensing that changes cost, applications that cannot move without a rebuild. How these are presented determines whether they are acted on.
Group findings by decision rather than by system. Stakeholders can decide “retire these eleven workloads” more easily than they can work through a spreadsheet of a hundred rows.
Attach an indicative cost and effort to each recommendation. Findings without costs get deferred; findings with costs get scheduled.
For a modest estate, a few weeks. The pace is usually set by access to systems and to the people who understand them rather than by the analysis itself.
You still need to know dependencies and data constraints. For a handful of workloads the assessment is short, but doing none of it is how cutover-day surprises happen.
That is a valid finding. Some systems are better left in place until they are replaced. A hybrid arrangement is preferable to forcing an unsuitable migration.
Keep reading
The overspend is rarely caused by the cloud itself. It is usually set in motion by three decisions taken in the first few weeks, often by people who did not realise they were making them.
All four run the same workloads competently. The decision usually follows existing commitments, data residency and the skills already in your team.
A meaningful share of cloud spend on a typical estate is recoverable without changing the architecture at all. Start there.
