Liferay upgrade & migration to DXP 7.4, without the rewrite

Liferay retires each release line a few years after it ships. Liferay 6.2 and the early 7.x lines are already past premium support, and 7.3 follows on Liferay's published lifecycle — which means no security patches for a platform that usually sits behind your customer or employee login. The longer a portal stays on an old line, the wider the gap grows: every year of not upgrading adds another year of API changes, Java versions, browser deprecations and dependency CVEs that the eventual upgrade has to cross at once.

DXP 7.4 is also a different product from the one most old portals were built on. Content pages and fragments replaced hand-built layouts; Liferay Objects let business teams model data without a Service Builder entity; client extensions let custom JavaScript, CSS and micro-frontends live outside the platform; headless REST and GraphQL APIs serve the same content to a React app or a mobile app; and Liferay now ships quarterly releases with a yearly long-term-support line. An upgrade is the moment to adopt these rather than port fifteen-year-old workarounds for their absence.

The commercial case is usually the simplest one. ICICI Bank ran four separate portal applications, each with its own infrastructure and maintenance team; consolidating them into a single DXP 7.4 instance cut infrastructure cost by 45 % and operations overhead by half. The upgrade paid for itself before the modernised portlets shipped.

Every upgrade engagement starts with a one- to two-week assessment of the portal as it actually runs — not as it was documented when it launched. We inventory the deployed plugins and modules, the hooks and ext plugins, the themes and layout templates, the Marketplace apps, the integrations and the custom database tables; we measure the database, the document library and the number of web-content and document versions; we check the permissions algorithm, the Java version, the app server and the search engine; and we read the code that will not survive the upgrade unchanged.

The output is an upgrade plan you can act on with or without us: every component classified as keep, port, replace or retire, with effort against each; the upgrade path that fits; a list of features that behave differently in 7.4 and need a product decision; a dry-run of the database upgrade tool on a copy of production with its actual run time; and a fixed price for the implementation. The dry-run matters more than it sounds — it surfaces the corrupt rows, orphaned documents and unsupported customisations that would otherwise appear at 2 a.m. on cut-over night.

• Code inventory — plugins, OSGi modules, hooks, ext plugins, Service Builder entities, custom SQL
• Content inventory — sites, pages, layouts, themes, structures and templates, workflows, Marketplace apps
• Data profile — database size, document library size, version counts, file-store type, orphaned records
• Platform profile — Java, app server, database, search engine, clustering, SSO and integrations
• Deliverables — component-by-component plan, upgrade path, dry-run results, fixed-price proposal

From 7.3 to 7.4 the platform is continuous: OSGi modules, Liferay Workspace, FreeMarker themes and the headless APIs all carry over. The work is the database upgrade, a dependency and Java-version refresh, a Clay and JavaScript update for anything still on Metal.js or AlloyUI, and a regression pass. Most portals on 7.3 can be on 7.4 in four to eight weeks, and after that the quarterly releases are routine.

From 7.0, 7.1 or 7.2 the code model is the same but the front end is not. Themes built for the early 7.x releases, portlets on Senna and Metal.js, and layouts assembled by hand all need rework; SOAP web services and some deprecated APIs are gone; and the upgrade tool has several years of schema changes to apply, which is where the rehearsal earns its keep. We port the modules, rebuild the themes and layouts on content pages and fragments, and take the opportunity to move the heaviest portlets to React — the change that gave ICICI Bank a 55 % faster page load.

From 6.1 or 6.2 the honest description is a rebuild in place. Plugins-SDK WARs, ext plugins, Velocity themes and the 6.x permission system do not port; every custom feature is re-implemented as an OSGi module, a fragment, an Object or a client extension, while the content, users, roles, documents and workflow history come across through the upgrade tool — after a mandatory step to 6.2 and permissions algorithm 6 if the portal is still on 6.1. We have run 6.1 and 6.2 portals for PodEngine, Netwokin, IGT and MasterCard, so we know exactly what those code bases contain and what 7.4 has replaced it with.

There is a fourth path that is really a business decision: consolidation. When an organisation has accumulated several portals — separate applications, separate logins, separate teams — the upgrade is the moment to fold them into one DXP instance with sites or virtual instances, one SSO and one support model. That is what ICICI Bank did, and it is usually where the largest saving is.

Liferay's database upgrade tool does the heavy lifting, but how long it runs and whether it finishes depend on what you feed it. Before the real run we prune expired web-content and document versions (with the business's sign-off on retention), clean orphaned document-library rows, move the file store to S3 or the advanced file system if it is still on the legacy layout, and fix the data the dry-run complained about. On a large portal this turns an upgrade that would run for a day into one that runs for an hour — which is the difference between a maintenance window and a weekend outage.

We run the upgrade at least three times: on a fresh copy of production during assessment, on a staging environment with the ported code, and finally on the cut-over night. Each run produces a reconciliation report — users, roles, sites, pages, journal articles, documents, workflow instances, custom entities — counted before and after and compared. Engineers India Limited moved 200,000+ engineering documents to a DXP 7.4 document-management platform this way with Elasticsearch-powered search on the other side; Bank of Baroda's early-warning system was re-platformed on DXP 7.4 with a hundred per cent of its data intact while scaling to three times the volume after the bank's mergers; CIGNEX's legacy CMS came across to Liferay with zero content loss across twelve language variants.

Search is its own migration. Portals still on Solr move to Elasticsearch; portals on an old Elasticsearch move to a supported major version, usually as a separate cluster rather than the embedded sidecar; and everything is reindexed with the new analyzers, then spot-checked against the queries your users actually run.

The reason a portal is hard to upgrade is almost always that a previous team modified Liferay itself — ext plugins, patched JSPs, forked core modules, custom SQL against internal tables. Our rule on every upgrade is the same as on every new build: never change core. Custom behaviour goes into OSGi modules with declared dependencies; JSP changes go into fragment bundles and dynamic includes; overrides use the extension points Liferay documents; and anything that still needs a core patch is written down as a risk with a plan to remove it.

Where a custom entity only stores and lists business data, we replace the Service Builder code with a Liferay Object — configurable, permissioned, exposed over headless APIs and upgraded by Liferay rather than by you. Where custom JavaScript or CSS lives in a theme, it moves to a client extension or a style book so the theme is no longer a fork. And where a portlet is doing real application work — a dispute-management screen, a maker-checker approval, a risk dashboard — we rebuild it as a React or Angular portlet against a Spring Boot service, the pattern behind the Bank of Baroda and ICICI Bank platforms.

The test of a good upgrade is the next one. A portal that leaves us on 7.4 with all customisations in modules, fragments, Objects and client extensions takes the next quarterly release as a dependency bump and a regression run — which is what our support retainers do for clients every quarter.

The assessment is a fixed fee and takes one to two weeks. As a guide from our own projects, the implementation then runs four to eight weeks for a 7.3 → 7.4 upgrade with a modest custom-code base; three to five months for 7.0, 7.1 or 7.2 → 7.4 where themes, layouts and the heavier portlets are rebuilt; and five to nine months for a 6.x rebuild in place or a multi-portal consolidation, delivered in releases so that the business sees progress before the cut-over.

Six things set the cost: the number and kind of custom plugins (a hook is an hour, an ext plugin is a rewrite); the number of themes and hand-built layouts; database and document-library size, which drives rehearsal and cut-over time; the integrations to re-test; the number of environments and the state of CI/CD; and how much downtime the business can accept, because a zero-downtime cut-over costs more than a weekend one. Liferay licence changes — DXP subscription tiers, or a move between DXP and the community Portal edition — are a separate line we help you size but do not mark up.

We quote the implementation as a fixed price for the scope in the assessment, with change control for anything found afterwards, and the post-upgrade support as a monthly retainer. You will not find a price list here because an upgrade without an inventory is a guess; send us the version you are on and roughly what has been customised and we will give you a bracket within a couple of days, and a number after the assessment.

Cut-over is rehearsed to a script: freeze content on the old portal, take the final database and file-store snapshot, run the upgrade on the new environment, reindex, run the reconciliation and smoke tests, switch DNS or the load balancer, and keep the old environment intact for a rollback window agreed in advance. For portals that cannot take a weekend outage we run the old and new environments side by side with the database frozen and switch traffic in stages. Either way, the decision to go or roll back is made against a checklist, not a feeling.

After cut-over comes a hypercare month with the engineers who did the upgrade on call, then a support retainer that applies Liferay's quarterly releases and security patches, monitors the platform and picks up the small changes that follow any upgrade. The hosting decision — your own servers, AWS or Azure with Docker, or Liferay's PaaS and SaaS offerings — is made during the assessment, and we set up the target environment with CI/CD before the first rehearsal so that every run of the upgrade is reproducible. Our wider Liferay DXP practice covers the new-build, integration and banking work that usually follows.