Turn Migration Disruption Into Strategic Advantage
Drupal 10 reaches end-of-life in December 2026, and the European Accessibility Act is putting fresh scrutiny on public-facing sites. If you're on Drupal 10, a migration is coming whether you plan for it or not.
Most teams treat that migration as a like-for-like move: get the content from the old site onto the new one, change as little as possible, ship it. That instinct is understandable — migrations are complex, time-consuming, and stressful, and adding scope sounds like adding risk.
But you're already paying for the two most expensive parts of any data project: a content freeze and a full-site QA pass. Those hours are sunk the moment you commit to the migration. The real question is whether you spend them moving content as-is, or use them to fix the things you'd otherwise pay to fix all over again in two years.
What that looks like in practice:
- Rationalize the content. Evaluate what's actually earning its place. Archiving or retiring low-value content shrinks the migration itself.
- Improve the data structure. Content with information buried in HTML is content you can't query, reuse, or expose through an API. Structured fields keep your options open — the same clean data feeds search indexing, an AI assistant, or an MCP server later, if you ever want it. None of that works on a blob of HTML.
- Future-proof the dependencies. Modules and integrations with a known end-of-life are a release you'll have to do anyway — Field Collection giving way to Paragraphs, older block layouts to Layout Builder. Doing it now folds that work into a schedule you've already committed to.
The honest trade-off: this adds cost and time to the migration up front. It isn't free, and anyone who tells you it is hasn't done one. What it buys you is not having to freeze, test, and disrupt the site a second time for work you could have done once.
Two hard-won notes. Map your entities, relationships, and edge cases before you migrate, not during. And not everything is worth automating — for small or one-off cases, manual entry is often the cheaper, safer call.
Evolution, not revolution. The best time to improve your data is while you've already got the hood open.