Cracks in the CMS: A Finance-Friendly Case for Upgrading Without a 40-Page Deck
Photo: Foreign, Commonwealth & Development Office, CC BY 2.0, via Wikimedia Commons
Most CMS upgrade proposals sink under their own weight. Twenty slides, a feature matrix, a vendor demo recording and a glossary nobody asked for. A finance director in a UK organisation — whether you run a charity, a housing association or a mid-sized business — will not read it. They will skim page one, look for the number and ask what happens if you do nothing.
That is why the two-page business case works. It is not less rigorous. It is more disciplined. It forces you to explain the problem in operational language: time, risk, compliance and publishing speed. Here is how to build one.
Page one: the cost of staying put
Start with the current CMS, not the shiny replacement. Finance needs to see the status quo as a cost centre, not a neutral backdrop.
Cover four things, in this order:
- Staff time. Estimate the hours your team spends on workarounds: re-entering content, fixing broken layouts, chasing approvals, building pages by hand. Use a conservative range and say how you arrived at it. For example: 'Three editors spend roughly two days a month rebuilding landing pages that the template cannot handle.' That is a number a budget holder can test.
- Publishing speed. If a routine news update takes two days because of workflow friction, say so. Compare it with what the organisation expects. Slow publishing has a cost in missed campaigns, late consultations and stale information.
- Risk. Keep this plain. Old CMS versions, unsupported plugins, unclear backup routines and patchy permissions are risk items. So are accessibility gaps and data protection questions. You do not need to exaggerate. A short risk register with likelihood, impact and current mitigation is enough.
- Compliance. For UK organisations, accessibility and data protection are not abstract. If your CMS makes it hard to publish accessible documents or manage consent, that belongs on page one. So does any difficulty producing an audit trail of who changed what.
A useful rule: if a sentence would fit in a vendor brochure, cut it. 'Intuitive content modelling' is not a finance phrase. 'Editors currently need developer help to publish a campaign page' is.
Page two: options, cost and the ask
Page two is where you recommend a course of action. Keep it to three options at most: stay put, patch and improve, or replace. Give each a rough cost and a rough consequence. Finance does not need a full tender; they need to see that you have considered the alternatives.
Use a simple table like this:
| Section | What to include | Example evidence |
|---|---|---|
| Problem | One paragraph on the operational bottleneck | Two-day publishing delay for campaign pages |
| Cost of doing nothing | Staff hours, agency spend, risk exposure | Estimated 18 editor days a year on workarounds |
| Options | Stay, patch, replace | Patch extends life by 12 months but adds support cost |
| Recommendation | One clear option and why | Replace now to avoid a rushed migration later |
| Ask | Budget, timescale, decision date | £X over two years, decision by end of Q1 |
Then add a short 'what good looks like' paragraph. Not features. Outcomes. Editors publish a standard page without developer help. Accessibility checks happen inside the CMS. The team can produce a content audit without exporting spreadsheets. Permissions are clear enough that leavers lose access on day one.
Frame benefits as operational wins
Finance teams are trained to spot vague benefits. 'Improved user experience' will not survive scrutiny. 'Reduces developer involvement in routine publishing by roughly 30%' might, if you can point to the tasks involved.
Try these translations:
- Technical debt becomes 'work that keeps the team from planned projects'.
- Better integrations becomes 'fewer manual exports and re-keying errors'.
- Workflow improvements becomes 'faster approvals and a clearer audit trail'.
- Accessibility controls becomes 'lower risk of non-compliance and fewer retroactive fixes'.
Do not promise savings you cannot defend. If the main benefit is avoided risk, say that. A finance director will respect 'this reduces the chance of an unsupported platform failure during a busy period' more than a made-up efficiency percentage.
Keep the ask specific
End page two with a decision, not a discussion. State the budget range, the timescale and the next step. If you need discovery work first, ask for that instead of the full programme. Small, fundable steps are easier to approve than a five-year transformation.
The two-page case is not a trick. It is a test of whether you can explain the upgrade in the language of the organisation. If you cannot fit the argument on two pages, the problem is usually not the page limit. It is that the case has not been thought through yet.
