“How much will our Liferay upgrade cost?” is usually the first question a CIO or product owner asks, and the honest answer is: it depends on a handful of factors you can measure before anyone writes a line of code. Two Liferay upgrades can start from the same version and end up with budgets that differ by an order of magnitude, because the effort is driven by your customizations, your data and your integrations, not by the version number alone.
This guide explains where the money actually goes in a Liferay upgrade, what a realistic timeline looks like phase by phase, and how to get a reliable estimate instead of a guess. It applies whether you are moving from Liferay Portal 6.2, from DXP 7.x, or from DXP 7.4 to the quarterly releases.
Why the Upgrade Cost Question Matters Now
Liferay now ships quarterly releases, and each year the Q1 release is designated as the Long-Term Support (LTS) version, with a three-year Premium Support phase followed by a two-year Limited Support phase. Other quarterly releases get one year of Premium Support. At the same time, DXP 7.4 is approaching the end of its Premium Support phase, which Liferay’s service life policy ties to four years after the general availability of its final release.
In practice, many companies are planning a move to the 2026.Q1 LTS release, as explained in our DXP 7.4 end of support guide. Budgeting early lets you choose the timing instead of being forced into a rushed project when patches stop arriving.
The Five Cost Drivers of a Liferay Upgrade
Almost every hour in an upgrade project can be traced back to one of these five drivers. Measure them first and the estimate largely follows.
1. Source version and upgrade path
The distance between your current version and the target matters, but less than most people assume. According to Liferay’s documentation, the minimum starting point for a direct upgrade to current releases is Liferay Portal 6.2 (6.1 requires enabling a specific feature flag). What really grows with distance is the number of breaking changes your code has to absorb: the move from the 6.x plugin model to OSGi modules in 7.0, the removal of deprecated APIs over the 7.x line, and most recently the switch from Java EE to Jakarta EE.
2. Volume and type of custom code
This is typically the largest cost item. Count and classify what you have:
- Portlets and MVC modules (straightforward to heavy, depending on the frameworks used)
- Hooks and Ext plugins (Ext plugins are the most expensive: they must be redesigned, not ported)
- Service Builder entities and custom database tables
- JSP overrides and fragments of core modules
- Themes, layout templates and front-end build tooling
Code that overrides Liferay core behavior costs far more than code that only uses public APIs. A portal with forty clean portlets can be cheaper to upgrade than one with five deep core overrides. This is also why the choice between OSGi modules and client extensions affects every future upgrade bill: we compare both in our guide to Liferay client extensions vs OSGi modules.
3. The Jakarta EE switch
Starting with the 2025.Q3 release, Liferay DXP moved from Java EE 8 to Jakarta EE, which Liferay describes as a breaking change for custom code and certain dependencies. Every module that imports javax.servlet, javax.portlet or similar packages must be migrated to the jakarta namespace, and third-party libraries must be available in Jakarta-compatible versions. Liferay provides tooling to automate part of this (for example the blade gw upgradeJakarta command in Liferay Workspace), but dependency updates and regression testing still take real time.
4. Data volume and database health
The database upgrade itself is run with Liferay’s Database Upgrade Tool, offline. Liferay’s own documentation notes that upgrading large data sets can take a prohibitively long time without preparation, and recommends pruning unused instances, sites, pages and old content versions, plus tuning the database for the write-heavy upgrade process. Large Documents and Media repositories, many web content versions or years of audit data all extend the number of test runs you will need before the production cut-over.
5. Integrations and infrastructure
SSO (SAML, OpenID Connect, LDAP), ERP and CRM connectors, search (Elasticsearch or OpenSearch version compatibility), the application server and the Java runtime all need to be validated against the target release. If you are also changing hosting at the same time, for example moving to containers or to Liferay’s PaaS, that is a separate workstream with its own budget.
A Realistic Timeline, Phase by Phase
Rather than a single number, think of the upgrade as five phases. Their relative weight depends on the drivers above.
Phase 1: Assessment and planning
Inventory of custom code, data volume analysis, dependency review, and a trial database upgrade on a copy of production. This short phase is where you replace assumptions with facts, and it is the best investment you can make: it is what turns a vague estimate into a committed plan.
Phase 2: Code migration
Porting portlets, hooks and themes, redesigning Ext plugins, migrating to Jakarta EE, and replacing deprecated APIs. On most projects this is the longest phase. Where a customization is no longer needed because Liferay now covers it out of the box (Objects, Fragments, Client Extensions), removing it is often cheaper than porting it.
Phase 3: Database upgrade rehearsals
Repeated runs of the Database Upgrade Tool on fresh copies of production data, fixing upgrade errors, pruning data and tuning the database until the run time fits your maintenance window.
Phase 4: Testing and user acceptance
Functional regression tests, integration tests, performance tests and user acceptance by business teams. Underestimating this phase is the most common reason upgrade projects run late.
Phase 5: Go-live and stabilization
Production cut-over during a planned window, search reindexing, monitoring, and a short hypercare period to fix issues discovered by real users.
Hidden Costs Teams Often Forget
- Parallel environments: you run the old and new platforms side by side for development, rehearsals and UAT.
- Content freeze: editors may need to pause publishing during the final migration, which has a business cost.
- Licensing and subscription changes: check with Liferay or your reseller whether your subscription covers the target version and deployment model.
- Training: administrators and content authors need time to learn new interfaces such as Content Pages and Fragments.
- Technical debt found along the way: an upgrade often exposes undocumented customizations that nobody remembers writing.
How to Reduce the Cost of Your Liferay Upgrade
- Decommission before you migrate. Every unused portlet, site or content version you remove is one less thing to port and test.
- Replace customizations with standard features. Liferay Objects, Fragments and Client Extensions can replace a lot of legacy Java code.
- Automate your tests early. Automated regression tests pay for themselves across the repeated rehearsal runs.
- Rehearse the database upgrade on real data. Surprises found in rehearsal are cheap; surprises found at go-live are not.
- Target an LTS release. Landing on a Q1 LTS release gives you the longest support window before the next mandatory upgrade.
For a concrete example of how these steps play out, see our Liferay portal migration to DXP 7.4 case study. If you are still on 6.2, our step-by-step 6.2 migration guide details the extra plugin work involved.
How to Get a Reliable Estimate
A trustworthy quote for a Liferay upgrade is based on evidence, not on the version number. Before accepting any figure, make sure the estimate is backed by:
- a complete inventory of modules, plugins and themes, with a complexity rating for each;
- at least one trial run of the database upgrade on a recent copy of production;
- a list of integrations and the target versions of the app server, Java, database and search engine;
- an explicit test strategy and who performs user acceptance;
- clear assumptions and exclusions (hosting changes, redesigns, new features).
You can learn more about our approach on our Liferay consulting and upgrade services page.
FAQ
Can we upgrade directly from Liferay 6.2 to the latest release?
Yes. Liferay’s documentation lists Liferay Portal 6.2 as the minimum starting build for a direct database upgrade to current releases (6.1 is possible with a feature flag). The custom code, however, still has to be migrated to the modern module architecture.
What is usually the most expensive part of an upgrade?
Custom code migration, especially Ext plugins and core overrides, followed by testing. The database upgrade itself is mostly a matter of preparation and rehearsal.
Should we skip intermediate versions?
In most cases you target the latest LTS release directly, since the Database Upgrade Tool handles the schema steps. Skipping versions does not remove the code changes introduced along the way, so your code must be adapted for all of them.
Does the Jakarta EE switch affect every project?
Any upgrade to DXP 2025.Q3 or later, including the 2026.Q1 LTS, must deal with it. Projects with little custom Java code are affected much less than those with many modules and third-party libraries.
How long does the database upgrade take?
It depends on data volume, database tuning and pruning. The only reliable answer comes from a rehearsal run on a copy of your production data.
Planning a Liferay upgrade? Get a free technical assessment and receive an evidence-based estimate of the cost, the timeline and the risks for your portal.