The migration nobody wanted to quote on.
Every Drupal migration quote is a guess until somebody reads the code. That is why they get avoided: nobody wants to commit to a number for a site with two hundred content types, eleven patched contrib modules and a theme written before Twig.
We start every migration with an audit, and we charge nothing for it. You get a written assessment of what is really in there, which modules have no upgrade path, what the content volume actually is once the abandoned drafts are excluded, and a fixed price against it.
- All published content
- User accounts and roles
- URL aliases and redirects
- Media and file references
- SEO metadata and canonicals
- Contrib with no D10 path
- Deprecated custom code
- Pre-Twig theme layers
- Undocumented core patches
- Views using removed handlers
It is almost never the content that causes the overrun.
Content volume is the thing clients worry about and the thing that matters least. These five are what actually consume the budget.
Contrib with no upgrade path
Every Drupal 7 site depends on modules that were abandoned years ago. Each one needs a replacement, a core equivalent, or a small custom module, and the answer differs for every module.
Undocumented patches
Somebody patched core or a contrib module to fix an urgent problem in 2019 and it was never written down. The behaviour is now load bearing and nobody remembers why.
Field mapping
The unglamorous heart of any migration. Two hundred fields across forty content types, some of which changed meaning over the years, and all of which have to land in the right place.
Media and inline references
Drupal 7 file fields become media entities, and references embedded inside body text have to be rewritten. Miss this and images vanish from old articles after launch.
Redirects and SEO
If the URL structure changes at all, a redirect map is required, and it needs testing against real top-performing URLs from analytics rather than a handful of samples.
Editorial downtime
The content team cannot stop working for six weeks. That constraint shapes the whole cutover plan, and pretending otherwise is how launches slip.
Five stages, and you can stop after the first.
Read the site, not the brief
We go through the codebase, the contrib list, the custom modules, the content model and the analytics. The output is a written document: every module with no upgrade path and what we recommend for it, the real content volume once abandoned drafts are excluded, the risks, and a fixed price. This costs nothing and it is yours whether or not you continue.
Build the target platform
A clean Drupal 10 or 11 install with the content model rebuilt properly rather than copied. This is the one chance to fix a data model that has drifted over a decade, and it costs almost nothing to do while everything is being touched anyway.
Move content, then verify it
Migrations written with the migrate API so they are repeatable rather than a one-off script. We run them repeatedly against production data, and every run produces a comparison report of counts and spot checks against the source.
Protect the traffic you already have
URL aliases carried across, a redirect map built for anything that changed, and testing against your highest-traffic URLs pulled from analytics. Metadata, canonicals and structured data verified page type by page type.
Switch without a maintenance window
A final content sync, then the switch at DNS or load balancer level. The editorial team keeps working on the old site right up to the day. Two weeks of close monitoring follows, because migration problems surface in the second week rather than the first.
Three of them, on live platforms with real editorial teams.
Each was led by our founder through the agency named or described. Full details on the homepage.
A university art museum, US
Migration to Drupal 10 alongside custom theme and module development, with DDEV environments and Playwright smoke tests catching route and redirect problems before staging.
A private college, US
A complete redesign with new features built in, plus a migration carrying the platform from Drupal 8 all the way to Drupal 11, with performance and security work throughout.
A data centre and colocation provider, US
A rebrand carried through every template, then a redesign adding new features, then the migration from Drupal 9 to 10. Three projects in sequence on a live site with no dark window.
What people ask before committing to a migration.
Is Drupal 7 still supported?
Can you upgrade Drupal 7 directly to Drupal 11?
How long does a Drupal migration take?
Will the site go offline during the migration?
What happens to our SEO?
What about contrib modules that do not exist for Drupal 10 or 11?
Do you migrate media and file references?
Can you migrate from platforms other than Drupal?
Do you clean up content during the migration?
What do we get at the end?
Send us the site you have been avoiding.
Give us read access to the repository, or just the URL and a rough idea of the content volume. Within one working day you get a reply from the engineer who would run the migration.
Before anything is signed, you get a written technical assessment: the real scope, where the risk sits, what we would build differently and why, and a fixed price against it. It costs nothing and it is yours to keep either way.