Cloud Migration Advisory: What Changes in Practice

The placement decisions get remade at the handover, once the delivery schedule takes over from the advisory document. A target architecture is signed off, the migration waves are identified on a slide, and the choices that determine cost and risk are then made by whoever is closest to cutover. Cloud migration advisory has changed shape because that gap between the signed design and the running estate is where the money now leaks. What follows is a checklist of what a credible advisory arrangement settles, grouped by when in the programme each check happens. Every item below is either true of your situation or false of it.

Checked before the engagement is scoped

There are four types of advisory engagement, and they break in different places. Take them in turn, each with the estimate, the optimisation and the error mode that belong to it.

Platform vendor consultancy keeps the estimate within the vendor, optimises for consumption on that vendor's platform, and breaks when the recommendation turns out to be the product.

Delivery-led integrator consultancy keeps the estimate within the integrator, optimises for the scope the integrator can build, and is unsuccessful when the assessment reads as a sales document.

Independent consultancy checks the estimate against evidence, optimises for a defensible placement per workload, and ceases if there is no internal owner to receive it.

The internal platform team keeps the estimate inside the organisation, optimises for fit with the operating model in use, and under-reports the workloads that want to go.

With that in view, the pre-scope checks are these.

The scope lists the workloads that will not move. NHS England Digital's cloud migration guidance states that "Cloud-first doesn't mean that the entirety of an on-premises data centre has to be migrated to cloud services", and it gives the two reasons that justify staying: regulatory requirements and latency. A scope reading "all applications" means a programme with no defensible boundary has been acquired.
Assessment and planning are separately priced and separately deliverable. The cloud migration advisory service from Syntax consists of two components that "can easily be linked into an efficient whole" and that "can be accessed separately", and it lists the deliverables: An assessment establishes the as-is and to-be states of the systems, and a planning phase creates a migration plan, a cost estimate and an operating model. An engagement that bundles those into one line item removes your ability to halt after the assessment and change your mind.
Someone with no stake in the selected platform keeps the estimate. A vendor's estimate forecasts its own consumption, and an integrator's estimate forecasts its own build. Both are honest numbers that serve the estimator, and a placement decision needs a number from outside that interest.
An internal owner is assigned to the engagement to receive the advisory results. An independent consultant with no internal equivalent creates a report that goes into a folder.
Discovery is scoped to produce an inventory of the estate. Syntax calls out the ghost servers, hardware running without official documentation, and the adjacent workloads a core application depends on. Those are the workloads that turn a migration plan into a series of surprises.
A proof of concept or prototype runs before the migration plan is fixed. Audacia describes delivering cloud proof of concepts and prototypes to validate early discovery and test high-risk technical features before adoption. Moving from assessment straight to plan skips the cheapest way to find the technical unknown.
The timeline lists phases and their durations. GreenTree Advisory, a UK cloud migration service, publishes a phased engagement of two to four weeks for readiness assessment and platform selection, four to twelve weeks for secure data migration and deployment, and two to six weeks for optimisation and testing, with ongoing monitoring after that. The guidance lacks scheduled moments to pause and re-evaluate because it has no matching phase boundaries.

A workload is checked when it is placed

The engagement is made to decide on placement, and each placement decision belongs to one workload. NHS England Digital sets out the attributes to assess: risk, technical fit and value. Risk decides whether a mistake is absorbed or fatal to the programme. Technical fit decides whether a workload moves as it stands or needs change. Value decides whether the change is worth making.

Every workload has a specific placement from the set NHS England Digital uses: re-host, revise, rearchitect, rebuild, replace. A placement policy that terminates at "cloud" has placed no resources.
You select the cloud tier with the placement. NHS England Digital says that re-host and revise usually execute at IaaS, rearchitect and rebuild on PaaS, and replace on SaaS, and adds that the rule is not strict. Regulatory requirements or absent vendors routinely force a workload down a tier. A placement without a tier is a placement without a cost.
The transformation budget is matched to the expected return. NHS England Digital is explicit that where you choose transformation, the organisation has to assess how much transformation it will accept against the expected return. A rearchitect decision carries a costing against the value of the workload, and without that number it stands as an architectural preference.
Every workload that stays on-premises has a stated cause. The reasons NHS England Digital allows are regulatory requirements and latency, both of which are checkable. The phrase "It is too old" does not pass that test.
Whoever pays the run-rate bill reviews the placement decision, sitting alongside the architecture function. Placement is the stage where capital cost becomes operating cost.

Checked when the migration waves are cut

Sequencing is where a technically sound plan meets a political one. The check is whether the wave order reflects the placement decisions or the stakeholder map.

The first wave contains at least one workload with low risk and high learning value. NHS England Digital says that organisations often want to begin with low-risk applications so that they absorb the impact of mistakes without jeopardising the whole initiative. A first wave chosen to show the board visible progress is a different object, and it usually pairs high value with hidden dependencies.
The wave plan has rollback at wave level as well as at programme level. If wave one goes wrong, the plan either survives it or does not.
Dependencies are mapped per wave, with high-blast-radius systems mapped first. CACI's 2026 guide to cloud migration challenges reports that organisations spend an average of 14% more on migration than planned, that 38% of migrations run more than a quarter late, and that 84% of organisations struggle to manage cloud spend; it warns that missing a single critical dependency can cause outages when workloads are moved. Discovery and assessment is where that risk concentrates.
The plan states who owns the platform and how application teams consume it. The same CACI guide considers the operating model the place where a cloud-appropriate strategy develops.
Cost controls land in wave one, with resources tagged so that spend can be allocated. FinOps is a design decision made before the first workload moves.

Verification occurs at the time of cutover and after

The advisory is usually quiet by this stage. That is the change being described here: engagements that hold up stay in the room for cutover and for the first optimisation cycle.

Security posture management is part of the migration plan from the first wave. CISA's blog on the Cloud Security Technical Reference Architecture sets out how the guidance divides the work between FedRAMP coverage of cloud service selection and shared risk, USDS coverage of migration benefits, challenges, strategies and scenarios, and CISA coverage of cloud security posture management through the implementation and monitoring phases. An engagement that hands over before those phases has left its own recommendation unenforced.
The operating model is in place at the time of cutover, with a designated platform owner. Syntax places the operating model alongside the migration plan and the cost estimate in its planning phase, and requires the plan and the model to carry the switchover schedule.
Cutover is automated and reversible. Cyber-Duck describes using Infrastructure as Code to provision the new cloud environment, building or updating continuous integration and continuous deployment pipelines, and running quality, accessibility, security and compliance tests before the final data migration and DNS switchover. An advisory with no view on the switchover mechanism has no view on the outage.
The optimisation cycle after cutover has a deadline and an owner. GreenTree Advisory runs optimisation and testing for two to six weeks after deployment, then quarterly performance reviews with cost monitoring. A programme that concludes at cutover has tracked no metrics the board asked about.
The evidence trail satisfies the regulators who will read it. Suffescom's 2026 guide to cloud migration risks lists UK GDPR, the Data Protection Act 2018, FCA operational resilience expectations and ISO 27001 among the frameworks a UK migration has to map to, and mentions the 72-hour breach notification window to the Information Commissioner's Office. Security controls change shape in the cloud, and the evidence that they operated has to move with them.

Sources

Run through this

The scope names the workloads that will not move.
Assessment and planning are separately priced and separately deliverable.
The estimate is held by someone with no stake in the platform selected.
The engagement has a named internal owner who receives the advisory output.
Discovery is scoped to produce an inventory of the estate.
A proof of concept or prototype runs before the migration plan is fixed.