Liferay and Spring Boot, each doing what it does best

Liferay should own what a portal platform is built for: pages and navigation, web content and documents, users, organisations, roles and permissions, forms, Kaleo approval workflow, search across content, and the personalisation that decides who sees what. Rebuilding any of that in custom code is expensive and makes every upgrade harder.

Spring Boot should own the business domain: calculations, rule engines, risk scoring, pricing, data ingestion, batch processing, and integration with core banking, ERP and partner systems. That logic changes on the business's schedule, not Liferay's; it often needs to scale separately from the portal; and keeping it in plain Spring Boot means it can be tested, released and upgraded without touching the portal — and reused by a mobile app or a partner API later.

Not everything needs a separate service. Small, portal-specific logic — a model listener, a custom field rule, a screen's data access — is often better as a Liferay OSGi module or a Liferay Object, because a network hop and a second deployment would cost more than they save. The assessment draws this line component by component and records the reason for each decision.

• Liferay — pages, content, documents, users, roles, permissions, forms, Kaleo workflow, content search
• Spring Boot — domain logic, rule engines, data ingestion, batch jobs, integrations with core systems
• Liferay Objects or OSGi modules — small, portal-specific data and logic that does not need its own service
• Shared — identity, audit trail and the API contracts between the two, owned by one team

Portlets and custom elements calling Spring Boot. The screen lives in Liferay — a React or Angular portlet, or a custom element client extension — and calls Spring Boot REST APIs for its data and actions. Liferay handles the page, the menu, the login and who can see the screen; the Spring Boot service does the work. This is the most common pattern in our banking and government portals, and the one Bank of Baroda's early-warning system uses for its risk dashboards.

Spring Boot as a microservice client extension. On current Liferay DXP releases, a Spring Boot application can be registered with Liferay as a microservice client extension: Liferay calls it when an Object entry is created or changed, or when a workflow reaches a step, and passes an OAuth 2.0 token the service verifies. Custom logic that used to be deployed as OSGi modules inside Liferay now runs and scales outside it, so a Liferay upgrade no longer means recompiling and retesting it — and on Liferay SaaS, client extensions are the way custom code is added at all.

Spring Boot calling Liferay's headless APIs. Where Liferay holds data another system needs, or the other way round, a Spring Boot service reads and writes it through Liferay's REST and GraphQL endpoints — web content, documents, users, and Objects, which get their own endpoints automatically — and uses the batch engine for bulk imports and exports rather than thousands of single calls.

Events in both directions. When something happens in Liferay that a service must react to — a user registered, an Object entry approved — Liferay publishes it through an Object action, a webhook or a model listener, and the service consumes it from a queue. When a service finishes work the user is waiting for, it notifies Liferay, which raises an in-app or email notification. Neither side polls the other, and either can be down briefly without losing work.

Users sign in once, to Liferay, and the services behind it must know who they are and what they may do. We set this up in one of two ways. Liferay can act as the OAuth 2.0 authorisation server: front-end code in a portlet or custom element gets a token for the signed-in user, and each Spring Boot service, configured as an OAuth 2.0 resource server, verifies that token before doing anything. Or Liferay and the services share an external identity provider — Keycloak, Azure AD, an Active Directory federation or CAS — through SAML or OpenID Connect, and trust the same tokens.

Authorisation is enforced in the service as well as on the screen. Hiding a button in Liferay is not security; the Spring Boot service checks the user's roles or scopes on every call, so the API is safe even if someone calls it directly. Service-to-service calls use their own client credentials, never a user's password or a shared admin account. Conscious Connects runs on Liferay DXP, Spring Boot and React behind CAS single sign-on, and removing the separate logins improved sign-in conversion by 45 %; Wipro's employee portal signs its staff in through their existing Active Directory.

Regulated work usually needs a person to approve a change before it takes effect: a risk indicator edited, a threshold changed, a customer record corrected. Liferay's Kaleo workflow is good at this — multi-level maker-checker routing, assignment by role, deadlines, reminders and a full history — so we use it for the approval and let the Spring Boot service carry out the decision once it is approved. The audit trail shows who proposed what, who approved it and when the service applied it.

For Bhutan's central bank, the EWS-Plus platform on Liferay DXP 7.4 uses a multi-level Kaleo maker-checker workflow for indicator data, with Liferay REST service modules for ingestion and a customised Elasticsearch index that returns sub-second search across millions of financial records — and no indicator can be changed without approval. At Bank of Baroda, an RBI-compliant maker-checker workflow runs on the Liferay platform alongside the Spring Boot services that hold the early-warning logic.

Bank of Baroda's early-warning system was a monolith built for one bank's data. After the mergers with Vijaya Bank and Dena Bank we rebuilt it as Spring Boot microservices on Java 11 behind Liferay DXP 7.4, with Angular portlets for the risk officers and data-ingestion pipelines for the merged entities' systems. The platform absorbed three times the data volume, risk-review cycles fell from two days to four hours, and no data was lost in the move.

Triton Digital's publisher portal runs on Liferay DXP 7.2 with Spring Boot behind it, pulling real-time listener data from streaming measurement systems over REST and handing data to advertiser platforms through custom export modules. Publisher self-service cut support tickets by 60 %, automated yield reports save the analytics team more than 200 hours a month, and the portal onboarded more than 1,000 publisher accounts in its first year.

The same split runs through intranets and partner portals: ITC Infotech's intranet on Liferay DXP 7.0 and Spring Boot brings supply-chain, SAP and HR data into role-based dashboards, and Engineers India's document platform on Liferay DXP 7.4, Spring Boot and React moved more than 200,000 engineering documents and cut retrieval time from hours to seconds.

Liferay now ships quarterly releases, and Spring Boot has its own release train. The integration is designed so each side can upgrade without the other: the services and the portal talk only through versioned REST contracts and events, contract tests run in both pipelines, and custom logic that lives outside Liferay — in Spring Boot services or client extensions — is not recompiled when Liferay changes. Our Spring Boot migration and Liferay upgrade practices plan the two together when both are behind.

Older portals often carry Spring MVC portlets from Liferay 6.x. On current Liferay they can move to PortletMVC4Spring, Liferay's supported way to run Spring Portlet MVC, which keeps the code largely as it is; or the screen can be rebuilt as a React portlet over a Spring Boot or Spring MVC API, which is what we did at ICICI Bank — the business logic stayed in Java 11 and Spring MVC while the screens moved to React portlets, and pages loaded 55 % faster. The assessment recommends one route per portlet.

We start with a fixed-fee assessment of two to three weeks. It maps every screen, workflow and integration, decides component by component what belongs in Liferay and what belongs in a service, chooses the integration pattern and the identity model, and ends in a phased plan with a fixed price for the first release.

Cost is driven by the number of screens and workflows, the number and state of the systems behind the portal, the identity setup, how much existing portal code and data has to move, and the compliance and audit requirements. For new platforms the foundations — identity, API gateway, pipelines and monitoring for both sides — are built with the first release and reused by every later one.