Decide What the Move Is For
Cloud is not one goal, and different goals produce different plans. Getting out of a building before the lease ends is a deadline job, and lifting things across as they are is usually the right answer. Spending less every month is an optimisation job, and lifting things across as they are usually makes it worse. Staying up when something fails is an architecture job. Shipping a new feature is a development job that happens to involve servers.
Write the goal in one sentence and get the person paying for it to agree to that sentence. Every contested decision later gets settled against it. Without one, decisions get settled by whoever is most senior in the room that day.
If several goals apply, put them in order, because they pull against each other. Speed and cost do not travel together, and a plan that pretends otherwise delivers neither of them.
Count Everything, Including the Long Tail
Every business has a long tail. The small tool one team depends on. The scheduled job on a server nobody owns. The reporting database feeding a spreadsheet the board reads every month. On their own they are nothing. Together they are where the budget goes.
Build the list from more than one source. A discovery tool finds what is running. Network traffic shows what talks to what, which is what really decides the order you move things in. Talking to the head of each department finds the systems that barely register in either and would stop the business dead.
For each one write down the owner, what it talks to, whether the operating system and the software are still supported, and whether anybody would notice if it stopped. That last column is the most useful thing on the sheet.
Give Every System a Decision
There are only a few decisions available. Switch it off, which is the cheapest and the least used. Replace it with something you subscribe to, which moves the problem to integration and to who owns the data. Move it across as it is. Move it and swap the database or the file storage underneath for a managed one. Or rewrite it, which is a development project wearing an infrastructure hat.
Record the reason next to the decision. You will want it in a year when somebody asks why the accounts system was moved as it was rather than rebuilt, and it stops the plan being reopened every time a new person joins the steering group.
Expect the switch off and replace lists to be longer than anyone guessed at the start. That is the process working, not scope going missing.
Order by What Talks to What
The instinct is to start with the easiest system so that everyone feels good. It works as a rehearsal and it teaches you almost nothing about the hard part, which is separating things that depend on each other.
Move things in groups instead. Systems that have to travel together, or that can survive being split across two places for a known number of weeks. Anything that chats constantly with something left behind will either move with it or pay for every round trip in slowness and transfer charges until it does.
Logins, name lookups and the sign in path go early, because everything else leans on them. Getting those wrong does not give you a slow migration. It gives you an outage in systems nobody was touching that week.
Build the Landing Zone First
Some decisions are cheap now and expensive later. How accounts and subscriptions are split. The network layout and the address ranges. Who gets administrator rights and how. Where logs are sent. How things are labelled. Where the encryption keys live and who can use them. And the rules that stop a well meaning engineer creating something the whole internet can read.
Put cost on that list. If nothing is labelled with an owner from the first day, the bill arrives as one number nobody can break apart, and controlling it turns into archaeology instead of management.
Where the risk justifies it, make the rules block rather than report. A rule that refuses to create a public storage bucket is worth a great deal more than a dashboard listing the ones that already exist.
Rehearse the Cutover, Including Going Back
For anything that matters, the cutover is a scripted event with named jobs, a start time, a go or no go point, and a way back that has been tested rather than described. The way back is not a formality. It is the thing that makes attempting the move reasonable at all, because without it the only option at three in the morning is to keep going.
Rehearse with real volumes of data. Copying that keeps up with a test set and falls behind on the real one is something to find out during a rehearsal, not during the freeze.
Plan for the fortnight afterwards. Extra hands, a lower bar for raising something, and somebody watching the bill. Most problems after a move are not failures. They are things being slower or stranger than expected, and they surface in the first two weeks of real use.
