Drupal Development & Migration
Drupal 6 through 11: architecture, custom modules, version migrations and the long tail of keeping it healthy.
More on Drupal Development & MigrationA content platform is not finished at launch; that is when it starts costing money. Most of my CMS work is with organisations two, five or ten years past go-live — inheriting a build whose original team has moved on, facing an end-of-life version, or running a site that has quietly become slow, insecure and frightening to deploy.
Drupal 6 through 11: architecture, custom modules, version migrations and the long tail of keeping it healthy.
More on Drupal Development & MigrationCustom themes and plugins, performance work, security hardening and rescuing sites that have been let go.
More on WordPress DevelopmentCheckout, payments, tax, B2B pricing and the database work that keeps a large catalogue fast.
More on WooCommerce & E-commerceDrupal or WordPress as a content API behind React front ends — when it is worth it, and when it is not.
More on Headless & ComposableFourteen years across Drupal 6 to 11 and a similar span of WordPress means I have seen most of the ways these platforms go wrong — and, more usefully, which of those are worth fixing and which are worth living with. Not every piece of technical debt deserves a rewrite.
Almost every expensive CMS problem traces back to a content model that did not match how the organisation actually works. Fields bolted on over years, a taxonomy nobody maintains, identical content types created because editing the existing one felt risky.
Getting this right early is cheap; changing it later means data migration, redirect maps and retraining editors. I spend a disproportionate amount of discovery on it, and I would rather push back on a structure now than migrate it in three years.
A platform that is technically excellent and miserable to publish on will be worked around until the content model stops meaning anything. Preview that works, sensible defaults, validation that explains itself, media handling that does not require a support ticket — these determine whether the investment holds its value.
The organisations facing painful, expensive migrations are the ones that treated upgrades as projects rather than routine maintenance. Drupal 6 and 7 sites that skipped a decade of updates are dramatically harder to move than sites that stayed current.
Where I inherit that situation I will do the migration; where I am building or maintaining, I set up the dependency management, automated tests and deployment pipeline that keep it from recurring. See DevOps & CI/CD for how that side is handled.
Both platforms have solid security teams and both are heavily targeted, largely through out-of-date contributed code. Staying patched matters more than any single hardening measure. Performance follows a similar pattern: a fast launch degrades as content grows and modules accumulate, so caching strategy and query behaviour need revisiting rather than solving once.
Increasingly this work overlaps with AI & Automation: content summarisation and metadata generation inside the editorial workflow, semantic search over a large archive, or a knowledge assistant grounded in the CMS content you already maintain. Built as a proper module or plugin, that respects your existing permissions and caching rather than working around them.
Describe the problem in your own words — I will tell you what I would actually build, and what I would not.
Start a conversation