Are CMS suites coming back?
For most of the last decade the CMS market moved in one direction: headless, composable, best-of-breed. Breaking systems apart gave us cleaner architectures and content that could finally live beyond a single website. It also gave us stacks that take a whole team to hold together. Every product in the stack is another integration to build, another contract to manage, and another dependency to maintain for years, and many teams are feeling that weight now.
The market has noticed. Dan Drapeau, writing about DXP selection this year, calls it convergence: suite vendors have become more modular, headless platforms have expanded their native capabilities, and both sides are growing toward the middle. And on top of that, AI is changing how software gets built, and with it the math behind many of these decisions.
So this is a good moment to ask where separation still pays off, and where it has just become a habit.
Most of the industry discusses this as a purchasing question, composable versus suite. I think that framing is the problem. It describes how software is packaged and sold, and says nothing about what a team has to integrate, extend and keep running for the next five years. That second question is the one we live with every day, and it is worth asking whether separating concerns really requires separating every capability into another product.
Decoupling was the right move
The most important improvement in modern content management was separating content from its presentation. Content gets modelled as structured data, and how it is rendered comes second. Take a product with a name, description, specifications and images. The website renders it into HTML. A mobile app consumes the same information as JSON through an API. A screen in a store shows the name, the image and three specifications. The content is the same. What changes is where it is used.
Headless CMSs pushed this idea further by removing the presentation layer completely, and for some projects that is exactly right. But the principle that matters is decoupling. Headless is just one way to get it. There is nothing wrong with a CMS rendering HTML for a website, as long as the content does not depend on that output and stays available through an API to whoever else needs it.
Did we take separation too far?
While the architectures were getting cleaner, we also started separating products. Content management from one vendor, search from another, digital assets from a third. Sometimes that is exactly right. The problem starts when composition becomes the default answer.
Every product creates a boundary. Another API, another authentication mechanism, another permission model, another dependency someone has to maintain. The editor sees five useful tools. The development team sees five systems that somehow have to behave like one platform. Vercel described the mechanism recently better than I could: the industry sells the decoupling and skips the operational cost of running what you just built.
None of this makes composable architectures bad. It means another system boundary has to earn its place. Separation of concerns does not require separation of vendors.
AI is changing the build-versus-buy math
For years the reasonable move was to reach for another product whenever a new requirement showed up, because building it yourself was expensive. That calculation is moving. Retool's latest build-vs-buy report found 35% of enterprises have already replaced a SaaS product with something they built, and the direction matches what we see in our own projects.
Coding assistants help most when they have something to work with, like a known framework with a predictable architecture and clear extension points. A developer describes a requirement and implements it inside the existing application instead of starting another integration project. Open source helps in a way that is easy to miss. The assistant can read the framework itself, not just its documentation.
That does not mean anyone should rebuild a search engine or a DAM. But the space between integrating a major external product and writing everything from scratch is getting bigger. Anything specific to your business is usually better built close to the application that already understands your business. That is how we think about Sulu: Symfony underneath, a CMS on top, and clear places to put your own code. Sulu.ai follows the same logic with AI built into the platform instead of bolted on as another system to integrate.
Decouple capabilities, not vendors
You could object that I help run a company that makes a broad platform, so of course I think broad platforms are underrated. Fair enough. But what I am arguing for is not a bigger box from one vendor. It is discipline about boundaries.
A clean architecture keeps your content structured and your own code out of the platform's internals, so what you build stays yours. A modular setup lets you replace a single capability when it stops serving you instead of ripping out everything at once. And every additional integration has to earn its place. If a specialized product brings something your platform cannot reasonably provide, integrate it. If it mostly duplicates what you already run, it adds a boundary without adding value.
The lessons of the last decade still hold. Content stays structured, APIs stay first-class, and components keep clear responsibilities. What changed is the assumption that those principles need a collection of separate products. They don't.
So, are CMS suites coming back? The old all-in-one suite is not. But integrated platforms, where the pieces are built to work together, are. And this time we can have that without giving up decoupling.
If you have consolidated a stack recently, or looked at it and decided not to, write to me on LinkedIn or find us on GitHub.
