Business Challenge
Wave 1 goes out on a Friday night. Six servers, an application nobody thought was complicated. By Saturday morning it is up in AWS and failing: it cannot reach a database that is still on-premises, because the database belongs to a different application, owned by a different team, scheduled for wave 9.
The wave plan was built the way most of them are — exported from the CMDB, sorted by application, split into rows of roughly equal size. It encodes what somebody once wrote down about how the estate is put together. The estate has been running for eleven years since then.
AWS is precise about this. The unit is the move group — “a block of servers or applications that should be moved together in a group” — and a wave is one or more move groups. The application is not the boundary, because an application can share a database with two others, and a server can host databases for several applications.
Which means the first question is not which applications go in wave 1. It is what cannot be separated. Everything after that is packing.
Turn on discovery, collect every observed connection, and group anything that communicates. The result is a single move group containing the entire estate, because every server talks to Active Directory, DNS, NTP, the monitoring agent and the backup server.
AWS names the exception explicitly: a dependency on Active Directory “should not be considered when defining move groups because it is a common dependency for all applications”. Instead you build the domain controller in the cloud first, and it stops being a constraint on anything.
That is the actual craft in wave planning, and it is a judgement rather than a query. Shared services get built ahead and excluded. Genuine couplings — a shared database, an ETL job, a file store two applications both write to — bind a group. Getting that line wrong in either direction produces either one unmovable wave or a Friday night like the one above.
Waves are usually sized by dividing the estate by the number of weekends available. AWS sizes them from the other end — the throughput of the people doing the work. Its stated measure is that a team of four architects can migrate up to 50 servers in a week for rehost patterns, and that a wave should not exceed 50 servers in total.
It also says the first waves should be under 10 servers, in lower environments, deliberately chosen to be dull. And to keep only 4 to 5 waves planned ahead rather than mapping the whole programme up front, because the plan will change and the later waves are the ones that change most.
Every estate has a CMDB, and every CMDB is a record of intentions. It has the applications somebody registered, the owners who have since left, and the dependencies documented at go-live. What it does not have is the connection somebody opened during an incident in 2019 that nobody removed, which is exactly the kind of thing that fails a cutover.
AWS's guidance is to use the CMDB and then validate it — automated discovery for what actually communicates, and the application and infrastructure teams to confirm the manual parts. Neither source is sufficient alone: discovery sees traffic but not intent, and the CMDB records intent but not traffic.
Architecture
Three layers, in order
Wave planning fails when it is treated as one step. It is three, and each one produces the input to the next.
Layer one: what communicates. Observed inbound and outbound connections per server, collected over long enough to catch the monthly jobs. This is data collection, not decision-making, and it is the only layer where a tool does the work.
Layer two: what must not be separated. Every dependency is classified as either a shared service to be built ahead, or a coupling that binds. AWS's own move group rules are a good starting set: applications sharing a database migrate together, applications with the same owner migrate together, applications with the same patch window migrate together. The second and third are not technical dependencies at all — they are the reason a wave succeeds or gets rescheduled, which is a distinction most dependency tooling cannot make.
Layer three: packing. Move groups are combined into waves under the constraints — under 50 servers, smallest and dullest first, lower environments before production, and never more than the migration team can cut over in the window. A move group is never split. If a move group exceeds the wave cap on its own, that is a finding about the architecture, not a packing problem.
Build the shared services first, and they stop being dependencies
The Active Directory rule generalises, and it is the most useful idea in the whole exercise. Anything that everything depends on should exist in the target before wave 1: the domain controller, DNS resolution, the monitoring and backup endpoints, the certificate authority, the patching infrastructure, the network path back to what remains on-premises.
Build those first and they disappear from the dependency graph — not because the dependency went away, but because it is satisfied on both sides of the move. What remains after subtracting them is usually a surprisingly small number of genuine couplings, and that is the graph worth planning against.
Why the plan is deliberately short
A programme with 340 servers and a lease expiring has an obvious temptation: plan all thirty waves now, publish the schedule, report against it. AWS advises the opposite — keep four or five waves planned ahead and treat wave planning as continuous.
The reason is that the early waves change the later ones. Wave 1 discovers that the discovery tool missed a class of connection. Wave 3 discovers that one team cannot do Saturdays. A thirty-wave plan does not survive those, and worse, it makes each discovery look like a slip against the schedule rather than what it is — the process working.
Why This Architecture Holds Up
It fails cheaply and early. First waves under 10 servers, in development environments, on applications nobody will miss for an afternoon. Every migration programme's first cutover teaches something expensive; the only question is what it costs to learn it. AWS's guidance is explicit about deliberately spending that lesson on something dull.
It sizes to the constraint that actually binds. The limiting factor is almost never how many servers exist — it is how many the team can cut over, validate and support in a window, while also handling the previous wave's fallout. A plan sized from the portfolio produces waves nobody can execute; a plan sized from throughput produces waves that land.
It puts judgement where a tool cannot go. Discovery tooling answers what talks to what. It cannot tell you that Active Directory is infrastructure and the shared Oracle instance is a coupling, or that two applications with the same owner should move together because that owner can only attend one cutover. Those decisions are the plan.
And it degrades gracefully. A move group that has to be rescheduled moves as a unit, so the blast radius of a change is one group rather than a re-plan. That is only true if the groups were formed properly in the first place — which is the argument for spending the time there rather than on the schedule.
Key Architecture Decisions
| Situation | Decision | Because |
|---|---|---|
| Every server talks to Active Directory, DNS and monitoring | Build them in the target first; exclude from grouping | AWS's stated rule. A dependency common to everything groups everything. |
| Two applications share a database instance | One move group | A genuine coupling. Splitting it is the Friday-night failure. |
| Two applications share an owner who can attend one cutover | One move group | Not a technical dependency, and still the thing that reschedules a wave. |
| Sizing wave 1 | Under 10 servers, dev or test, low complexity | The first cutover teaches an expensive lesson. Choose what it costs. |
| Sizing a steady-state wave | Cap at 50 servers, against team throughput | AWS's measure: four architects, up to 50 servers a week, rehost. |
| A single move group exceeds the wave cap | Escalate it as an architecture finding | Never split a move group. A 60-server atomic unit is the real problem. |
| Pressure to publish the full schedule | Plan 4–5 waves ahead, continuously | Early waves change later ones. A full plan turns learning into slippage. |
| CMDB and discovery data disagree | Discovery decides couplings; teams confirm intent | The CMDB records what was built. Traffic records what is running. |
Closing Thought
Wave planning looks like scheduling, so it gets handed to whoever owns the plan. It is really a sequence of architectural judgements wearing a spreadsheet: what is infrastructure and what is coupling, what must move as a unit, what the team can actually absorb in a weekend.
The tooling has genuinely improved — agentless collectors, automated dependency mapping, complexity scoring. None of it makes the decision, because the hard part was never finding the edges in the graph. It was deciding which edges are allowed to matter.
A plan that gets that right survives contact with the first cutover, and a plan that does not gets rewritten on a Saturday morning by someone who did not build it.
Migration — AWS DMS and what change data capture actually guarantees. Why a heterogeneous migration is two problems wearing one name, what the schema conversion step cannot do for you, and the difference between a cutover that is reversible and one that only looks it.
Comments