Three Clocks, One Website
A website decision feels like one moment: a pitch, a platform, a signature. In practice it starts four timelines at once, and they finish years apart.
The slowest is the site itself. Sites outlast their plans. Across the estates our agencies support, some sites still run on platform versions their vendors stopped patching years ago.
Those sites are not broken. They work, they are paid for, and nobody has yet signed off the budget to move them.
Against that slow clock run three faster ones.
Clock One: The Buyer
The person who chooses the platform is rarely there when it is retired. Spencer Stuart puts average CMO tenure at the largest US companies at 4.1 years, and 3.5 years in consumer businesses.
There is no equivalent figure for UK mid-market marketing directors. Few would expect it to be longer.
So the person who signs is often gone before the second major upgrade. Their successor inherits a platform they did not choose and an agency they did not hire. A common first instinct is to start again.
Clock Two: The Agency Team
The agency clock runs faster still. The IPA's 2025 Agency Census put staff turnover in creative and other non-media agencies at 27.6% for the year to September 2025.
At a steady rate like that, about half the team that built your site would have left within two years.
The agency may keep your account. The people who knew why the content model looks the way it does will not. Knowledge that lived in a developer's head leaves with the developer.
Clock Three: The Platform
The vendor keeps its own time and does not consult you. Whatever you build on, a content platform, a commerce engine, a framework or a cloud service, someone else decides when your version stops being supported.
Long-term support releases of the most widely used web platforms and frameworks typically get two and a half to three years of fixes before they are retired.
Software as a service does not stop the clock; it hides it. The APIs your site depends on are versioned and retired, some about a year after release, and features and prices change on the vendor's timetable.
Each upgrade is a small project with a cost and a sign-off. Skip two and the small projects become one large one. That is how working sites end up on unsupported versions: not by decision, but by a run of reasonable deferrals.
The Mismatch
Set the clocks side by side and the problem is plain. The decision is made by people on two of the clocks, about software on the third, for a site that outlives all of them.
The people who choose a platform are rarely the people who live with it.
That mismatch explains much of what goes wrong later. Documentation nobody wrote, because everyone who needed it was in the room. Content models shaped around one director's campaign plan. Upgrade budgets nobody owns, because the person who would have owned them has left.
Choosing for the Inheritors
Nobody could slow the clocks. What you could do is make the decision for the people who will inherit it. Five questions help.
Who could take this over if our agency could not?
Count the UK teams who work on the platform. Three credible partners is a different risk from thirty.
What will the next two upgrades cost, and who budgets for them?
Ask for the upgrade path in days before you sign. Leave a line for it in the budget your successor inherits.
Where does the knowledge live?
Make architecture notes, a content model diagram and a runbook deliverables, not extras. What is not written down leaves with whoever knows it.
Would a new marketing director want to change it?
Shape the content model around how the organisation publishes, not around this year's campaigns.
Whose name is on everything?
Domains, hosting, repositories and licences should sit with you, so the site survives a change of agency as well as a change of people.
The Short Version
A website is a long-lived asset chosen by short-lived owners. Choose it, write it down and contract for it as if you will not be there for the next upgrade. On the numbers, you might not be.