Choosing a content-management provider means choosing who will help deliver and maintain a working service. Separate the software product from implementation and ongoing support. A useful brief makes the required outcomes, responsibilities and acceptance evidence clear before suppliers propose a solution.
Identify the service you need
A software vendor supplies a product or subscription. An implementation partner configures it, migrates content or builds integrations. A support provider handles agreed operational work after launch. One organization may perform all three roles, but each responsibility still needs an owner and an escalation route.
List the skills your team already has and the gaps it needs to fill. The GOV.UK guidance on contractors and third parties emphasizes identifying skills and transferring expertise. Its procurement context is UK government; the practical question for another organization is how supplier work will leave its own team capable of continuing.
Agree who provides source facts, resolves content ownership, supplies access and approves releases. A migration can stall even with a capable supplier if nobody on the client side can decide which version is authoritative.
Turn a project idea into a bounded brief
Give suppliers representative content and the same questions. Ask them to distinguish included work, assumptions, optional work and recurring charges. Compare implementation hours, training, hosting, subscriptions, maintenance and exit effort across the same planning period. Treat unresolved assumptions as questions to answer.
Describe evidence for accepting delivery
| Deliverable | Demonstration | Evidence retained |
|---|---|---|
| Content transfer | Account for all 40 pages and 12 downloads, including approved exclusions. | Manifest, exception decisions and public checks. |
| Editorial workflow | Two client editors create, review and publish sample changes. | Observed tasks and unresolved issues. |
| Templates and form | Check agreed layouts, keyboard use and an approved test submission. | Test record and corrected defects. |
| Recovery and export | Demonstrate the agreed recovery and content-export procedures. | Files, instructions and reconciliation. |
| Handover | Client staff locate accounts, documentation and support routes. | Named owners and completed training record. |
A presentation of features is different from a demonstration against your content. Agree which defects block acceptance, who decides and how repairs are checked. Keep accessibility requirements explicit and use an evaluation appropriate to the service; W3C Easy Checks is an initial review, not a complete audit.
Ask questions that expose delivery risks
Request a relevant example of similar work and permission to speak with an appropriate reference. Ask who will actually do the work, what depends on subcontractors and how changes in personnel are handled. Evaluate the proposed approach and evidence rather than a polished generic portfolio.
Clarify account ownership, access administration, licensed components, source-file delivery and documentation. Ask which tasks your team can perform independently after handover. Discuss response and resolution expectations separately: acknowledging a request does not mean the service has been restored.
Have your procurement, security and legal owners review the terms that apply to your organization. The checklist here defines operational questions; it does not replace an organization-specific agreement or establish a supplier's compliance.
Rehearse operating the result
Before closing the project, ask a client editor to perform a change without the provider driving. Ask the operator to locate the recovery instructions and contact the agreed support route. Record what is missing and assign completion dates.
Download the supplier brief and handover checklist. It includes scope, dependencies, acceptance and ongoing ownership fields. Use the CMS software trial for product capabilities and the migration pilot for transfer validation.