Drupal migration is one of those projects that stays comfortably in next quarter’s plan until a date makes it urgent. Two dates are doing that right now, and only one of them is in the future.

Drupal 7 lost official support on 5 January 2025. Any site still running it has been going without security coverage for well over a year. Drupal 10 reaches end of life on 9 December 2026, the same week Drupal 12 is released, after which it receives no further releases of any kind. If you are on either version, the question is no longer whether to move but which path to take and what it will cost.

Where you stand: From Drupal 10 to Drupal 11 is a genuine upgrade — the same site, updated in place, typically two to six weeks. From Drupal 7 to Drupal 11 is not an upgrade at all; it is a rebuild with a content migration attached, and it typically runs three to six months. Confusing the two is the single most expensive mistake in this space, because Drupal 7 sites get quoted as upgrades and then overrun by a factor of four.

The Two Very Different Migrations

The word migration covers two jobs that share almost nothing beyond the name.

Drupal 10 to 11 is an upgrade. The architecture is the same. Your entities, fields, views and configuration carry across. The work is mostly dependency management: making sure every contributed module has a Drupal 11 compatible release, clearing deprecated API calls out of your custom code, and moving to a supported PHP version. It is methodical rather than difficult, and a well-maintained site can be done in a fortnight.

Drupal 7 to Drupal 11 is a rebuild. Drupal 8 rewrote the platform on Symfony components, replacing the module API, the theming layer and the configuration system. Nothing carries over automatically except content, and even that arrives through a purpose-built migration process rather than an upgrade script. Your modules do not exist any more, your theme has to be rewritten in Twig, and your custom code has to be reimplemented against a different architecture.

That second case is why Drupal 7 sites have lingered so long. The honest framing is that you are not upgrading a site, you are building a new one and bringing the content with you.

What Each Drupal Migration Path Costs

Figures below assume UK agency rates and a site of moderate complexity. Complexity here means the number of content types, contributed modules and custom modules, not the number of pages.

Drupal 10 to 11, well-maintained site. Two to four weeks, roughly £6,000 to £15,000. This is the happy case: modules are current, custom code is small, and the main work is testing.

Drupal 10 to 11, neglected site. Four to eight weeks, roughly £15,000 to £35,000. Here the blockers are contributed modules with no Drupal 11 release, custom code written against APIs that have since been removed, and a PHP version that also has to move. Every abandoned module becomes a decision: find a replacement, take over maintenance, or reimplement its behaviour.

Drupal 7 to Drupal 11. Three to six months, commonly £40,000 to £120,000 and higher for large or heavily customised sites. That range is wide because it is really a rebuild budget. The content migration itself is often the smaller half; the theme, the custom functionality and the integrations are the larger half.

Drupal 7 to a different platform. Sometimes the right answer. If the original reason for choosing Drupal no longer applies — the site has become a straightforward marketing site with a blog — then moving to something simpler can cost less than migrating within Drupal, and reduce running costs afterwards. Our comparison of WordPress and custom web development covers where that line sits, and the Drupal web development guide is honest about when Drupal is not the answer.

Why Contributed Modules Decide Your Timeline

Almost every Drupal upgrade estimate lives or dies on the contrib audit, and it is the first thing worth doing.

List every contributed module the site uses, then check each one for a stable release compatible with your target version. What you will find falls into four groups. Some have a compatible release and need nothing. Some have a release candidate or a patch in the issue queue that you can apply through Composer. Some have been abandoned, and you must find a replacement, adopt the module yourself, or replace its function with custom code. And some have been absorbed into Drupal core, which is the pleasant surprise of the exercise.

That audit converts a vague project into a countable one. Until it is done, any quote is a guess, and a supplier who gives you a fixed price without it is either padding heavily or about to raise change requests.

The same logic applies to custom modules, with a different tool. Drupal’s deprecation tooling will scan custom code and report calls to APIs that have been removed or are due for removal, which turns “we have some custom code” into a specific list of files and line numbers.

What Actually Goes Wrong

Certain failure modes recur across almost every Drupal migration.

Configuration drift between environments. If changes have been made directly in the production admin interface rather than exported to configuration files, your staging environment is not a faithful copy and your testing is worth less than you think. Discovering this mid-migration is common and it always costs time.

Content that was never as structured as everyone believed. Drupal 7 sites frequently accumulated content in ways nobody documented: fields repurposed for other things, a taxonomy vocabulary doing the job of a workflow state, HTML pasted into body fields carrying inline styles. A migration surfaces all of it at once, and each case needs a decision from someone who knows what the content is for.

Media and file handling. Drupal’s media handling changed substantially after Drupal 7. Files, image styles and embedded media rarely map one to one, and sites with large media libraries should budget for this specifically rather than assuming it comes free with the content migration.

URL and SEO continuity. This is the one that damages the business rather than the schedule. If URL aliases change without redirects, you lose the rankings the old site earned. Every migration needs a full URL inventory, a redirect map, and verification after launch. Our guide to migrating a website without losing traffic covers that process in detail, and it applies to platform changes just as much as domain changes.

Multilingual content. If the site runs in several languages, expect the migration to take substantially longer. Language handling was rebuilt after Drupal 7, and translated content, translated configuration and language-specific URL patterns each need their own attention.

How to Sequence the Work

The order matters more than most teams expect, and getting it wrong causes rework.

Start with the contrib and custom code audit, before any estimating. Then get the site onto a supported PHP version and the latest release of its current major version, because that removes a whole category of noise from the actual upgrade. Only then attempt the major version step.

Build the new environment alongside the old one rather than upgrading in place. That gives you somewhere to test the content migration repeatedly, which you will need, because migrations are run many times before they are run once for real.

Treat the content migration as code. Drupal’s migration framework lets you define migrations in configuration and re-run them, which means you can reset, adjust the mapping and go again. Teams that hand-fix content in the new site rather than fixing the migration definition end up unable to re-run it, and then a single content change in the old site becomes a manual reconciliation.

Finally, plan a content freeze near the end, and keep it short. Long freezes cause editors to work around you, which produces exactly the drift you were trying to avoid.

Should You Move Off Drupal Entirely?

It is a fair question and it deserves an honest answer rather than a defensive one.

Stay on Drupal when the reasons you chose it still hold: complex content modelling, granular permissions, multilingual requirements, heavy editorial workflow, or accessibility and public sector obligations. Drupal remains genuinely strong at all of these and the upgrade path from here is now stable, with a predictable two-year major release cycle.

Consider moving when the site has drifted away from those needs. Plenty of Drupal 7 sites are now, in practice, a marketing site with news and a contact form. Migrating that within Drupal means paying rebuild prices for capability you no longer use.

The decision should turn on the content model and the editorial workload, not on which platform your developer prefers. If nobody can articulate what Drupal is doing for you that a simpler platform could not, that is informative.

Get the Audit Before You Get a Quote

Mecanik handles Drupal upgrades and migrations as part of our website development services . We start with the contrib and custom code audit, because that is what turns an open-ended project into a fixed scope, and it is worth having even if you then take the work elsewhere.

For Drupal 10 sites the sensible move is to plan the Drupal 11 step now rather than in November, when everyone else is doing it. For Drupal 7 sites the security position is already the argument. If your constraint is capacity rather than expertise, our guide to hiring a Drupal developer covers what to look for.

Tell us which version you are on and roughly how many contributed and custom modules the site uses, and we will tell you which of the paths above you are actually facing.

Related reading: Legacy PHP Modernisation: A 2026 Guide , Symfony vs Laravel in 2026: Which PHP Framework to Choose , API Security: How to Protect a Public API in 2026 and Medical & Healthcare Website Development UK 2026 .

Frequently Asked Questions

When does Drupal 10 stop being supported? Drupal 10 reaches end of life on 9 December 2026, the same week Drupal 12 is released. After that date it receives no further releases, including security fixes, so any site remaining on it is running unsupported.

How much does a Drupal migration cost? A Drupal 10 to 11 upgrade on a well-maintained site typically costs £6,000 to £15,000, rising to £15,000 to £35,000 where modules and custom code are neglected. Drupal 7 to Drupal 11 is a rebuild with content migration and commonly runs £40,000 to £120,000 or more.

Why is Drupal 7 to Drupal 11 so much more expensive? Because it is not an upgrade. Drupal 8 rebuilt the platform on Symfony components, replacing the module API, theming layer and configuration system. Modules must be replaced, themes rewritten in Twig and custom code reimplemented, with content brought across through a purpose-built migration.

How long does a Drupal 10 to 11 upgrade take? Two to four weeks for a site whose contributed modules are current and custom code is small, and four to eight weeks where abandoned modules or removed APIs have to be worked around. A contributed module audit up front is what makes the estimate reliable.

Can I migrate from Drupal to WordPress instead? Sometimes that is the right call, particularly where a Drupal 7 site has become a straightforward marketing site with no complex content modelling, permissions or multilingual needs. Base the decision on your content model and editorial workload rather than on platform preference.