Platforms that outlive the project that built them

A 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.

How I approach CMS work

Fourteen 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.

Content modelling is the decision that lasts

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.

Editors are users too

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.

Upgrades are a habit, not an event

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.

Security and performance are ongoing

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.

Where AI fits

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.

Have a project in mind?

Describe the problem in your own words — I will tell you what I would actually build, and what I would not.

Start a conversation