Once the target platform is chosen, the question becomes what moves when. This is where most of the real risk sits and where the least analytical effort usually goes.
The grouping that matters
Not by size, not by team, not alphabetically. By dependency cluster.
Applications that talk to each other constantly should move together. Splitting a chatty pair across two platforms for six weeks means their traffic crosses a boundary it was never designed to cross, and you get performance problems that are nobody’s fault and hard to diagnose.
Building the dependency map is the hard part. Some of it comes from documentation, some from network flow data, and the rest from asking people who know. Budget real time for it; it is the input that makes everything else possible.
The ordering
Wave zero: something that does not matter. A handful of VMs that nobody would notice. The purpose is not to migrate them. It is to exercise the whole process end to end: tooling, change process, validation, rollback, communications.
You will find something wrong. Everyone does. Finding it here costs nothing.
Wave one: low criticality, low dependency, representative variety. Deliberately boring. Include at least one of each shape you will eventually face — a Windows server, a Linux server, something with a database, something with an unusual disk layout — so that each surprise arrives while the stakes are low.
The temptation is to make wave one large to show progress. Resist it. The purpose of wave one is learning, and a large wave teaches you the same lessons more expensively.
Middle waves: the bulk. By now the process is routine. This is where the schedule is made or lost, and the constraint is usually change windows and human attention rather than technology.
Late waves: high criticality. Move these when the process is proven and the team has done it a hundred times. Everyone wants to defer them, which is correct, and the risk is deferring them past the point where the source platform contract expires.
The tail. Applications with certification requirements, vendor dependencies, or owners who will not engage. Identify these at the start, because the tail determines when you can actually switch off the old platform, and a project that has migrated 95% of VMs but cannot decommission anything has not finished.
The two lists to build early
Will not migrate. Applications being retired, replaced, or moved to a service. Confirm this in writing with an owner and a date, because “that is being decommissioned” has a way of remaining true for years.
Cannot migrate yet. Blocked on a vendor certification, an OS upgrade, or a licensing question. Each needs an owner and a target date, and these should be tracked from day one rather than discovered in month eight.
What the change board actually wants
Not a Gantt chart. They want to know: what is the blast radius of one wave, how do we know it worked, and how do we go back.
Have a crisp answer for each. Validation criteria per application, agreed with the owner in advance. A rollback that has been tested, with a decision deadline inside the change window.
A plan with those three things gets approved. A plan with a beautiful timeline and a vague rollback does not, and it should not.
The number that matters
Not VMs per weekend. It is how long you run two platforms in parallel, because that period is when you pay for both, staff both, and hold twice the operational risk.
Optimise the plan to shorten that window, not to maximise throughput in any single wave. They are different objectives and they produce different sequences.