Seven Things to Test After the CMS Demo (Before You Sign Anything)

Demo day is a bit like an estate agent viewing. The lights are on, the coffee is fresh, and nobody mentions the damp patch behind the sofa. CMS vendors are not villains for doing this — they are showing their best day. Your job is to test the ordinary Tuesday afternoon, when a council comms officer needs to publish a road closure notice and the payment provider has gone wobbly.

Here are seven questions UK web teams should ask after the demo, before anyone gets attached to a shiny interface. They are not designed to catch vendors out. They are designed to catch the details that decide whether the system works six months after launch.

1. Can an editor publish a real page without a secret decoder ring?

Ask for a live editing task using your own content. Not a polished case study, but the messy page with a table, a PDF, an image with alt text, a call to action and a redirect. Watch how many clicks it takes, whether preview looks like the live site, and whether the editor can schedule the page for 7am on a Monday. If the vendor needs a developer on the call to make it look easy, that is a clue about your future workload.

2. Put accessibility on the demo screen

Accessibility is not a nice-to-have in the UK. Public sector bodies have legal duties under the Public Sector Bodies Accessibility Regulations, and every organisation should be aiming at WCAG 2.2 AA. Ask the vendor to show you how the CMS helps editors write good alt text, avoid skipped heading levels, and check link text. Then ask what the CMS itself does — or does not do — to meet those standards. A demo that only shows pretty templates is not enough.

3. Follow the data: UK GDPR, hosting and subprocessors

Where is the content stored? Which subprocessors touch it? How does the vendor handle data subject requests, backups and deletion? If the CMS uses AI features, what happens to your content when someone clicks generate? UK web teams need clear answers, not a link to a trust centre that was last updated in the mists of time. Bring your DPO or privacy lead into the conversation early. It is much easier to rule out a poor fit now than to unpick it after procurement.

4. Test the boring environments

Ask about staging, preview, rollback and deployment permissions. How does a change move from draft to live? Can you schedule a content freeze over Christmas without locking out the whole team? What happens if an editor deletes a page by mistake — is there a recycle bin, a version history, or a support ticket and a prayer? These are not glamorous questions. They are the ones that keep a web team sane during a busy bank holiday weekend.

5. Price the integrations, not just the licence

A CMS rarely lives alone. It might need single sign-on, a CRM, a payment provider, analytics, a search service or a translation tool. Ask what is included, what is an add-on, and what needs custom work. Then ask who maintains the integration when the third party changes its API. The licence number may look reasonable until you add the implementation days, the connector fee and the annual support uplift.

6. Read the support SLA like a cynic

What counts as a priority one incident? Who answers the phone at 8am on a Saturday? Is support UK-based, follow-the-sun, or a chatbot with a friendly avatar? Ask for real response times, not marketing promises. If your organisation runs essential public services, a 48-hour response window for a broken form is not a support plan — it is a hostage situation.

7. Ask how you leave

This is the question nobody wants to ask on demo day: if we move on in three years, how do we get our content, media and metadata out? Is there an export tool, an API, or a professional services invoice? A good vendor should not be offended. A good vendor should have a clear answer. Exit plans are part of a healthy relationship, not a lack of commitment.

The detox test

After the demo, write down one sentence for each question: what you saw, what you were promised, and what you need to verify. Then ask the vendor for evidence — a sandbox, a sample export, an SLA, a subprocessor list. If the answers are vague, that is not a reason to panic. It is a reason to slow down. The best CMS for your team is not the one with the slickest demo. It is the one that still makes sense when the coffee has gone cold.