Upgrading from Drupal 10 to Drupal 11: what actually changes
Drupal 11 is a far smaller step than the Drupal 7 to 9 migration was. Here is what the upgrade touches, what breaks, and the order to do it in.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Map content type by type and field by field before writing any migration code.
- Use the Migrate API so the migration is repeatable, not a one-off copy.
- Redirect mapping protects the commercial value of existing rankings.
- Decide the content-freeze strategy before cutover day, not on it.
Map the content before you move anything
WordPress posts and pages rarely map one-to-one onto a well-designed Drupal content model. Custom fields added by plugins over the years usually need consolidating, and taxonomies often need rationalising.
Produce an explicit mapping document: source type, destination type, field by field, with a decision for anything that has no clean destination. Content nobody can find an owner for is a candidate for archiving rather than migrating.
Use the Migrate API
Drupal's Migrate API handles source, process and destination as separate concerns, which makes migrations re-runnable. That matters: you will run the migration many times before the real one.
Write the migration as configuration, run it against a copy of production, review the output, adjust and repeat. Manual copy-paste migration is only viable for very small sites and is impossible to verify.
Protect search rankings
This is where migrations most often cause commercial damage. Crawl the existing site to capture every indexed URL, then produce a redirect map to the new structure before launch.
- Preserve URL structure where it is already sensible; redirect where it is not.
- Carry over page titles, meta descriptions and structured data.
- Keep image alt text — it is content, and it is routinely lost in migrations.
- Submit an updated sitemap and monitor coverage reports through the first weeks.
Plan the cutover
Freeze content editing in the source system for the final migration run, or build a delta migration for anything published during the transition. Decide in advance which is happening, because discovering it on cutover day is expensive.
Keep the old site available internally for a period afterwards. Something will be missing, and having the source to check against turns a crisis into a lookup.
What usually goes wrong
Migrations rarely fail on the main content types. They fail on the edges, and those edges are predictable enough to plan for.
Embedded media inside body copy is the most common problem: WordPress stores images as absolute URLs and shortcodes inside the post content, and a naive migration carries markup that points at a domain you are about to switch off. Plan an explicit pass to rewrite embedded references and re-attach media as entities.
The others worth budgeting for are plugin-generated custom fields with no clean destination, users and their content authorship, comment threads if you are keeping them, and any content that exists only inside a page builder's serialised data — which is often the hardest to extract and the easiest to discover late.
Frequently asked questions
The content migration itself is usually a smaller part of the project than the new build. The variables are the number of content types, how much plugin-specific data needs extracting, and how much the content model is being changed rather than copied.
It should not, if redirects are mapped comprehensively and metadata is carried across. Rankings commonly wobble for a few weeks after any replatform and recover. Damage that persists is almost always traceable to missing redirects or lost metadata.
Yes, and for large sites it is often wise. Move a self-contained section first, verify it in production, then continue. This requires careful handling of URLs and internal links during the overlap, but it substantially reduces cutover risk.
