Most CMS decisions are made by comparing feature lists, and most CMS regret is about workflow. That gap is the whole problem: every mature platform lists roughly the same capabilities, so the comparison cannot distinguish them on the thing that will actually matter.
The decision is better made by describing what you publish and who publishes it, then eliminating systems that cannot express that.
Question 0 — do you need one?
Worth asking honestly, because the answer is sometimes no.
A CMS solves one problem: people who should be publishing are waiting on someone else to do it. If a single technical person publishes everything and is not a bottleneck, a CMS adds a system to maintain, secure, back up and upgrade — in exchange for solving a problem you do not have.
The trigger is a non-technical publisher, not a content volume. A site with two hundred pages maintained by one developer may need no CMS. A site with twelve pages that marketing needs to update weekly probably does.
If the honest answer is "not yet", the useful move is to defer and revisit when the publisher exists — not to build in anticipation of one.
The six questions that decide it
1. What is your content actually shaped like?
Not "we have pages". Describe the types, their fields, and how they relate.
A site with one content type and a handful of fields fits almost anything. A site with interlinked types — articles referencing authors, referencing topics, referencing services — needs a system that models relationships properly, and this is where platforms genuinely differ.
Write the model down before looking at any platform. The shortlist narrows itself, and the exercise frequently reveals that the model is unclear, which is a more important finding than the platform choice.
2. Who publishes, and what can they do?
The single most predictive question, and the most often skipped.
| Publisher | Implication |
|---|---|
| One technical person | Git-based workflows are viable and cheapest |
| Marketing, non-technical | Needs a genuine editing interface with preview |
| Several people, varying skill | Needs roles, permissions and a review gate |
| External contributors | Needs sandboxing and approval before anything goes live |
A system chosen for capability but too complex for its actual users gets worked around — and content ends up in documents, emails and someone's drafts folder.
3. What is the workflow?
Draft, review, publish is the minimum most teams need. Scheduling, roles and approval chains cost real complexity.
Be honest about what you will actually use. An approval chain nobody follows is worse than none, because it creates a bypass habit that then applies to the rules that matter.
4. What are your hosting and data constraints?
This eliminates more options than any feature comparison.
- What database does your hosting provide?
- Can you run a persistent process, or only static files?
- Must data stay in your own infrastructure?
- Who patches and backs it up?
These are hard constraints and they are decisive. A platform requiring a database your hosting does not offer is not a candidate, however good it is — and discovering that after selection is an expensive way to learn it.
5. What happens when you outgrow it?
Ask two things: can you get your content out in a usable format, and are the URLs yours?
Content portability is a real differentiator. A system whose content cannot be extracted in full, on demand, in a format that survives the vendor is a system you cannot leave.
6. What does it cost over three years?
The licence is usually the smallest line. Implementation, migration, training, hosting, maintenance and the upgrade that breaks a plugin are the rest.
A free platform with a fragile plugin stack and monthly firefighting can cost more than a paid one that needs no attention. Compare total cost, and include the hours.
Because questions 1 to 3 determine which platforms are even viable, we run them as the first phase of
modelling content and workflow before the platform decision.On building your own
Sometimes proposed, rarely correct.
A CMS needs authentication, sessions, permissions, a rich editor, revisions, media processing, scheduling and an audit log. None of that is specific to your business. It is commodity infrastructure mature systems have already solved, and building it means months on problems whose solution creates no advantage.
The genuinely Vedixx-specific parts of a content system — the content model, the validation rules, the quality gates — are a small fraction of the work, and can usually be expressed as configuration on top of something existing.
The legitimate exception is when constraints rule out the alternatives: hosting that provides only a particular database, data that cannot leave your infrastructure, or a content model nothing off-the-shelf can express. Then a build is a consequence of the constraint rather than a preference — and it should be scoped with the commodity parts recognised as commodity.
Migration: where the risk actually is
Not the platform. URLs and content.
- Every existing URL either survives or redirects to its closest equivalent. A redirect to the homepage discards most of what it could have preserved
- Content that ranks is preserved, not trimmed. Length is frequently the reason a page performs
- Verify after launch, not when someone notices traffic fell — the effects take weeks to become visible
The same discipline applies whether you are moving between traditional systems, going headless, or rebuilding entirely. The website redesign checklist covers the URL and content work in full; it applies to a CMS migration essentially unchanged.
The decision, compressed
- Does a non-technical person need to publish? No → you may not need a CMS
- Write down the content model. Types, fields, relationships
- Describe the workflow you will actually use, not the one that sounds thorough
- Eliminate on hosting and data constraints. These are hard
- Shortlist on content shape and operability, not on feature count
- Test with a real publishing run before sign-off
Step 6 is the one that catches mistakes while they are still cheap. Have someone from the team publish something real, unaided. Whatever they get stuck on is what configuration or training still has to address — and it is far better found the week before launch than the month after.
Want this handled properly?
You now know what the work involves. If you would rather not do it yourself, that is what we do.