The Framework Isn't a Warranty: Buying a CMS on G-Cloud Without Switching Off Your Brain

There is a particular kind of relief that washes over a web manager when they discover their next CMS is already on a framework. No full OJEU-style exercise. No six-month tender that eats the entire content team's summer. Just a few searches on the Digital Marketplace, a shortlist, a call-off, and back to the actual work of running a website.

That relief is justified — up to a point. The trouble starts when people confuse procurement shortcut with quality assurance. They are not the same thing, and the gap between them is where lean web teams get bruised.

What the framework genuinely does for you

Let's give credit where it's due. Buying through something like G-Cloud, run by the Crown Commercial Service, solves a real problem for UK public sector teams — and for the suppliers who serve them.

First, it removes the compliance theatre. The supplier has already been through a selection process, has published terms, and has agreed to operate within a set of framework rules. Your procurement colleagues will still want a look, but you're not starting from a blank page.

Second, pricing is meant to be transparent. Service definitions and rate cards are published, which gives you at least a fighting chance of comparing one supplier's numbers with another's without three rounds of "can you send us an indicative quote".

Third, call-off is fast. For a district council, a housing association or an NHS trust with a small digital team and no dedicated commercial function, that speed is worth a great deal. It means you can spend your energy on the product rather than the paperwork.

And fourth — the small print is at least visible. Framework terms around things like social value and data handling give you hooks to pull on that wouldn't otherwise exist.

What it quietly doesn't promise

The framework does not tell you the CMS is any good.

That sounds obvious written down, but it gets forgotten the moment a supplier's listing page uses the phrase "G-Cloud accredited" as if it were a kitemark. It isn't. Being on the framework means the supplier met the entry criteria and agreed to the rules. It does not mean anyone tested the editor experience, checked whether the API is actually documented, or asked a real content designer to try building a landing page.

It also doesn't promise that the thing you're buying is the thing you need. Service definitions are written by suppliers, for suppliers, and they tend to be broad. A listing may mention "integration capabilities" without saying a word about your specific CRM, your payment provider or the creaking student records system that everything in your organisation orbits around.

Nor does it cover the messy middle: migration. Framework pricing typically covers the software and, sometimes, a standard implementation. Lifting five years of legacy pages, redirects, embedded PDFs and a folder structure maintained by someone who left in 2019 is almost always a separate conversation, priced separately, and scoped by people who haven't seen your content yet.

And exit? The framework will ask suppliers to describe their exit arrangements. It will not stop those arrangements from being expensive, slow, or creatively worded.

Where the money actually hides

If you're building a budget from framework prices alone, you're building it on sand. The line items that blow up a CMS project are rarely the licence fee.

• Implementation and discovery. Even a "fixed price" implementation usually assumes a fixed scope, defined before you understood your own requirements.
• Data migration. Priced per page, per asset or per hour — and always more than the estimate once the legacy site is opened up.
• Integrations. Single sign-on, CRM, search, analytics consent tooling. Each one is a small project with its own surprises.
• Support tiers. The base level in the listing often isn't the one you'll actually need. Read what response times you get and what counts as "out of hours".
• Hosting uplift. Traffic spikes, environments, backups, disaster recovery — sometimes bundled, sometimes not, occasionally bundled and then charged again.
• Exit and export. Ask now, not in year three.

None of this is sharp practice. It's just that frameworks price commodities, and a CMS rollout is not a commodity.

Questions to put to any supplier whose CMS you find on a framework

Bring this list to the first conversation. The answers tell you more than the listing ever will.

1. Which parts of our requirement does the published service definition explicitly cover, and which parts would be a change request?
2. Can you show us a live site you built that's roughly our size and sector — and can we talk to that team without you in the room?
3. What's your documented process for exporting all content, media and metadata if we leave, and how long does it take?
4. Who does the migration, to what standard, and at what point does it become a separate paid engagement?
5. What's your actual support model — UK hours, named contacts, escalation path, and what happens at 9pm on a Friday before a big campaign launch?
6. How do you handle accessibility conformance, and can you evidence it rather than describe it?
7. What does a typical year-three cost look like, once the introductory pricing has moved on?
8. Can we see the roadmap — and do you have a track record of shipping against it?

Eight questions, one meeting. If a supplier gets tetchy about any of them, that's information too.

Using the framework well

The sensible posture is this: let the framework carry the procurement weight, and spend the time you save on due diligence you'd have done anyway. Build a scoring matrix before you look at listings, so you're not seduced by a tidy service definition. Talk to reference customers off the record. Get a content person, not just a technical person, into the demos.

The framework is a decent shortcut through the formalities. It is not a substitute for judgement, and it never claimed to be — that bit was our own wishful thinking.