Modernise · service 06 of 09

Upgrades & migrations

Keeping Drupal and Symfony applications on supported versions, and moving legacy PHP onto a modern stack, with content intact and a release plan that can be rolled back. If you're still on Drupal 7, official security support ended on 5 January 2025, so it's time to plan the move.

Drupal 10 ends on 9 December 2026, and Drupal 12 is due the same week. See the dates, requirements and upgrade path for your version.Drupal 12 guide → Symfony 6.4 bug fixes end in November 2026, and security fixes in November 2027. See the dates and the route to Symfony 7.4.Symfony guide → PHP2Shell: only PHP 8.2 to 8.5 got official fixes. What it means for applications on older PHP.Legacy PHP guide →
upgrades-and-migrations.yml
engagement: Fixed-scope project
paths: Drupal 7/10 to 11, 11 to 12, PHP 5/7 to 8.x
content: Audited and mapped before migration
go-live: Staged and reversible
Is this for you?

Sounds familiar?

  • Your site runs on a Drupal or PHP version that's out of support
  • Your host has warned that your PHP version is being retired
  • Deprecated code is blocking module updates
  • A legacy or bespoke CMS that nobody can maintain any more
  • A previous upgrade attempt stalled halfway
What's included

The work, in detail.

01

Drupal 7 to Drupal 10 and 11

Content, users, files, URLs and redirects moved with Drupal's Migrate API, and a new theme built for the modern templating system.

02

Drupal 10 to 11, and Drupal 11 to 12

Deprecated code fixed with Upgrade Status and Rector, modules leaving core replaced with their contributed versions, and hosting brought up to PHP 8.5 for Drupal 12.

03

Bespoke and legacy CMS to Drupal

Content and media pulled from the old system's database or exports, cleaned up and mapped to a new content model.

04

Symfony major version upgrades

Upgraded one major version at a time, with deprecations cleared before each step.

05

Legacy PHP 5/7 to PHP 8.x

Tests added around risky code first, then automated refactoring and static analysis to bring it up to date safely.

06

Content audits and field mapping

What to migrate, merge or leave behind, agreed before anything moves.

07

Staged, reversible go-live

Migrations run many times against fresh copies, so launch day is a rehearsed routine with a way back.

How it works

From first call to finished work.

Every engagement starts with a free 30-minute discovery call and a written proposal. Nothing starts until the scope, price and terms are agreed in writing.

  1. Upgrade assessment

    I check versions, custom code, contrib modules and content, and list everything that needs to change.

  2. Plan and quote

    A fixed-scope plan with a content map, a timeline and a rollback plan.

  3. Migrate and rehearse

    Migration scripts are built and re-run against fresh copies until the results are right.

  4. Go live and support

    A planned launch with a short content freeze, then a support period to fix anything that turns up.

Questions

Frequently asked.

Do we need a new design?

Not necessarily. From Drupal 9 the theme usually carries over with updates. From Drupal 7 the theme has to be rebuilt for Drupal's newer templating system, but it can match your current design.

Will our URLs and search rankings survive?

Old URLs are mapped to new ones and redirected, and the redirect map is checked before launch so links and bookmarks keep working.

Can we keep editing content during the project?

Yes, until a short content freeze just before go-live. Because the migration scripts can be re-run, the final run picks up the latest content.

Will you have access to personal data?

If the work means handling personal data, such as user accounts, form submissions or a copy of a live database, we sign a UK GDPR data processing agreement alongside the contract before I get access. Where I can, I work on copies with personal data removed.