The technology is the easy part. What derails migrations is sequencing, licensing, the integrations nobody listed, and cutting over without a way back.
Most cloud migration checklists are inventories of technical steps, and the technical steps are rarely where migrations go wrong. The tooling for moving mailboxes, files and virtual machines is mature. The common failures are decisions made in the wrong order and dependencies that were never written down.
So this checklist is organised by the decisions, not by the steps.
Before anything: what is this for?
A migration with a clear reason gets scoped properly and finishes. A migration justified as "moving to the cloud" expands until it stops.
Legitimate reasons, each of which implies a different scope: the datacentre lease is ending; the hardware is at end of life and replacing it costs more than moving; you need capability you cannot build on-premises; an acquisition has to be integrated; or a specific compliance requirement is easier to meet in a managed service.
Illegitimate reasons: cost saving in the abstract. Lift-and-shift to infrastructure-as-a-service is frequently more expensive than the hardware it replaces, once you account for egress, storage tiers and the fact that cloud instances run twenty-four hours a day unless somebody turns them off. Cost savings in cloud migration are real but they come from retiring things and from moving to managed services, not from relocating virtual machines.
Decide the destination per workload
Not everything should go to the same place, and the choice is not binary. For each system:
Retire. Is anyone actually using this? A meaningful fraction of what you are proposing to move does not need to exist. This is the highest-value question on the list and it is usually asked too late.
Replace. Would a SaaS product do this job? Moving a self-hosted system to a virtual machine in the cloud preserves your maintenance burden exactly. Replacing it removes it.
Rehost. Lift and shift. Fast, low risk, and it keeps all your existing operational cost. Legitimate as a step when a lease is ending and you need time.
Refactor. Rebuild to use managed services. Highest cost, best long-term economics, and only worth it for systems that will still matter in five years.
Sequence it so the first wave is easy
There is a persistent instinct to migrate the hardest system first, on the theory that if it works, everything else will. In practice the first wave is where you discover your tooling gaps, your bandwidth constraints and the fact that nobody documented how the test environment is built. Discovering those on the ERP migration is expensive; discovering them on file shares is a Tuesday.
The list that is always incomplete
Before any wave, enumerate for each system: who uses it, what it talks to, what talks to it, what authenticates against it, what its licence terms say about virtualisation and about running in a public cloud, and what its recovery requirements are.
The second and third of those are where migrations break. The reporting tool that connects to the database on a fixed IP address. The scanner on the second floor that drops files onto a share by UNC path. The script on somebody's desktop that has run every Monday for six years. None of these are in any documentation and all of them surface at cutover.
Two techniques that find them: run a network flow analysis for a fortnight and look at what actually connects to the server, and ask every department the same question, being "what do you do that touches this system, including the things you do once a month".
Licensing deserves its own mention. Per-core and per-socket licences frequently have different terms in public cloud, sometimes dramatically different. Check before you size anything, not after.
Cutover, with a way back
The parallel-run step is the one most often cut for time, and it is the one that catches the monthly and quarterly processes. A system that works perfectly for three weeks can still fail at month end, because month end exercises code paths nothing else touches. One full business cycle, whatever your cycle is.
For the cutover itself, write down in advance: the point of no return, who makes the call to proceed past it, what the rollback procedure is, how long rollback takes, and the time by which you must decide. Then rehearse the rollback. A rollback plan nobody has tested is a paragraph.
After, which people forget to plan
Decommission on a date. The old environment should be readable but not writable for a defined period, then switched off by somebody who owns that action. Environments left running "just in case" run for years, cost money, and remain an unpatched attack surface.
Re-baseline the cost. Cloud bills arrive monthly and grow quietly. Review the first three in detail, line by line, and find the instances nobody turned off and the storage tier that was set wrong.
Update everything that referenced the old thing. Documentation, runbooks, the continuity plan, the asset register, monitoring, and the firewall rules that now point at nothing.
Check the backups changed too. This is the single most common post-migration gap we find. The old backup job pointed at the old environment and was never repointed, so the new system has been running unbacked-up since cutover. Verify with a restore, not with a dashboard.
The honest timeline
For a mid-sized organisation moving off on-premises infrastructure: three to six months of planning and discovery, six to eighteen months of execution depending on how many systems are in the "refactor" column, and a tail of several months tidying up.
Anyone offering substantially less than that has either a much simpler estate than they realise or is planning to lift and shift everything, which is a valid choice but should be made deliberately rather than by schedule pressure.
