I am an Adobe AEM Sites Business Practitioner Expert and a Magento Certified Developer Plus. My own project runs on Payload — an open-source CMS. Those two sentences do not describe a contradiction; they describe almost exactly the question every CMS selection is really about.
My experience after fifteen years of web and CMS projects: 80 to 90 percent of efforts that need a new CMS could technically be solved without trouble by an open-source system. Yet a considerable share end up on an enterprise suite. The reasons are rarely technical — which is precisely why it is worth naming them openly.
Why most projects could run on open source — and often still do not
There are many small, good open-source CMS. Their problem is rarely the technology but the market around them: for a niche system you will hardly find agencies or freelancers who can still reliably maintain a larger project years later. So you stay with the few well-known open-source systems — or reach for the enterprise option, often simply because other products from the same vendor are already in the house.
Only one thing has shifted in my thinking over the years: I no longer consider enterprise CMS oversized across the board. They have their place — just not in every second mid-market project where they are sold.
Where enterprise genuinely wins
AEM is the right choice when further building blocks of the Adobe ecosystem are actually used too — Adobe Analytics, Real-Time CDP, AEM Assets. Anyone who truly runs that chain gets an integrated stack you would otherwise have to assemble laboriously from open-source components.
The more decisive factor, though, is rarely the ecosystem but the number of people working with the system. AEM offers functions for steering an entire content pipeline — content planned months in advance that at the same time affects many delivery channels. That is the real advantage over open source. Add compliance, hosting and SaaS operation out of the box — all things you must first create yourself with open source.
Where enterprise is oversold to the Mittelstand
An enterprise content suite quickly reaches the region of around 200,000 euros in license costs per year for larger setups. Project costs are a chapter of their own: in the order of 150,000 to 300,000 euros, just to reach the functional state of the old website again.
That would be defensible if the added value were realized afterwards. In practice the focus usually stays on the core business — product, sales, conversion — and the ambitious content plan slips. When in the end only one to five people maintain content, the actual enterprise value goes unused. Worse, the enterprise mindset rubs off on the whole project — everything is conceived bigger, heavier and more expensive than the mid-sized company would ever have needed.
Where open source bites
The other way round, open source is no free lunch either. It stands or falls with its community: if that is missing, no innovations and no security fixes arrive — and a CMS without security updates is a liability topic in the medium term, not a savings model.
The second classic is plugin sprawl. Because a large open-source CMS has an extension for almost everything, a project quickly fills up with plugins and drifts toward spaghetti architecture. And self-hosting is almost always underestimated — operations, backups, updates and scaling are real, recurring costs, not a one-off effort.
The questions I ask during selection
When a managing director asks me "which CMS for us?", I do not answer with a feature table. I ask questions — these first:
- How many people will actually work with the system?
- How often will content be updated — daily, monthly, campaign by campaign?
- Are there compliance constraints? EU or US, SaaS or mandatory self-hosting?
- Is vendor support with an SLA needed — or does an internal team carry the risk?
- How large is the license budget over a three- to five-year horizon, not just in year one?
Technically, any serious CMS can deliver pages, content and blocks and be connected to any system. The choice is not decided by features — but by how a team wants to work with it.
A lesson from practice
A project from memory, deliberately anonymized: a full-blown CMS was introduced although a markedly leaner setup would have sufficed. Many processes were still designed out of the old logic that thought tightly along the product catalog — while in fact the CMS was the leading system for the actual website. That discrepancy made coordination and feature tests sluggish.
The pattern was typical at the end of every iteration: only then did it become visible what should really have happened one iteration earlier. The CMS had introduced an extra layer of complexity the team could no longer cleanly oversee. The client carried it — there was a genuine vision behind it. But the team was too small to maintain such a complex construct, all the more with worldwide rollouts. The vision was not wrong. It just was not sustainable for the crew on hand.
The lesson is unspectacular and important for exactly that reason: the right CMS choice does not start with the system but with the team and its real way of working. That very step — the sober system selection before the first line of code — is part of my work in Technical Consulting. If a CMS decision is on your table right now, in a non-binding 30-minute call we will clarify which of the questions above already dictates your answer.