Still running Drupal 7? Your migration starts here

"End of life" gets used loosely, so here is what it means in practice for your site:

• No more security updates from the Drupal community. Vulnerabilities found in Drupal 7 will not be patched.
• Contributed modules are unmaintained. The add-on features your site depends on have stopped receiving fixes.
• Server compatibility is drifting. Hosting providers have moved to PHP 8.2 and beyond. Drupal 7 was never designed for it, and the gap widens with every release.
• It shows up in compliance checks. External security scans flag Drupal 7 as insecure, which can affect PCI, GDPR, Cyber Essentials and ISO 27001 assessments.

None of this means your site will break tomorrow. It means the risk is accumulating, and it is now the kind of risk that turns up in an audit rather than one you can quietly carry.

If you've looked into this already, you've probably found that it isn't a straightforward update. Unlike going from Drupal 10 to 11, which is relatively painless, moving off Drupal 7 is a bigger undertaking. The architecture changed fundamentally at Drupal 8, which means in practical terms:

Your content is migrated, not upgraded. Pages, articles, users, files and taxonomy are moved into a brand new Drupal installation using the Migrate API. It is a structured, repeatable process — not a database update you run once and hope.

The theme is rebuilt. Drupal’s theming system changed completely. Your site's appearance is recreated using modern Twig templates. That's also an opportunity to fix the things about the current design that have been annoying you.

Modules are replaced, not carried over. Many Drupal 7 modules have been absorbed into core, superseded, or abandoned. Each one on your site needs assessing and mapping to a modern equivalent.

Custom code is rewritten. Anything bespoke built for Drupal 7 has to be rewritten for Drupal 10 or 11. The APIs, standards and patterns are all different.

That sounds like a lot, and for an in-house team without deep Drupal experience it is. For someone who does this regularly it is a well-understood process with proven tools and predictable outcomes.

I've migrated several organisations from Drupal 7 to modern Drupal over the last couple of years, at both ends of the scale — from a single-page resource centre through to a large, highly visible site holding thousands of scientific articles and related resources. Whatever size yours is, I've very likely done one like it, and I can tell you early and honestly what it will involve.

1. Discovery & audit. I review your existing site: content types, modules, custom code, integrations, theme complexity and content volume. This gives us both a clear picture of scope and lets me give you an accurate estimate.
2. Planning & specification. We agree what's migrating, what functionality to keep, replace or retire, and whether to replicate the design or refresh it. You get a written migration specification.
3. New site build. I set up a fresh Drupal 10 or 11 project with the right modules, content types and configuration, and build the theme.
4. Content migration. Using the Migrate API, I build scripts that move your content across. This is iterative — run, review, refine, re-run — until the output is right.
5. Testing & review. You review the new site and test everything that matters to you. I fix what needs fixing.
6. Launch. DNS switches over, a final content sync captures anything that changed since the last run, and the site goes live. I watch it closely for the first few days.
7. Ongoing support. After launch I can host, maintain and keep developing the site — I know the codebase better than anyone at that point.

A migration is more than moving what's already there — it's the point where the things that have been bothering you about the old site for years actually get fixed: features you gave up asking for, an information architecture that made sense a decade ago, a design that has aged. We agree what is changing at the planning stage, not halfway through the build.

It is the start of a working relationship, too, not the end of one. Once I have built your new site, I know the codebase better than anyone — the natural person to keep developing it, not just keep it patched.

Running something other than Drupal 7? The same problem — a platform that has started holding you back — comes up just as often for people on Squarespace, Wix or Joomla. See Platform Migration for how that works.

Every Drupal 7 site is different, so I quote after auditing yours rather than guessing from a form. What I can tell you is that as an independent specialist I do not carry agency overheads, and my rates are significantly lower than agency rates for the same quality of work. For most charities and SMEs, that difference is the reason the project happens at all.

The audit itself is free and comes with no obligation. If the answer is that you should wait, or that extended support is the sensible move for now, I will tell you that.

I am Nathan Simmonds, a software engineer and Drupal specialist based in Bristol with over 15 years of Drupal experience.

I spent seven years at a top-20 UK digital agency working on projects for The Wildlife Trusts, Anthony Nolan, Parkinson's UK and the Institute and Faculty of Actuaries. Since going independent I have worked with clients including RELX, the FTSE 100 publishing and analytics group, and Cohesion, whose product was later acquired by Acquia. Drupal 7 migrations have been a large part of my work for the last couple of years — content moved with the Migrate API, custom migration plugins where the content structure needs them, and complex structures like entity references, media and paragraphs handled properly rather than flattened. I am a member of the Drupal Association.

When you work with me, you work directly with the person who writes the code, manages the server, and fixes the bug. There is no account manager in between, and nobody hands your project to a junior once it is sold.