Liferay Migration and Replacement
Your Liferay portal was once the right decision.
Our Liferay experts analyse your portal with the help of specialised AI agents and capture every technical and business dependency in a knowledge base. From the specification derived from it, we keep what you need and add what you want. The result is a tailored, lightweight, secure and fast solution built from open building blocks.
- No more licence fees
- No lock-in
- Faster page loads
- New features delivered faster
- Optimised for AI-assisted engineering
- Fixed price after the analysis phase
Right back then, not any more.The web has moved on. The portal model has not.
In the mid-2000s, organisations ran dozens of separate applications, each with its own login. The enterprise portal promised one front door for everything: sign in once, content, documents, workflow, search and permissions from one product, many audiences on one installation. Liferay was the open, more affordable answer to that problem.
Since then, single-page applications, microfrontends, headless CMSs and API-first architectures have replaced the portlet. Every capability Liferay bundles into one product is now handled better by a specialised, open component. What remains is a monolith that slows modern development down.
The architecture sets the frame
Applications have to be integrated into portlets, OSGi modules and the Liferay Workspace. Modern tools can only be used through workarounds. Delivery is considerably more laborious and slower than with standalone custom development.
Page loads take seconds
Portlets render serially and lazy loading barely helps: every Ajax request runs through the full portal pipeline again, with filter chain, authentication and permission checks. Performance can only be bought with more hardware, and more hardware means higher licence costs.
Upgrades are projects
Every major jump means rebuilding custom portlets, hooks, Ext plugins and themes. For many teams the move from 6.2 to the OSGi-based 7.x line was a major project in its own right. After years of customisation, the portal is a one-off that only a few people still understand.
Interest has fallen by around 85 percent since 2010
Google Trends, search term “liferay”, worldwide, 2004 to today
Relative search interest, 100 is the peak within the period. Traced from Google Trends, as of October 2026.
Open-source alternatives for every Liferay feature
Liferay bundles around a dozen capabilities into one monolith. For each of them there is now an open-source alternative that did not exist back then or was not mature enough, for example Keycloak, a headless CMS, Spring Boot, OpenSearch or Camunda. The tools named are examples; we choose based on your requirements.
Back then in Liferay
Portlets following JSR 168 and 286, assembled on the server one after another. Layout, theme and navigation came from the portal.
Today, open and specialised
A standalone front-end shell, for example with React, Next.js or Astro, with pre-configured routes. Microfrontends or web components remain valid, the portal context goes away.
Back then in Liferay
LDAP and Active Directory integration, SAML and CAS. Roles were stored persistently in the portal and overwritten on the next sync.
Today, open and specialised
An identity provider such as Keycloak as the single source of identity and roles. Signed JWTs, stateless checks on every call, federation with Entra ID or other identity systems.
Back then in Liferay
A fine-grained, portal-specific model with PermissionChecker and RoleLocalServiceUtil deep in the Java code.
Today, open and specialised
Roles come from the token, and checks are declared in the code, for example via Spring Security annotations on controllers and service methods. Roles are assigned in the identity provider.
Back then in Liferay
Liferay Journal with DDM structures, editing inside the portal, content tightly bound to the portal markup.
Today, open and specialised
A headless CMS, for example Strapi or Directus, delivers content via REST or GraphQL to any front end. Editors keep their workflow, the front end stays untouched.
Back then in Liferay
OSGi modules and Service Builder in the Liferay Workspace. Upgrades across major versions were risky and expensive.
Today, open and specialised
A modulith, for example with Spring Boot or Quarkus, encapsulated by business domain. Ported Java to Java rather than rewritten, existing tests reused. Microservices only where an area genuinely needs to scale on its own.
Back then in Liferay
Liferay Vulcan provided REST and GraphQL, with its own error format and its own serialisation.
Today, open and specialised
Controllers are generated from the existing OpenAPI specification, for example with Spring Web and Spring GraphQL. Endpoints stay contract-identical, and clients keep working without changes.
Back then in Liferay
Elasticsearch as a mandatory platform component, embedded only for demos. The index belongs to the portal and is versioned with it.
Today, open and specialised
A search component such as OpenSearch where full-text search and facets are needed. Often PostgreSQL full-text search is entirely sufficient and saves a whole component.
Back then in Liferay
Document Library with versioning and permissions inside the portal.
Today, open and specialised
An existing DMS or, for example, Nextcloud, connected through open interfaces. Documents do not belong in the portal but in the system that manages them.
Back then in Liferay
Kaleo workflows inside the portal, tightly bound to portal objects.
Today, open and specialised
A standalone, BPMN-based engine such as Camunda or Flowable that any service can use. Or no workflow product at all if the processes are simple.
Back then in Liferay
Vertical: a large JVM, lots of memory, long start-up times. Horizontal only with complete nodes and cache replication, and every node costs subscription.
Today, open and specialised
Stateless containers that scale exactly where the load is, for example on Kubernetes or Container Apps. The existing CI/CD pipeline stays. No licence surcharge per core.
Can your Liferay be replaced? Your custom code decides.
How much work a replacement takes depends mainly on your own code: how much of it depends on Liferay APIs, how many sites and roles you have and how your editors work. Five questions give a first assessment.
Liferay DXP licence costs: why the numbers no longer add up today
With Liferay DXP, licence costs grow with every node and every core you need for load or high availability, and the architecture forces you to always scale the whole platform. A decoupled open-source stack scales selectively and without a licence surcharge.
Cores per instance, tiered
DXP subscriptions follow the sizing of the instance. More load means the next tier, a second node means a second subscription.
Vertical instead of targeted
A large JVM monolith with high memory needs and long start-up times. Every cluster node carries the entire platform plus cache replication, even when only a small part is under load.
Liferay CE no longer exists
Since 2026 there is only DXP with an activation key, and the key decides which features run. The free tier only gets the first build of each quarter, no patches. Anyone serious about security ends up on the subscription.
How AI speeds up the Liferay migration
A Liferay migration rarely failed because of the new build. The problem was reverse engineering: nobody knew exactly any more what thousands of lines of custom code actually did. Our AI agents read the existing code in full, generate a knowledge graph from it and derive the specification on which development then runs highly efficiently.
- 1
Capture the existing system in full
Static analysis of all imports, portlets, hooks, themes, Expando fields and Service Builder entities. How much really depends on
com.liferay.*, which features are used, and which are only paid for? - 2
Generate the knowledge graph
Every class, table, interface, role and integration becomes a node, every dependency an edge. Hidden coupling becomes visible before it gets expensive in the project.
- 3
Business requirements, not legacy
API contracts, data model, permission matrix and test cases describe the behaviour, not the old architecture. New requirements come in, unused features are dropped.
- 4
Implement highly efficiently
Controllers, front-end components, integration code and migration scripts are developed with AI support and tested against the specification. The result: a future-proof service on open standards that never leads you into lock-in again. Your code stays your code.
Liferay migration in layers instead of a big bang
Whatever has no Liferay dependency stays. Whatever depends on Liferay is replaced layer by layer and verified against the current state on the test environment before the next one follows. No years of running two systems in parallel.
1 to 2 weeks
Deep dive and design
Code analysis, open questions, editorial workflow, data maintenance, search, infrastructure. Result: a confirmed architecture picture and a binding backlog.
1 week
CI/CD and guardrails
Automated tests, dependency and security checks, reproducible builds, before the first layer is migrated.
8 to 10 weeks
Development, layer by layer
Port the back end, generate the API layer from the specification, move identity to Keycloak, replace the CMS and import legacy content, front-end shell with theme bridging.
1 week
Handover
Acceptance against the quality goals, documentation, knowledge transfer. You operate and develop it further on your own.
Frequently asked questions about replacing Liferay
What does a Liferay migration cost?
That depends mainly on how tightly your code is bound to Liferay and how many instances and nodes you run. In our projects the one-off migration usually lands between 50,000 and 300,000 euros, and running the open stack costs 500 to 2,000 euros a month. We give you a binding fixed price after the analysis phase.
How long does replacing Liferay take?
Around three months: one to two weeks of deep dive and design, one week of CI/CD and guardrails, eight to ten weeks of layer-by-layer development and one week of handover. With very deep coupling to Liferay it can take longer, and the analysis shows that.
Do we have to run Liferay and the new system in parallel for a long time?
No. We replace whatever depends on Liferay layer by layer and check each layer against the current state on the test environment before the next one follows. That means no big-bang switchover and no years of running two systems side by side.
What happens to our content and data?
Content from Liferay Journal is cleaned up and imported into a headless CMS by script, and your editors keep their workflow. Your own databases and connected systems such as a CRM usually stay as they are.
Will our single sign-on keep working?
Yes. Identity and roles will come from an identity provider such as Keycloak, which can be federated with Entra ID or other directories. Your users keep signing in with their existing accounts.
Do we have to let Posedio run the new solution?
No. After the handover you operate and develop the solution yourselves, and the code belongs to you. If you want, we take over operations for a monthly fee.
What if replacing Liferay does not pay off for us?
Then we tell you. With many sites, intensive editing, deep coupling and acceptable costs, the benefit of a replacement is not automatically greater than the effort. It often makes more sense to build new features outside the portal so the dependency stops growing. The replacement check on this page gives a first assessment.
Questions about your Liferay instance?
Your contact person
Onur Kasimlar
Onur is a certified Liferay expert at Posedio and brings years of experience in developing and operating software. He is available to answer all your questions about replacing Liferay.
CONTACTRelated Services
Design Document as a Service
Architecture, tech stack, timeline and cost in one document, before a line of code exists.
MORE >
Software Modernisation
Outpace the competition with the right infrastructure and tools.
MORE >
Cloud‑native Development
You have an idea – we have the expertise to turn it into software.
MORE >Let us read your Liferay code before you renew the next subscription.
In a free initial consultation we look at your Liferay instance together and tell you openly whether a replacement pays off. If it does, a Design Document follows with target architecture, risks, assumptions and a milestone plan. The result belongs to you.
Request a free initial consultation