What I’ve Learned From 19 Years of Business-Critical CMS Work

I started working with ExpressionEngine in 2007, at a point when it was one of the few platforms capable of handling genuinely complex content requirements. Craft CMS came along later and I picked that up in 2013. The work across both has been consistent: membership sites, booking systems, trade portals, internal tools built on a CMS a business actually relies on.

After 19 years across both platforms, the symptoms clients describe are familiar before the diagnosis is made. The site feels slower than it should. A feature stopped working at some point and nobody is sure when. A report has been producing results that look slightly wrong and nobody has been checking. Behind most of those descriptions are the same problems: maintenance that was never caught up on, a period between agencies where the site was left alone, and issues that had been getting worse without anyone realising.

What “business-critical” means

After launch, most CMS sites get handed to whoever will maintain them, and maintenance tends to mean reacting when something goes wrong. For a brochure site, that is fine.

On the other hand, a site that handles live orders, member logins, booking requests, or staff workflows needs more than that. When the site goes down, orders stop. When the CMS has not been upgraded in four years, known vulnerabilities go unpatched and third-party plugins start breaking against newer server environments.

I use the term “business-critical” because it describes the type of problem I am hired to solve. That means keeping the platform on a supported version, ensuring the software the site runs on stays compatible with the server, patching known security vulnerabilities, and making sure that routine updates do not cause problems elsewhere. A client will rarely notice when that work is being done. When it stops, the problems follow quickly.

The patterns that repeat

The first is deferred maintenance. Most ExpressionEngine and Craft CMS sites I inherit have missed several rounds of updates, and the reason is usually risk aversion. If it works, don’t touch it. If it half-works and nobody has complained, the logic tends to hold too. The result is a site whose software has not kept pace with the server it runs on. When the hosting environment eventually forces a change, what looked like a routine update often turns into a much larger piece of work.

The second is the handover gap. When an agency relationship ends, the period between agencies is where problems accumulate.

• Security updates get skipped. The ones that were due while nobody was watching.
• Plugins hit compatibility issues and there is nobody to fix them.
• Support emails go unanswered. Sometimes for weeks.

Six months later the client finds a new agency, who inherits a site that has not been touched in months.

The third is invisible degradation, where things go slightly wrong in ways that do not produce error messages and are not reported by any monitoring tool.

• A form that stopped sending emails two months ago.
• A search result silently returning nothing.
• A report exporting incorrect data because a field was renamed and nobody updated the query.

These problems tend to surface through a customer complaint, not a developer alert, and the customer is usually apologetic about mentioning it.

What long-term relationships teach you

I have worked with some of my clients for five years or more. After working on the same site for that long, you accumulate knowledge about how it actually behaves that no handover document covers.

For example, one client’s booking system had a bug that only appeared when two customers submitted at the same time. I found it, fixed it, and it is now documented. Another had a plugin that could not be updated without testing it on a copy of the site first. The developer before me updated it directly on the live site. It took most of the evening to put right.

What clients need

The sites I work on are rarely failing in obvious ways when I first see them. They are usually working, but working in a way that has become increasingly fragile, with a CMS version two or three major releases behind, server software approaching the point where it no longer receives security updates, and an integration with an external service that the third party has announced they are retiring.

Clients in that situation need to understand what they have.

• Platform version: how far it sits from the current release
• Server software: whether the technology running the site is on a current, supported version
• Known security issues: outstanding patches and flagged vulnerabilities
• Integrations at risk: particularly anything connected to an external service that may change or retire

With that picture in place, the work can be planned and prioritised rather than done reactively. That conversation usually takes a couple of hours. It is better to have it before something breaks.

What I’ve learned

Nineteen years across both platforms has taught me four things consistently.

• Reactive maintenance is not enough. A site a business depends on needs regular attention, not just fixes when something breaks.
• The worst problems are rarely dramatic. Deferred updates, agency gaps, and slow degradation that nobody spotted cause more damage than sudden failures.
• Long-term relationships are worth more than handover documents. After years on the same site, you know things no brief can transfer.
• Understanding the current state is the most valuable first step. It is better to know what you have before something forces the issue.

The client

The clients I work with run businesses that depend on a website. They want honest answers about what state the site is in, a direct line when something goes wrong, and the work done without drama. I have worked with clients like that for 19 years.

If you want to understand the current state of your site, or need specialist support, get in touch.