Everything else in an estate migration depends on this. Sequence, effort, test depth, rollback design, staffing and acceptance criteria all follow from knowing which sites are alike, and none of them can be planned honestly before that.
This is the checklist. It is written so an organization can run it on its own estate, and the output is a complexity matrix rather than a report.
What you are scoring, and why not effort directly
The temptation is to estimate days per site. That produces numbers nobody can defend and that vary with whoever produced them.
Score the factors instead, on a simple scale, and let the classes emerge from the pattern. Two sites with similar profiles genuinely belong in the same wave, with the same runbook and the same acceptance criteria. That is what makes a factory possible rather than a series of estimates.
The factors
Application
- Drupal version. Current, one major behind, or unsupported. An unsupported version is a rebuild rather than a migration and belongs in its own class.
- Custom modules. Count and, more importantly, what they touch. A custom module doing display logic is minor; one integrating with a payment system or writing to a filesystem path is not.
- Custom theme. Whether it is a light subtheme or carries substantial logic of its own.
- Contributed modules. Count, and whether any are unmaintained or patched locally. A locally patched module is a migration risk with a person's name on it.
- Configuration management. Whether configuration is exported to code today. If it is not, that work is part of the migration.
Data
- Database size. It sets synchronization time and therefore the shape of the cutover window.
- File volume and count. Both matter. Many small files behave differently from few large ones, and a copy step measured in hours changes the plan.
- Private files. Present or not. Their permission model rarely survives a move unexamined.
- Content velocity. How much changes daily, which decides whether a freeze is viable.
Connections
- Outbound integrations. What the site calls, and how it authenticates.
- Inbound integrations. What calls the site. Consistently the most underestimated item, because these do not appear in the codebase and their owners are often external.
- Authentication. Local accounts, single sign on, or a directory. Federated authentication frequently needs a change on the identity provider side, with its own lead time.
- Search. Internal or an external service. An external service is part of the environment and part of the migration.
- Scheduled jobs. What runs, how often, and who owns it. Jobs with no owner are found here or during an incident.
Operations and risk
- Traffic. Volume and shape, including whether it is spiky and predictable.
- Business criticality. What happens if it is down for an hour, and who says so.
- Recovery objectives. How much work may be lost, and for how long may it be gone. NIST defines these as the recovery point objective, the point in time to which data must be recovered, and the recovery time objective, the maximum amount of time a resource can remain unavailable.
- Compliance and data sensitivity. Whether the site holds personal data or carries a regulatory obligation.
- Editorial workflow. Whether editors depend on a platform specific interface that will not exist afterwards.
- Technical debt. The judgment item. Modules abandoned, workarounds nobody remembers, a theme with three generations of approach in it.
- Ownership. Whether a named person can accept this site. Sites without an owner stall their wave.
Scoring, kept deliberately crude
Score each factor low, medium or high. Resist a weighted numeric model: it produces a single number that hides the shape, and the shape is what tells you which sites belong together.
Two rules keep it honest. Any single high on a risk factor promotes the site, regardless of the rest, because a small site with a statutory deadline is not a simple migration. And score from evidence, not from memory. Much of this can be collected automatically from the codebase and the database; the parts that cannot, mainly ownership and inbound integrations, are exactly the parts that will surprise you.
Turning scores into classes
Sort by profile and the groups usually appear on their own. Typical classes on a real estate:
- Brochure. Current version, little custom code, no integrations, low criticality. Volume for early waves.
- Content heavy. Large media libraries. The distinguishing risk is synchronization time.
- Integrated. Difficulty is other systems and other people's change processes.
- Authenticated. User accounts, roles, private files. Test depth is higher and permission errors are quiet.
- Legacy. Unsupported version or unmaintainable custom code. A rebuild, and should be scheduled as one.
- Bespoke. A small number that fit nothing. Individual projects, and saying so early is better than discovering it in wave four.
Admitting the last class exists is important. A plan that pretends every site fits a class is wrong about the hardest three, which are the ones by which the program will be judged.
What the matrix should decide
If it decides nothing, it was a documentation exercise.
- Pilot selection. Representative, not easy. A pilot should exercise several classes' patterns.
- Wave sequence. Risk rising, learning front loaded. See sequencing a large estate.
- Test depth per class. A brochure site does not need the test suite an authenticated transactional site needs.
- Rollback design per class. Restore to a point, reverse and reconcile, or forward fix only. See cutover and rollback strategy.
- Acceptance criteria per class. Written before the wave, so acceptance is a check rather than an impression.
- Staffing shape. Which classes need specialist involvement and which can run on the line.
- Retirement candidates. Frequently the largest single saving in the program.
The retirement conversation
The assessment reliably finds sites that should be switched off. Low traffic, no owner, unmaintained, superseded, or duplicating another site.
Migrating a site nobody has updated in four years is the most expensive possible way to learn it was not needed. The decision needs somebody empowered to say no, and it needs taking before wave planning, because a retirement decision taken mid-program invalidates the sequence.
Retirement is itself work: archive the content, arrange redirects, release the hostname, keep the evidence. Budget it rather than treating it as an absence.
What can be collected automatically, and what cannot
Most of the application and data factors can be gathered by script across an estate, and should be, because manual collection across forty sites is where errors enter.
Four things cannot be automated, and they are the four that most often change the plan: who owns this site, what calls it from outside, what the business considers acceptable downtime, and whether the editorial workflow depends on something that will not exist. Those require conversations, and the conversations have lead times, which is why the assessment starts early.
The findings that recur on almost every estate
Assessments across large Drupal estates tend to surface the same handful of things. Knowing them in advance does not remove the work, but it does stop each one arriving as a surprise that reopens the plan.
- The inventory is incomplete. Sites exist that nobody listed: a campaign microsite, a subdomain from a project that ended, a staging environment that has been serving real traffic for two years because somebody linked to it.
- Several sites should be retired. Usually a meaningful proportion, and the decision has no owner because nobody has ever been asked to make it.
- Configuration is not fully in code. The pipeline story assumes it is, and the gap becomes migration work rather than a footnote.
- A module has been patched locally. Working, undocumented, and known to one person. It will not survive an update unless it is found now.
- An integration authenticates by address. It will break at cutover, silently, and the fix needs a third party's change process.
- Nobody knows the recovery objectives. They have never been set, so the current arrangement is whatever the platform happened to provide.
- A scheduled job has no owner. It has run nightly for years. What it does is inferred from its name.
- Editors depend on a platform feature. A preview arrangement, a workflow, a media interface that the new platform will not reproduce without deliberate work.
Two of these are worth treating as first class program risks rather than findings. Inbound integrations are the commonest cause of a cutover that goes wrong in a way nobody detects for days, which is why they are covered separately in cutover and rollback strategy. And unset recovery objectives mean the architecture is being sized by guesswork, which is why backup and disaster recovery starts with the two numbers rather than with the tooling.
None of these is a reason to delay. They are the reason to assess before planning rather than after committing to a date.
How long it takes
For an estate of a few dozen sites, the automated collection is days and the conversations are weeks. The weeks are not slack; they are what makes the rest of the plan real, and compressing them produces a schedule that looks decisive and is fiction.
The assessment is the first deliverable of Drupal modernization and migration engineering, and everything in the migration factory approach depends on it. If you have an estate and no matrix, that is the right place to begin.
Sources
The external statements on this page are quoted from the following, each re-read on 10 September 2026.