How big a job is your Drupal upgrade?
You probably know your website needs an upgrade well before anyone can say how big the job is. Drupal 10 reaches end of life on 9 December 2026, when its security fixes stop, and Drupal 7, 8 and 9 are already past it. Maybe your security team is asking which version you're on, or a module your site relies on has stopped releasing updates for that version.
The word "upgrade" also covers very different jobs. Moving from Drupal 10 to 11 updates the site you have, while moving off Drupal 7 means rebuilding it on current Drupal and carrying your content across. Until someone has looked inside your site, it's hard to know which job you're facing or what it will take.
An upgrade goes well when the job is measured before it starts, so you know the scope, cost and timeline up front, and every step after that is tested before it reaches your live site.
How we upgrade a Drupal website
There are 2 routes, depending on where you're starting from, and both follow the same 5 steps. Our post on how we upgrade and modernise Drupal sites covers each step in more detail.
| You're on | The upgrade | What it involves |
|---|---|---|
| Drupal 8, 9 or 10 | In place | We bring your code, modules and Drupal core up to the new version. Your content and configuration stay where they are. |
| Drupal 7 or older | A migration | Drupal's architecture changed after version 7, so we build the site on current Drupal and move your content into it with Drupal's Migrate system. |
1. We start with a site audit
Every upgrade starts with a site audit, and the audit is part of the upgrade we estimate for you. It sorts your modules into those with a release for the new version, those that have been abandoned and those you no longer use. We read your custom code for anything the new version will reject, and check your patches and your PHP version.
We'll also ask which features your team still relies on. Anything nobody uses can come out, which makes the upgrade smaller. The audit report sets out your options, from an in-place upgrade to a fresh build, with our recommendation and what each would take.
2. We bring the foundations up to date
First come the parts underneath your site: the PHP version, the Composer packages it's assembled from, and the tools that build and deploy it. We set the project up on Vortex, our open-source Drupal project template, which gives it a tested build and continuous integration from day one.
Then we move each contributed module, the add-ons the Drupal community shares, to a release that supports the new version, and swap abandoned ones for maintained alternatives. Where there's no alternative, or no release yet, we write the compatibility fix ourselves. We check every existing patch and keep, update or remove it.
3. We modernise your custom code
Each Drupal version retires old ways of writing code. Much of that change is mechanical and repeated across many files, so we use Rector, a tool that rewrites code for the new Drupal and PHP versions. PHPStan, a static analysis tool, flags anything left that the new version won't accept, and we bring the code in line with Drupal's coding standards.
4. We upgrade Drupal core, or migrate your content
For an in-place upgrade, Drupal core moves to the new major version at this point, and the whole site is tested again against it. On the Drupal 7 route, your content moves into the new build, piece by piece, until it holds everything you're keeping. Our migrations page has more on that route.
5. We test it and release it
Automated tests run on every change. PHPUnit(Opens in a new tab/window), the standard testing framework for PHP, checks your custom code piece by piece. Behat(Opens in a new tab/window) tests the site the way people use it: each test is a scenario written in plain English that visits pages, fills in forms and checks the result. We write scenarios for the journeys that matter most on your site, and they run on every change until the upgrade is released. Here's one that checks your contact form still sends enquiries:
Feature: Contact form
As a visitor
I want to send an enquiry
So that the right team can reply to me
Scenario: A visitor sends an enquiry
Given I am an anonymous user
And the test email system is enabled
When I visit "/contact"
And I fill in "Your name" with "Sam Example"
And I fill in "Your email address" with "[email protected]"
And I fill in "Subject" with "Weekend opening hours"
And I fill in "Message" with "Are you open on Saturdays?"
And I press "Send message"
Then I should see "Your message has been sent."
And the number of emails sent should be 1Visual regression testing compares the upgraded site with your current one, screen by screen, and flags anything that moved.
The upgrade goes to a staging environment for a full regression pass, then to production at a time you agree, with a way back if anything unexpected appears. Until it's released, we ask for a pause on new features, so any change in behaviour can be traced to the upgrade.
What you get
Everything an upgrade produces stays with your site, for whoever looks after it next.
Your upgraded website
Your site runs on supported versions of Drupal and PHP, with its modules current and its custom code updated. After an in-place upgrade, your visitors see the same site unless you've asked for a change, and visual regression testing checks that.
Automated tests that stay with your site
The Behat tests written for the upgrade stay in your project and check every later change. They're written in plain English, so your team can read what each test covers.
A setup that keeps you current
Your project runs on Vortex, and continuous integration checks every change. We also add Renovate, which proposes package updates as they're released, so updates arrive in small, tested steps and the next upgrade starts from a maintained base.
- The site audit report, with your options and our recommendation
- A written scope that sets out what's included, what isn't and the milestones
- A record of every patch, showing whether it was kept, updated or removed, and why
Where we've done this
For a state emergency services agency, working through a global digital agency, we upgraded the public website from Drupal 10 to Drupal 11, along with the PHP version underneath it. We costed an in-place upgrade against a rebuild, and the upgrade came in at under half the effort, so that's the route they chose. The plan paused new features and left editors free to publish, and the site moved onto Vortex in the same project.
We're also moving a Melbourne community radio station's website from Drupal 7 to Drupal 11, through a digital agency. The migration brings across more than 300 programs and their history, with redirects so the links listeners already have keep working.
On a university-run public e-mental-health service, again through a digital agency, the questions in our audit turned up features that were no longer in use. Taking them out made the upgrade smaller before any code changed.
What it costs
Every upgrade is different, so we price each one on its own. The site audit is the first part of the upgrade, and it's included in the estimate we send you before any work starts.
Once the audit shows what's involved, we can give you a fixed-price quote for the rest of the upgrade, and a fixed-price quote is the price. Nothing starts until you've approved the scope and cost.
Upgrades suit AI-assisted delivery, because compatibility fixes and code cleanup make up so much of the work. If you choose it, you pay up to 30% less on suitable work, and every change is reviewed and tested to the same standard.
Where an upgrade leads
Once your site is current, a support plan keeps it that way with monthly updates, and managed hosting means we look after the hosting as well as the website. Automated testing builds on the tests from the upgrade to cover more of your site. If your content is coming to Drupal from another system, that's a migration, which we handle as well.
FAQs
Should we wait for Drupal 12?
Usually not. Drupal 12 only upgrades from a recent Drupal 11 release, so a Drupal 10 site goes through Drupal 11 either way. Drupal 10 reaches end of life on 9 December 2026, the same week Drupal 12 is due, and Drupal 11 keeps getting new releases alongside it.
Can we upgrade a single module, or just part of the site?
Yes. We check what else the change touches first, because updating a module often means updating the ones that depend on it.
Can our editors keep working during the upgrade?
Yes. We work on a separate copy of your site, so your editors keep publishing on the live one. A Drupal 7 migration needs a short pause in editing near launch, while the final content comes across, at a time we agree with you.
Do the patches have to stay forever?
Not always. A patch fixes a problem until the fix reaches an official release. During an upgrade, we check every patch, remove the ones that are no longer needed and keep a record of the rest.
Can you upgrade a site someone else built?
Yes. The site audit is where we learn how your site fits together, whoever built it, and nothing starts until you've seen what we found.
How long does an upgrade take?
It depends on the version you're moving from and on what your site does. The site audit includes a timeline, and we agree the dates with you before work starts.
How does AI fit into an upgrade?
If you choose AI-assisted delivery, AI speeds up the repetitive work, such as making the same change across many files or drafting tests. Every change it produces is reviewed and has to pass the same automated tests, and our Responsible AI policy sets out how we handle your code and data.
Can you keep our site up to date afterwards?
Yes. Our support plans include monthly maintenance that keeps Drupal core and your modules up to date, with a report each month. They run on a prepaid block of hours, starting at 50 hours, to use within 12 months.
