Waves exist for one reason: so that migrating the fortieth site is easier than migrating the first. Everything else about the model follows from that, including the parts that look like project management overhead and are not.
A generalized model helps to think with. It should not be adopted as a plan, because the number of waves and their contents are properties of a specific estate, and any proposal that arrives with the waves already decided has not looked at yours.
A generalized model
None of this is specific to Drupal. Microsoft gives the same instruction for any large estate in its Cloud Adoption Framework: organize large portfolios into migration waves, group the things that have to move together so that all components required for functionality move together, and add one or two complex workloads to each early wave rather than saving every hard case for the end. The sequence below is that practice applied to a Drupal estate.
- Wave 0, platform and automation. The environment, the pipelines, the migration tooling and the acceptance suite. No customer facing site moves.
- Wave 1, representative pilots. A small number of sites chosen because they exercise the patterns, not because they are easy.
- Wave 2, lower complexity. Volume, building confidence and revealing the long tail of small surprises.
- Wave 3, moderate complexity. Sites with real custom code or a handful of integrations.
- Wave 4, integration heavy. Sites whose difficulty is other systems rather than themselves.
- Wave 5, mission critical. Moved last, with the most rehearsal, onto a platform that has by now been operated for months.
- Wave 6, validation and decommissioning. Confirming nothing was left behind, and switching the old estate off deliberately.
Wave 6 is the one dropped when a program runs late, and dropping it is how organizations end up paying for two platforms for two years.
Wave 0 is not a formality
The temptation is to move a site early to show progress. It is the most expensive form of progress available, because every gap in the platform is then discovered while a live site depends on it, and the fix is made under pressure and never generalized.
Wave 0 is complete when four things are demonstrable: a non-production environment can be destroyed and rebuilt from definitions, a release can be built once and promoted, a site can be migrated by pipeline rather than by hand, and the acceptance suite produces a pass or fail report without a person forming a judgment.
That fourth item is what makes the waves cheap. If acceptance is a person browsing, the fortieth site costs what the first did. The reasoning is in the migration factory approach.
Grouping by class, not by department
The instinct is to group by owner: this business unit's sites, then that one's. It is politically comfortable and technically wrong, because it puts unlike sites in the same wave and forces the team to solve several new problems at once.
Group by class instead, where a class is a set of sites for which the same runbook, test depth and acceptance criteria apply. The classification that produces those classes is described in the Drupal site complexity assessment.
Departmental grouping can be honored within a wave rather than as the wave, which usually satisfies the underlying concern, since what an owner actually wants is notice and a say in timing.
What decides the order
Four inputs, in roughly this priority.
- Learning value. Early waves should teach. A site that exercises authentication, a heavy media library and one integration is worth more in wave 1 than three brochure sites.
- Risk. Rising, not flat. The platform should have run for months before it carries what matters most.
- Dependency. Sites sharing a codebase, a domain or an integration may have to move together whether or not they are alike. Multisite arrangements in particular remove the choice.
- Business calendar. Real and frequently discovered late. An academic term start, an enrolment period, a campaign, a filing deadline. Ask early; it will remove weeks from the available window.
The mistakes that cost the most
An easy pilot. Proves simple sites migrate, which nobody doubted, and defers every real finding into wave 2 where it is more expensive and more visible.
Parallel waves too early. Running waves concurrently doubles throughput and halves learning. Overlap once the pattern is genuinely stable, not before.
Waves sized by capacity rather than by class. Filling a wave to occupy the team mixes classes, which is precisely what the classification was for.
No stabilization between waves. A wave is not complete when the sites are live. It is complete when they have run under real traffic through a full cycle, and the findings have been fed back into the tooling.
Skipping decommissioning. The old estate stays up, costs money, and remains reachable. Reachable old sites are a security exposure and a source of confusion in search results.
Wave zero and the retirement decision
Every estate contains sites that should be switched off rather than moved, and the cheapest migration is the one not performed.
The decision needs an owner with authority to say no, and it needs to be taken before wave planning rather than during it, because a retirement decision taken mid-program invalidates the sequence. Retirement is also work: archiving content, releasing hostnames, arranging redirects and keeping evidence. Treat it as a wave item with an owner, not as an absence.
What each wave produces besides moved sites
A wave that only moves sites has wasted most of its value. Three deliverables should come out of each one.
- Improvements to the tooling. Every manual intervention during a wave is a candidate for automation before the next.
- New acceptance checks. Anything that broke after acceptance is something the suite failed to catch, and each should become a check.
- A revised estimate. Effort per site by class, updated with evidence. This is what makes the plan credible to a steering group, and it is the number that should fall.
If effort per site is flat across waves, the waves have become a queue of individual projects and the program has lost its economic argument.
How long a wave actually takes
Wave duration is the question a sponsor asks first and the one most often answered with a number nobody can defend. It is worth breaking down, because the migration itself is rarely the constraint.
For any given site, the elapsed time is the sum of five things, and only the third is engineering.
- Notice to the owner. A site cannot be migrated on a schedule its owner has not agreed. On an estate with many owners this is frequently the longest single element, and it is entirely predictable, which means it can be started early.
- Pre-migration synchronization. The initial copy of database and files. On a large media library this is measured in hours and occasionally in days, and it is the step most often discovered to be slow on the night rather than in rehearsal.
- The migration and validation run. The part the tooling performs. On a mature line this is short and getting shorter.
- The acceptance window. Long enough to see real traffic. Frequently a business day, and it cannot be compressed by adding people.
- Stabilization. Watching the site through a full cycle before the wave closes.
Two implications follow, and both are counter-intuitive to a plan built on engineering effort alone.
Adding engineers does not shorten a wave much. Items one, four and five are elapsed time rather than effort, and they dominate. What shortens a wave is starting item one earlier and rehearsing item two.
Waves can overlap on the non-engineering parts safely. Owner notice for wave three can run while wave two is in acceptance. That is a genuine compression and it does not create the learning loss that running two migration waves concurrently does.
Estimating from the first wave is unreliable in both directions: the pilot is slower than steady state because the line is still being built, and a wave of brochure sites is faster than the class that follows. Estimate per class from evidence, and revise after each wave, which is the third deliverable named above.
Reporting, in terms a sponsor can use
Sites moved is the number everyone asks for and the least informative. Four others are worth reporting.
- Effort per site by class, trending.
- Defects found after acceptance, which measures whether the suite is honest.
- Rework rate, which measures whether the classification is putting unlike sites together.
- Sites retired rather than migrated, which is usually the largest single saving in the program and is invisible in a count of migrations.
When waves are the wrong model
Below roughly ten sites the overhead of wave planning may exceed its value, and a small number of carefully sequenced projects is the honest recommendation. The classification is still worth doing, because it still tells you the order.
Equally, an estate that is genuinely heterogeneous, where every site is unlike every other, does not have classes to group. That is a real finding and it should change the plan rather than be forced into a wave structure that describes nothing.
Wave planning is one deliverable inside planning a Drupal estate migration, and it depends entirely on the inventory that precedes it. The cutover mechanics for each site are in cutover and rollback strategy, and the overall sequence is in migrating Drupal off a proprietary hosting platform. If you have an inventory and no sequence yet, that is a productive conversation.
Sources
The external statements on this page are quoted from the following, each re-read on 10 September 2026.