Most businesses running on a legacy CMS (Content Management System) – TYPO3, older WordPress setups, or something bespoke from 2014 – aren’t paying attention to what it’s actually costing them. Not the licence fee. Not the hosting bill. The real cost: the hours burned on maintenance, the developer dependency for every small change, the integrations that don’t quite work, and the features you quietly gave up on because the system couldn’t handle them.
This isn’t a theoretical problem. It’s one we see repeatedly, every time a client comes to us frustrated that a “simple update” took three weeks.
The question worth asking isn’t “is our CMS good enough?” It’s “what is staying on it actually costing us – and what are we missing out on?”
What made legacy CMS platforms the standard (and why that no longer holds)
Systems like TYPO3 became the backbone of corporate websites in the DACH region for understandable reasons. They offered granular permissions, structured content trees, and editorial workflows that large organisations actually needed. When your website was essentially a static publishing tool for a single domain, a monolithic PHP-based CMS made perfect sense.
The problem is that the web changed, and these platforms didn’t change at the same pace.
Legacy CMS architecture bundles everything together: backend logic, frontend rendering, templates, plugins, and the database; all tightly coupled. That worked when “delivering content” meant publishing a webpage. It doesn’t work nearly as well when you need to deliver content to a mobile app, a customer portal, an IoT interface, or an AI assistant.
The biggest cost of a legacy CMS isn’t the licence – it’s the opportunity cost.
Every time your team has to wait for a developer to make a content change, every time an integration breaks after an update, every time you can’t connect a new tool because the API doesn’t exist or isn’t documented – that’s compounding cost. Quietly, month after month.
We covered the full breakdown of these hidden expenses in our article on the hidden costs of staying on legacy CMS platforms, but the short version: most organisations dramatically underestimate what staying put actually costs over three to five years.
The architectural shift: from monolith to API-first
Modern CMS platforms aren't just better software – they're a fundamentally different philosophy about where content lives and how it moves.
The defining difference between a legacy system and a modern SaaS (Software as a Service) or headless CMS comes down to architecture. Legacy platforms are monolithic: everything is coupled together, and the frontend rendering is baked into the same system as your content management.
Modern platforms – whether fully managed SaaS like Contentful, or open-source headless options like Payload CMS – treat content as structured data delivered via APIs. The frontend is decoupled. A product price updated in the CMS can instantly reflect on your website, your mobile app, your B2B customer portal, and your internal dashboard – from a single source of truth.
For businesses, this means:
- Content teams can publish and update without filing developer tickets
- Development teams can work on the frontend independently without touching core content logic
- Integrations with ERPs, CRMs, and marketing tools happen cleanly through APIs, not fragile custom code
- New channels (an app, a partner portal, a new market) can be added without rebuilding the CMS
This is where platforms like Payload CMS stand out specifically. Built on TypeScript and React, with REST and GraphQL out of the box, Payload is both a headless CMS and a genuine application framework. It’s not trying to retrofit API capabilities onto a page-publishing tool – it was designed for this from the start. That’s also why we chose Payload CMS as our default for new web projects.
Where Shopify fits this conversation
Shopify represents the SaaS end of this spectrum for e-commerce. It’s worth including here because it illustrates the same underlying shift – from “we own and maintain the infrastructure” to “we configure a platform that someone else keeps running.”
With Shopify Plus, infrastructure, security, and updates are handled entirely by Shopify. Teams focus on products, conversion, and customer experience. The total cost of ownership is predictable. And critically, the integration story is strong: Shopify connects cleanly to ERPs, CRMs, and PIM systems via well-documented APIs.
This is exactly the pattern that modern SaaS platforms have proven out: lower operational overhead, faster time-to-market for new features, and a team that spends its time on growth rather than maintenance.
TYPO3 vs. Payload: an honest comparison
To make the difference between an old and a new system concrete, here’s how the two approaches differ in practice across the dimensions that actually matter to decision-makers:
| TYPO3 (legacy) | Payload CMS (modern headless) | |
|---|---|---|
| Architecture | Monolithic, tightly coupled | Decoupled, API-first |
| Hosting | Self-managed or hosted, your responsibility | Self-hosted with full control, or cloud-deployable |
| Updates | Manual, risk of breaking plugins | Dependency-based, like any modern app |
| Frontend flexibility | Tied to templating system | Any framework: Next.js, React, Vue |
| Integrations | Custom development usually required | REST and GraphQL out of the box |
| Editorial experience | Functional but dated | Clean admin UI, customisable per workflow |
| Developer talent pool | Shrinking TYPO3 specialists | Broad TypeScript/React ecosystem |
The developer talent angle is underappreciated. Maintaining a TYPO3 system in 2026 means depending on a smaller, increasingly expensive pool of specialists. Payload runs on tools that the majority of modern web developers already know – which means faster hiring, faster onboarding, and more flexibility when your team changes.
When staying makes sense – and when it doesn’t
To be honest: not every legacy system needs replacing immediately. If your TYPO3 setup is stable, your editorial team is fluent in it, and you have no near-term plans to add new digital channels or integrations, the disruption of migration may not be worth the gain right now.
But that calculation changes quickly when:
- You’re spending more on maintenance than on building new things
- Integrating a CRM, ERP, or marketing tool requires months of custom development
- Your team is filing tickets for content changes that should take minutes
- You’re planning to launch a new product, market, or digital channel in the next 12–18 months
If any of those sound familiar, the question isn’t whether to move – it’s how to do it in a way that’s structured and doesn’t create unnecessary disruption. That’s exactly what we cover in our guide to CMS migration and the upgrade vs. full relaunch decision framework.
Staying on an outdated platform isn’t playing it safe – it’s just delaying a more expensive problem.
What actually changes when you make the move
When we’ve helped clients migrate from legacy CMSs to modern platforms, the operational changes are usually more significant than the technical ones. Teams that previously waited days for developer support start publishing content independently. Integrations that previously required months of custom work connect in days. And instead of spending budget on keeping the system alive, it goes toward features that actually drive business outcomes.
The shift isn’t painless – migrations require planning, proper SEO handling, and realistic timelines. But the direction of travel is clear, and the businesses that made this move two or three years ago are meaningfully ahead of those still maintaining monolithic systems from 2012.
If you’re evaluating whether your current CMS is holding your business back, or you’re ready to explore what a modern platform could look like for your organisation, our Payload CMS team is happy to take a look. We work with enterprise clients across Switzerland and the DACH region, and we’ve seen what the transition looks like from both sides.
