The word factory does real work here. It is not a claim about scale or speed. It is a claim about where the cost sits: in a factory the expensive part is building the line, and each unit that follows is cheaper than the last. Migrating an estate site by site inverts that, so the fortieth site costs roughly what the first one did and the organization learns nothing it can reuse.
The distinction matters most on estates between about fifteen and a few hundred sites, where a project per site is still imaginable and is the wrong choice.
The lifecycle
Ten phases. The order is the argument.
- Discover. Inventory what actually exists, which is reliably not what the documentation says.
- Assess and classify. Score every site so that alike sites can be treated alike.
- Architect. Design the target once, for the whole estate.
- Build. Stand up the platform from Infrastructure as Code and prove it can be rebuilt.
- Automate. Build the migration tooling and the validation before volume arrives.
- Pilot. Move representative sites and change the plan.
- Migrate in waves. Group by complexity and risk so each wave teaches the next.
- Validate. Against a defined pass mark, the same way every time.
- Stabilize. Watch under real traffic before calling anything done.
- Operate. Hand over to a named operating model.
Phases four and five are the ones organizations compress under schedule pressure, and compressing them is exactly what turns the factory back into forty projects.
What is actually being built
The line consists of five things, and they are the deliverables that make the difference between a factory and a plan.
A classification model. A repeatable way to score a site and place it in a class, so that migration effort can be estimated from evidence rather than from optimism. Described in the Drupal site complexity assessment.
A target environment definition. One set of Infrastructure as Code definitions that produce a site's environment from a small set of inputs. HashiCorp describes Terraform as letting you build, change, and version cloud and on-prem resources safely and efficiently, and reusability across sites is the property being bought. See Terraform and Infrastructure as Code for Drupal.
A migration pipeline. Provision, copy database, transform, copy files, run the Drupal deployment sequence, validate, report. Run the same way for every site in a class.
An automated acceptance suite. The single most important item on this list, and the one most often replaced by a person browsing the site. More on this below.
A runbook per class. What a wave does, who is involved, what the rollback is, and what acceptance means for this class of site.
Automated acceptance is what makes it a factory
If acceptance means a person opening the site and forming an impression, the twentieth migration costs what the first one did. If acceptance is a report produced by a suite, the cost per site falls and the result is comparable across sites and defensible afterwards.
A workable suite checks, at minimum:
- The site responds, and on the expected release.
- Content reconciles: node counts, taxonomy terms, media items, users, matched against the source within a stated tolerance.
- A defined set of URLs return the expected status, including a sample of deep content rather than only the front page.
- Search returns results.
- Each integration authenticates and completes one round trip.
- Authenticated journeys work, not only anonymous ones.
- Files resolve, including private files, which fail differently and more quietly.
- Redirects and legacy paths still resolve.
Two checks earn their place repeatedly. Content reconciliation catches a partial database copy that otherwise looks perfect, because a site missing ten percent of its content renders beautifully. Private files catches a permissions arrangement that did not survive the move, which anonymous browsing will never reveal.
Why per class rather than per site
The factory's economics come from treating alike sites alike. A class is a group of sites for which the same runbook, the same test depth and the same acceptance criteria are appropriate.
Typical classes on a real estate: brochure sites with no integrations and little custom code; content heavy sites with large media libraries; integration heavy sites that talk to other systems; authenticated sites with user accounts and permissions; and a small number of genuinely bespoke sites that are effectively individual projects and should be scheduled as such.
Admitting that last class exists is important. A factory that pretends every site fits a class produces a plan that is wrong about the hardest three sites, which are the ones that will define whether the program is judged a success.
Where the time actually goes
The distribution surprises people who expect the migrations themselves to dominate.
- Discovery and classification take longer than planned, always, because the inventory is wrong and every correction has consequences.
- Building the line is a genuine engineering project with a genuine duration, and it is the phase most vulnerable to being cut.
- The pilot costs more than a later migration and is supposed to. It is buying information.
- The waves are the cheap part, if the previous three were done properly.
- Stabilization and handover are routinely underestimated, and are where a program is judged.
A plan that shows the waves consuming most of the timeline has usually not built a factory.
What the pilot is for
Not to move a site. To discover what the plan got wrong while being wrong is still cheap.
Pick representative sites, not easy ones. A pilot chosen for simplicity proves that simple sites migrate, which nobody doubted, and defers every real finding into wave two where it costs more.
Expect the pilot to produce at least three surprises. The recurring ones: a file path assumption baked into custom code, an integration that authenticated by source address, a scheduled job with no owner, a caching behavior the old platform supplied invisibly, and an editorial workflow that depended on an interface that no longer exists.
If the pilot produces no surprises, be suspicious of the testing rather than pleased with the plan.
The parts of a factory that are not software
Three, and they decide as much as the tooling.
A decision about retirement. Every estate contains sites that should be switched off rather than moved. Migrating a site nobody has updated in four years is the most expensive possible way to learn it was not needed. Someone has to be empowered to say no.
A named owner per site. Acceptance requires somebody to accept. Sites without an owner stall the wave they are in, and they are discovered during discovery precisely so an owner can be found before the wave.
A content freeze policy. Whether editors can publish during a cutover window, for how long, and who tells them. This is a communications problem that becomes a data problem when it is not addressed, and it is dealt with in cutover and rollback strategy.
How the waves are sequenced
The classification determines the grouping, and the grouping determines the order: platform first, then representative pilots, then increasing complexity, with mission critical sites last and a final wave for validation and decommissioning of the old estate.
How many waves, and what goes in them, is a property of your estate rather than of a methodology. Any plan that arrives with the waves already decided has not seen your inventory. The shape and the traps are in sequencing a large estate.
Measuring whether the line is working
A factory that is not measured is a metaphor. Four numbers tell you whether the economics are behaving as the approach promises, and all four are cheap to collect if the acceptance suite exists.
- Elapsed effort per site, by class. The number that should fall. If site fifteen in a class costs what site three did, the line is not being improved and the waves have become a queue of individual projects.
- Defects found after acceptance. The number that measures whether the acceptance suite is honest. A suite that passes everything and is followed by a week of reported issues is testing the wrong things, and each of those issues should become a check.
- Rework rate. How often a site has to be migrated twice. A little is expected in early waves; a persistent rate means the classification is putting unlike sites in the same class.
- Time from cutover to acceptance. If this is growing, stabilization is absorbing work that validation should have caught.
The first of those is the one to report to a steering group, because it is the number that distinguishes this approach from the alternative. It is also the number that will look bad during the pilot and should: the pilot is where the line is still being built.
One practice keeps the line improving rather than merely running. After each wave, spend a scheduled session on what the acceptance suite failed to catch, and convert each answer into a check. A factory improves because findings are fed back into the tooling; without that loop it is simply a schedule with a diagram attached.
When a factory is the wrong answer
Below roughly ten sites the fixed cost of building the line may not amortize, and a small number of carefully run projects is the honest recommendation. The tooling still has value, because it becomes the operating platform afterwards, but the factory argument by itself does not carry.
Above that, the arithmetic changes quickly, and it changes further if the estate is expected to grow.
The factory is the delivery method inside modernizing a Drupal estate. The starting point is always the inventory, and if you would like a second reading of yours, that is the useful first conversation.
Sources
The external statements on this page are quoted from the following, each re-read on 10 September 2026.