Self-hosting a content management system looks like the cheap option, and for a small team with a competent developer it often is. The licence is free or nearly free, the server costs are predictable, and nobody has to negotiate with a vendor. It is a defensible choice.
It stops being defensible at a fairly specific point: when the number of people depending on the system exceeds the number of people who understand it. After that, the costs that were invisible on the business case start arriving, and they do not arrive as line items. They arrive as an urgent patch on a Friday night, a migration that takes two quarters, and a recruitment problem nobody anticipated.
It is worth being concrete about what those costs are, because they are the actual argument for a cloud hosted cms — not the marketing argument about elasticity and modern architecture, which is true and which nobody has ever been persuaded by.
Cost one: security is now your operations problem
An open-source CMS is a public target. The core may be well maintained; the extensions usually are not. In 2025 the WordPress ecosystem saw 11,334 new vulnerabilities disclosed, up 42% year on year — roughly twenty-two per day — and in the preceding year 96% of them came from plugins and themes rather than core. Median time from public disclosure to mass exploitation has been measured in hours, not days.
Other ecosystems are smaller but not exempt. Strapi had five CVEs disclosed in a single month in late 2025. Drupal issued a highly critical SQL injection advisory in May 2026 that was actively exploited across thousands of sites in dozens of countries within days.
None of this means open-source software is insecure in principle. It means that when you self-host, patching is your job, on the attacker's timetable rather than yours. A software-as-a-service platform moves that obligation to the vendor, along with the obligation to prove they are meeting it. That proof is the reason certification matters in procurement: ISO/IEC 27001 held by the vendor in its own right rather than inherited from a cloud provider, SOC 2 Type II, HIPAA where health data is involved, and alignment with DORA and NIS 2 where financial and critical-infrastructure rules apply.
Cost two: version transitions are rebuilds
The seductive thing about a self-hosted platform is that you can customise anything. The expensive thing is that you then have to carry those customisations across every major version.
Drupal 7 reached end of life in January 2025 with a substantial share of its installed base still on it, because moving forward meant rewriting custom modules, content types, and themes rather than running an upgrade. Commercial platforms have the same pattern in a different wrapper: one major vendor's migration path lists more than twenty features that simply do not carry over, with implementations commonly running six to twelve months.
A cloud platform updates underneath you. That is a real loss of control and a real gain in cost predictability, and which one matters more depends entirely on how much custom code sits between you and the vendor.
Cost three: the talent market
This is the one that surprises people. A 2025 survey of Drupal developers across 58 countries found only eleven developers globally with less than a year of experience. The specialists that remain command $120–$200 an hour. Platforms built on a single proprietary stack have the same problem in a milder form — if your CMS requires .NET specialists, your hiring pool is .NET specialists, at .NET specialist rates.
Cloud, API-first platforms invert this. The skills needed are the skills your front-end team already has, because the front end is built in whatever framework they chose. The CMS itself does not require a dedicated specialist to keep running, because keeping it running is not your job.
What "cloud" should actually mean
Not every hosted product delivers the benefits above, so it is worth defining the standard. A genuine cloud-native content platform should be:
Multi-tenant SaaS, not managed hosting. If the vendor is running a copy of a self-hosted product on your behalf, you have outsourced the servers and kept the upgrade problem.
API-first by design. Content delivered over REST and GraphQL to any consumer, rather than a rendering engine with an API bolted onto the side.
Free of metered surprises. Per-API-call pricing turns a successful campaign into an invoice. Ask what a tenfold traffic increase costs before you sign.
Governed as standard. Role-based access control, multi-step approval workflows, and environment-level permissions should be how the platform works, not an enterprise upsell.
Accessible. WCAG 2.2 AA is increasingly a procurement requirement rather than a nice-to-have, and very few platforms in this category meet it.
Structured. Content stored as typed, channel-agnostic data rather than as HTML blocks, so it can be reused wherever it is needed. A Kontent.ai headless CMS primer is a decent explanation of why that distinction ends up mattering more than any other item on this list: it is the difference between content you can deliver anywhere and content that only makes sense on the page it was written for.
The comparison that actually decides it
Build the five-year number, not the first-year number. For self-hosting, include the developer time spent on patching and upgrades, the cost of at least one major version rebuild, the specialist rates in your market, and the expected cost of one security incident weighted by likelihood. For a SaaS platform, include the subscription, the implementation, and the front-end build — then check for metering.
The published figures for enterprise alternatives are sobering in both directions. WordPress VIP starts at $25,000 a year for hosting alone, with three-year total cost of ownership commonly exceeding $600,000 once agency retainers and plugin licensing are counted. Traditional enterprise DXP platforms run $200,000 to $500,000 a year before implementation, with five-year totals above $800,000 and a rebuild waiting at the end.
Against those numbers, the "free" option and the "expensive" option are closer together than the labels suggest. The decision comes down to something simpler: whether running content infrastructure is a capability your organisation wants to own, or a distraction from the work that actually differentiates you.
Most organisations, asked plainly, answer the second. The business case just takes a while to catch up with the answer.