Since 2026.Q1, Liferay officially documents two CMS. The new one, called Liferay CMS or headless CMS, handles content as structured, reusable data. The historical one, now named Classic CMS, remains optimized for web delivery and has been in maintenance mode since that same release. Since 2026.Q3, the new CMS is generally available, with no feature flag to enable.
The direction is explicit: the headless CMS is the recommended system for new implementations, to benefit from object modeling and multichannel delivery.
This evolution therefore goes well beyond a redesign of the authoring interface. It is the content model itself that Liferay chose to rebuild.
Multichannel already existed
Liferay did not discover headless with this new CMS.
It has exposed its content through headless APIs for several versions. As early as 7.2, it presented these capabilities as a way to enable omnichannel experiences from a single data source, with delivery APIs aimed at front-end developers. Sharing across sites also existed: asset libraries act as content repositories that can be connected to several sites, and they remain available today, alongside the new CMS.
A company that wanted to feed a mobile application from its Liferay content could therefore do so, and many did.
What the historical model actually cost
Classic CMS content is structured. Web Content structures define typed fields, and those fields are accessible through the APIs.
That structure, however, belongs to the Web Content model, and the platform’s cross-cutting services must explicitly know how to interpret it. The new CMS changes this relationship by resting directly on the object framework.
Semantic search gives the exact measure of it. It produces vector representations of content to enable intent-based search. For classic web content resting on a custom structure, only the article’s localized title feeds this representation: custom fields are not processed. For a custom content structure in the new CMS, it is the localized title and the combined content of the indexable fields.
Same structure, same apparent richness, and a cross-cutting platform service that exploits only a fraction of it in one case and all of it in the other. The modeling is equivalent; it is the foundation it rests on that changes what the platform can do with it.
Every external consumer therefore remains dependent on the representation specific to the module it uses, and every platform service must know how to interpret it to take advantage of it. Evolving a content type then requires assessing the impact on each of the channels that consume it.
The same reasoning applies to how work is organized. Creating a content type means defining its structure and the accompanying rendering elements. Sharing across sites relies on an administration mechanism separate from contributors’ day-to-day working environment. And rights management remains tied to the organization of sites and folders.
Content can be used elsewhere, but it was not originally designed as an autonomous business resource.
The change is about the content model
The new CMS is built on the platform’s object framework: content is stored as structured, reusable data rather than as a page. Content and file structures define the data schema, including custom fields, references to other structures and workflow configurations.
Content is no longer modeled solely according to the conventions specific to Web Content: it now rests on the same object framework as the platform’s other business data. What holds for an object therefore holds for an article: exposure through REST and GraphQL APIs, indexing, workflow, permissions, display in collections.
Integration work on the channel side remains: a mobile application must still know what to do with the data it receives. It works, however, from an explicit model shared by all the platform’s services, rather than from the conventions of a particular module.
Making an old model accessible from the outside is one thing, which Liferay was already doing; redefining the model so that this accessibility is its natural form is another.
Contribution spaces that follow the organization
The new CMS organizes content into Spaces, the tool’s primary organizational units. A Space brings together content, members with their own roles, language settings, a recycle bin and sharing rules. It can be connected to one or more sites for delivery.
The lineage with asset libraries is deliberate: Spaces offer their flexibility while being fully integrated into the CMS interface. The shared repository therefore already existed; it moves from being an administration tool to being the default working environment.
In a multi-entity organization, a Communications team, an HR team and a subsidiary each have their own Space, with their contributors and their approval workflow. The news produced by the HR team can feed the group intranet and the subsidiary’s without being recreated in each site.
Content production stops mirroring the structure of sites and starts mirroring that of the organization. In multi-brand, multi-country or multi-entity groups, the two never quite coincide, and that gap is usually paid for in duplication.
Permissions that are simpler to maintain
This is the most visible change for the teams that administer the platform day to day.
In the classic model, permissions defined at the folder level do not automatically cascade to the subfolders and items it contains. At the scale of a group intranet, this translates into regular rights-cleanup campaigns and a lasting gap between the intended policy and the observed reality.
Default permissions can now be defined at the level of a Space or a folder, with distinct sets for subfolders, content and files. They apply to items created after their configuration, and a dedicated action makes it possible to propagate them to existing items, with explicit confirmation from the administrator. Rights can also be managed role by role, in bulk, or refined at the level of a folder, a structure, a piece of content, a vocabulary or a category.
Designing a coherent rights policy remains necessary; its application becomes administrable and verifiable, instead of relying on the teams’ discipline.
From development to configuration
The ability to define fields in an administration interface has existed at Liferay for a long time. What changes with the new CMS is what publishing a type entails.
When a content structure is published, a collection provider is created automatically, that is, a ready-to-use content source: it gathers all the content produced from that structure and becomes available in the configuration of collections and display fragments. For standard use of a structure, the step of defining a collection beforehand disappears; dynamic or manual collections remain necessary only for specific filtering, sorting or selection.
An authoring experience is also generated automatically when the structure is published. With an Enterprise subscription, this experience can be opened in the page editor and reworked with form fragments: accordion, inline instruction text, file drop zone, video preview. The form is simplified for occasional contributors and enriched for a demanding editorial team.
The role of technical teams evolves accordingly: less exposure plumbing for each new type, more modeling, governance and cross-cutting usage design.
Content becomes an asset
This consequence does not show up in a product demo, but it shapes content management over time.
In a site-oriented CMS, nothing requires creating content in the site that needs it, but it is the shortest path. Content then follows the lifecycle of that site: dropped during a redesign, recreated for another portal, governed by rules that vary from one team to another.
Content is now produced in a governed space, then consumed by different channels. The organization can then ask the questions that characterize managing an asset: where is this information used, who can change it, in which languages does it exist, when should it be reviewed.
This logic also makes it easier to leverage content through more recent mechanisms. Liferay’s semantic search covers the new CMS types, including custom structures, with the level of processing mentioned above. Other uses, around assistants and agents, rely on the same APIs.
Content that is structured and properly governed is simpler to leverage by a mobile application, a search engine or an agent, and for the same reason: its structure and its rules are explicit and shared.
A gradual adoption is possible
Classic CMS is not going away. It remains fully supported, while evolutions focus on the new model, and the two systems run in parallel within the same platform. Existing sites and applications that depend on classic features keep working.
For organizations that already have a substantial content estate, there is therefore no obligation to transform the existing one right away.
The approach we favor is to design new content domains on the new model, let the existing one live on, and migrate only what yields an identifiable benefit.
The work therefore starts with modeling: identifying the content that must be shared across several channels or several entities, understanding who produces it and who consumes it, defining the Spaces, roles and governance rules. Migration comes next, if it is justified.
Key takeaways
Liferay is not rebuilding its CMS because the platform could not deliver content across several channels. It was already exposing its content through headless APIs for several versions, notably as early as 7.2.
The change is about the foundation of content in the platform. Liferay makes it rest on the same framework as the other business data, instead of leaving it dependent on the conventions of the single module that hosts it. The semantic-search case shows that this difference is not theoretical.
For teams, this translates into contribution spaces closer to the real organization, administrable rights management, greater autonomy over content-type definition, and a reusable estate without duplication.
The question organizations face is therefore not whether to adopt this model: for new implementations, Liferay has already decided. The useful question is which modeling to start with, and that is an architecture decision before it is a migration project.
This article deliberately stays focused on usage and governance. A dedicated engineering note details the architecture of the new model, the APIs, how permissions work and the main points of attention for implementation: “Liferay CMS 2.0: an architectural analysis of the new content model”.
Our teams frame your roadmap and secure every step. Let’s talk.
Discuss your project →