When a CMS becomes a platform
Sulu has always evolved with the requirements we see in real projects, and sometimes they push us to rethink where the boundaries of a CMS actually are. One question keeps coming up: when does a CMS actually become a platform? My answer is simple: when managing content is no longer the main architectural problem. As long as the hard part is pages, editors, and publishing, you are making CMS decisions. Once content has to work with products, business objects, several markets, custom applications, and external systems, you are making platform decisions.
This is no "CMS is dead" argument. A corporate site with a blog, a few landing pages, and a careers section needs good editing, clean templates, and solid SEO. It does not need a domain model on day one, and there is nothing wrong with starting there. Sulu works perfectly well as a CMS for exactly that kind of project. The difference becomes visible when the requirements grow: you do not have to replace the foundation just because the website has become something more.
Content becomes one part of a bigger model
Most platforms start as a website and grow from there: a second market, a sister brand, product data from the ERP, a customer portal, a mobile app. The first sign that something has changed is usually structural. Not everything is a page anymore.
A product has attributes, variants, and relationships to other products. A location has opening hours and services. An event has dates and registrations. These objects have their own lifecycle, their own rules, and often their own source of truth in another system. You can force them into a page tree, and many teams do. It works until someone needs to filter products by three attributes across two markets. From then on, the page tree is the problem. The page that describes the product and the product itself are two different things, and once you separate them, you have started thinking like a platform team.
The questions change
The traditional CMS questions still matter: editing, workflows, permissions, multilingual content, media management. But a second set appears next to them. Can we model our actual business domain, or only pages and blocks? Can we build custom applications inside the same system, with the same admin and permissions? Can we integrate the ERP and CRM we already run? Can we serve several channels from one source? Can an AI agent answer a customer's question from our data instead of a scraped copy of our pages? And over a ten-year horizon: can our own developers extend this platform without waiting for the vendor?
If your answer is "we'll find a plugin", you are still in CMS territory. If it is "we'll build that", you have crossed into platform territory. Both can be right. They lead to very different architectures.
Architecture starts to matter more
The further a project moves beyond content management, the more the framework, data model, APIs, and extension points decide what is possible. In the early phase, the editor experience is what you notice. In the later phase, the data model is what you live with. The expensive part is rarely the first website. It is every requirement that comes afterwards when the architecture was only designed for the first one.
This is where I stop being neutral. Sulu is full-stack Symfony and open source under the MIT license, and that is why the questions above have concrete answers. You model business objects as Doctrine entities, as in any Symfony application, and Sulu gives them an admin interface, lists, forms, and permissions. Business logic lives in your own services. APIs are Symfony routes and controllers your team already knows how to build and secure.
The point is that once a CMS becomes a platform, the framework underneath it stops being an implementation detail.
A platform does not have to do everything
Platform does not mean one giant suite that owns every part of the stack. CRM, commerce, ERP, and analytics are specialized systems for good reasons. What matters is whether your platform can connect to them cleanly, own what is specific to your business, and hand off the rest. I wrote about this in August: every product boundary is another API, another permission model, and another dependency to maintain. Not every platform needs to be a marketing cloud, and I will come back to that.
Sulu is already a platform
I could list features at this point. I would rather describe what people build on Sulu today, because that is the more honest evidence.
Structured content, with templates and blocks that editors can rearrange without a developer, is the base layer. On top of that, multisite and multilingual setups run hundreds of localizations in a single instance for organizations with many brands and markets. Media management handles the assets those organizations produce and reuse across sites and channels. The headless bundle serves the same content to apps and frontends that never touch Twig. Smart content and audience targeting adapt what visitors see to where they come from and what they have done. And underneath all of it sits the application framework: Symfony, Doctrine, custom entities, admin extensions, and APIs that treat your business objects as first-class citizens next to pages and media.
Product data is the natural next step, and we are already working on treating it the same way: as its own entity with attributes, variants, and relationships, not as a page template with too many fields. You will hear more about that in October.
AI comes last in this list on purpose. It is the newest layer, and it only works because the layers below it are structured. Sulu.ai, the MCP Bundle, and Intelligent Search all read the same content model and the same entities that everything else uses. That is what makes the agent use case realistic. When a visitor asks which of your products work in a specific environment, or a sales assistant asks which locations offer a certain service, an agent has to query attributes and relationships, not paragraphs. With the MCP Bundle, external assistants get exactly those tools. With Symfony AI, your developers can build agents that live inside the application and use the same entities and permissions as everything else. AI on top of unstructured content is a demo. AI on top of a proper domain model is a tool.
None of this was assembled to fit a category. It is what happens when a Symfony CMS is used for business platforms for more than a decade and the team keeps building the pieces those projects need.
The question I have not answered yet
Analysts have a name for systems that manage content, integrate business data, serve multiple channels, personalize experiences, and let you build on top of them. Gartner calls it a digital experience platform. Strip the vocabulary away, and it describes what most of our customers run in production.
That category used to have several open source options. In the last few years, the vendors that offered an open source path into it have moved to source-available licenses or dropped the open edition. The DXP category is still there. But the open source choices within it have become much narrower.
Which leaves us with a question: what should an open source DXP look like today?
We will answer that with the next release.
