Drupal migration and upgrade

Drupal 10 loses support on 9 December 2026

If your site runs on Drupal 10, you have until 9 December 2026 to upgrade.
From that date, no more releases appear for Drupal 10, including security updates.
That's the same week Drupal 12 comes out.
Drupal 10.6.0 is the last minor release to be published.

What that means in practice: every vulnerability found in core or in a contributed module after that date stays open on your site.
For a brochure site, that's annoying.
For a site that processes personal data, handles payments or falls under a public tender, it's a demonstrable risk you need to be able to account for.

The good news: if you're on Drupal 10, the step to Drupal 11 isn't a rebuild.
Since Drupal 8, a major upgrade has become an update, not a migration.
That's exactly why putting it off is such a waste.

Which version are you running, and what does that mean

Not sure which version you're running? You'll find that in the admin screen under Reports, Status report.
Or ask whoever currently manages your site.
If you don't have access, I can usually estimate it from the outside.

Drupal 10 to 11 is an upgrade, not a migration

With an upgrade from 10 to 11, your site stays your site: same content, same structure, same theme.
What needs to happen sits in the technology underneath.

• Cleaning up deprecated code. Drupal flags functions that are going away as deprecated well in advance.
  What was still a warning in Drupal 10 is an error in 11.
  This mainly affects custom modules and the theme.
• Checking modules. Every contributed module needs a Drupal 11-compatible release.
  For most widely used modules that's already the case.
  For niche modules sometimes not, and then the question is: patch, replace or drop.
• Server environment. Drupal 11 has higher requirements for PHP and the database.
  That's often just a switch at the host, but it still needs to happen and needs to be tested.
• Theme and front end. Twig has moved to a new version.
  That affects templates using old syntax.

How long this takes depends almost entirely on the amount of custom work.
A site that stays close to standard Drupal and uses tidy modules is a straightforward project.
A site with years of accumulated custom work needs an assessment first, before anyone can name a timeframe.

From WordPress to Drupal

That step makes sense when you're hitting the limits of WordPress, not because Drupal is inherently better.
Concrete triggers I see in practice: complex content structures with lots of interrelations, genuine multilingualism, strict requirements around permissions and workflows, or an integration with systems that goes beyond what a plugin can do.

If you're running a blog or a straightforward business site that's doing fine, switching is spending money on a problem you don't have.
I'd rather say that upfront than afterwards.

Technically, that kind of migration runs via the WordPress export or directly on the database.
Things to watch are the URL structure, which you need to preserve or redirect properly, and the media, which is often stored more messily than people think.

How that kind of project runs

1. Assessment. Which version, how much custom work, which modules, which integrations, how the hosting is set up.
   This establishes what the work actually is, rather than what it looks like.
2. Plan with a budget. What moves over, what's dropped, what gets replaced.
   Including an estimate in days and the order of execution.
3. Execution on a separate environment. The existing site keeps running.
   The migration is set up to be repeatable, so you can run it multiple times with fresh content.
4. Checks and go-live. Redirects, structured data, accessibility and speed are covered.
   A migration is the moment to get those things right, since you're already in the code anyway.

Something I think matters: a migration isn't a good moment for a redesign.
Two big changes at once make it impossible to pin down where a problem is coming from.
Migrate first, then keep developing.

Bringing search engines and AI along in the migration

The biggest risk in a migration isn't the technology, it's the addresses.
If your URL structure changes without redirects in place, you lose in one go whatever search visibility has been built up.
That's preventable, but only if you set it up in advance.

Concretely: a full inventory of existing URLs before the migration, 301 redirects for everything that changes address, and a check after go-live that the sitemap is correct and structured data is intact.
The same principle applies to AI visibility: schema.org markup and an llms.txt that still point to existing pages after the move.