Drupal 7 Migration Scope Builder

The gap it fills

Drupal 7 reached end of life in January 2025, and 170,271 sites still reported Drupal 7 in the week of 2026-09-13. The technical path is documented. What is not written down anywhere is the proposal: the phases, the quantities, the exclusions and the number at the bottom.

There are three artifacts in a migration decision, and until now we only sold the last one. The free scanner says what is in the codebase. The paid workbook is where decisions get tracked once the work is approved. This kit is the one in between — the scope that gets it approved in the first place — and it is generated from the buyer's own scan rather than typed into a template.

Every quantity in the document traces to something the scan measured: the contributed projects that move across as they are, the ones needing a decision first, custom modules, Features modules, custom themes, and one work package per migration kickoff decision with code behind it, sized by the occurrences the scan counted.

The three commands

Node.js 18 or later is the only requirement. No install step, no dependencies, no account, no API key and no licence key. The kit never connects to the network, never reads environment variables, and writes only into the output directory you name.

1. Scan the codebase with the free scanner, which reads only and never connects to the network:

node d7-scan.mjs /path/to/drupal7 --json > inventory.json

2. Generate a rate card for that site, listing exactly the work packages this codebase needs:

node scope-builder.mjs inventory.json --init-rates rate-card.json

Open it and fill in hourly_rate and every hours_per_unit — your effort for one unit of that package: one project, one module, one occurrence. Optionally set contingency_percent, or give a single package its own hourly_rate to price a different role.

3. Build the documents:

node scope-builder.mjs inventory.json --rates rate-card.json --out ./scope --client "Client name"

The options, which are also in --help:

• --init-rates <file> — write a rate card listing exactly this site's work packages, then stop.
• --rates <file> — your filled-in rate card.
• --out <dir> — where to write the documents (default ./scope).
• --client <name> — client or project name to print on the documents.
• --destination <name> — destination version label (default Drupal 11).
• --help — the same list, from the tool.

What it writes

Five files, into the directory you name:

• scope-summary.md — the scope, phase plan, assumptions, exclusions and estimate in Markdown, for a ticket or a wiki.
• scope-summary.html — the same document, styled for print. Open it in a browser and print to PDF to send to a client.
• work-packages.csv — one row per work package: quantity, hours, rate, cost, and the scan evidence that put it there.
• module-decisions.csv — every contributed project, its Drupal 10/11 status, and blank columns for your decision, replacement, owner and hours.
• risk-register.csv — risks derived from the scan, each with the evidence behind it and a suggested mitigation, plus blank likelihood, impact and owner columns.

The scope summary groups work into five phases, and a phase appears only if the scan found work for it:

1. Discovery and inventory
2. Content model, modules and theme
3. Content, URLs, files and users
4. Rehearsal
5. Acceptance and launch

In the zip: scope-builder.mjs, a README.md, LICENSE.txt, CHANGELOG.md, and an example/ folder holding a scan, a filled-in rate card and the five documents it produces — so the first thing you can do is read a finished scope.

It ships no default hours

Practical Modules has no measured data on how long a Drupal 7 migration takes, so this kit does not pretend to. Every hours_per_unit starts empty, and the builder refuses to produce an estimate until you have filled them all in — it names each missing figure instead of guessing.

Run it against an incomplete rate card and you still get the scope, the phases, the quantities and the risks; the estimate section says plainly that it was not calculated. What the kit contributes is the structure — which work packages this codebase actually needs, how large each one is, and what can go wrong. The numbers are yours, which is what makes the estimate defensible when a client asks where it came from.

This is the product's main claim, and it is the one we are most often asked to break. We will not: an hours figure we invented would end up in a document a client signs.

What the output looks like

The kit ships a worked example — a scan of a fictional Drupal 7 codebase with 7 contributed projects, 6 of them needing a decision — and a rate card filled in so the document is priced. This is the shape of the estimate table at the end of the scope summary:

## Estimate

| | |
| --- | ---: |
| Hours | 184 |
| Subtotal | USD 18,400.00 |
| Contingency (15%) | USD 2,760.00 |
| **Total** | **USD 21,160.00** |

Above it sit the phase tables, a sentence of evidence under every work package naming the patterns the scan matched, any kickoff decision with no code behind it listed as in scope but not sized from code, the assumptions and exclusions, and 12 risks with the register in a CSV beside it. Under that, a provenance block records the codebase path, when it was scanned, by which version of the scanner, when the contributed release data was collected, and the sentence the document must always carry: the scan is a pattern search, it finds where to look, and every quantity should be confirmed before the document becomes a commitment.

The figures in the example are illustrative placeholders chosen to show the output. They are not benchmarks, not a recommendation, and not drawn from any real project.

Who it is for, and who it is not

• A Drupal agency scoping or quoting a Drupal 7 migration.
• A freelance developer who needs a proposal a client will sign.
• An in-house team asking a budget holder to approve the project.

It is the wrong purchase if you want the migration run or generated for you — it writes documents, not code. It does not measure content volume, revision depth, file sizes or data quality: the scan reads code, not the database, and those drive migration runtime, so you have to measure them separately. It does not replace technical discovery, a security review, backups, staging or testing.

Try the free things first

Everything this kit reads is free, and it is free on purpose — you should be able to see your own codebase's numbers before deciding whether the document around them is worth $39.

• The inventory scanner produces the inventory.json this kit consumes. One file, MIT licensed, no dependencies, also in VS Code.
• The kickoff checklist is the ten decisions the work packages are organised around, each with a test for telling when it is genuinely settled.
• Every contributed module's Drupal 10/11 status and every theme's, which is where the module decision sheet's verdicts come from.

If the free scan and the checklist are enough for your proposal, use them and keep your money.

Licence, support and refund

Licensed for use throughout one organisation, including work you deliver for clients. You may not resell or redistribute the kit itself. The documents it produces are yours to give to a client, including in a commercial proposal, with no attribution required.

Questions or problems: hello@practicalmodules.com. Request a refund within 14 days of purchase by emailing that address — no form and no reason required.

The price is USD 39, one time. There is no subscription, no licence key to activate, and no consulting included. It is a launch price rather than a measured one, and it stays fixed until there is customer feedback.

Questions

Does it migrate my site? No. It produces the scope, plan, risks and estimate around the migration. The import itself is done with Drupal's own migrate tooling.

Where do the hours come from? From you. The kit ships none and will not estimate without them.

Do I need the workbook too? No. They are independent: the workbook is a spreadsheet you fill in as the work proceeds; this kit generates the document you write before the work is approved.

Is the scanner included? The scanner is free and always will be. Download it from its page or install the free VS Code extension; the kit reads its --json output.

Can I run it on a client's codebase? Yes, and nothing leaves the machine: it reads the two files you name and writes to the directory you name, with no network access at any point.

What about Drupal 9 or 10 as the destination? The destination label is an option (--destination), and the contributed-project verdicts cover Drupal 10 and 11 releases, so a Drupal 10 destination is fine. The work packages are about leaving Drupal 7, which is the part that does not change.