What drives the cost of a Liferay migration?
There are two main factors, and the first is almost always underestimated: the condition of the database and the scope of your own code. The version gap affects both, but it is not itself the cost driver.
- Is the database even upgradeable? For portals that have grown over years or decades, the answer is often: not without preparatory work.
- How many custom modules are there—and what were they built with? Ten standard Liferay portlets are a different project than three Vaadin applications.
- How deeply does the code integrate with the platform? EXT plugins and hooks are the most expensive lines of code in the project.
What, on the other hand, is rarely the driving factor: the sheer volume of data. A portal with 50,000 pieces of content migrates barely any slower than one with 5,000—as long as the data is clean.
Why is the state of the database the biggest single factor?
Because issues accumulate unnoticed over the years and only become apparent during the upgrade. During normal operation, an orphaned reference doesn’t bother anyone—but the upgrade script stumbles over it and grinds to a halt.
Typical issues found in mature portals, especially in the Community Edition, where consolidation has been less frequent over the years:
- References to nonexistent groupIDs. Sites were deleted, but their content remained in the tables.
- Web content "zombies." Articles without structure, structures without templates, versions without articles.
- Broken portlet preferences. Configurations for portlets that no longer exist.
- Inconsistent resource permissions for objects that have been deleted.
- Mixed character sets and collations from different database generations.
These legacy issues can be resolved, but the effort required cannot be determined before the analysis. That is why the preliminary analysis is not a mere formality, but the step that turns an estimate into a fixed price: Only a test run on a copy reveals what the upgrade will actually encounter.
A healthy database migrates in a matter of hours. A problematic one can take weeks—and no one knows in advance which of the two they’re dealing with until the first test run has been completed.
How much effort is involved in each version jump?
The basic effort consists of two components: setting up the workspace and migrating the database. The following figures are based on over 50 completed Liferay projects since 2008 and apply to a database without significant legacy issues:
- Liferay 7.4 → 2026.x: Workspace 0.5 to 1 person-day, database a maximum of 2 hours.
- Liferay 7.0 / 7.1 / 7.2 / 7.3 → 2026.x: Workspace 1 to 2 person-days, database 0.5 to 1 person-day.
- Liferay 6.0 / 6.1 / 6.2 → 2026.x: Workspace 3 to 4 person-days, database 3 to 4 person-days.
- 2026.Qx → 2026.Qy (e.g., Q1 to Q3): approximately 1 person-day, including a test run, backup, and verification.
An upgrade from 7.4 to the current version can therefore be completed in one day. Starting from 6.2, the basic effort alone amounts to six to eight person-days—before a single custom module has even been touched.
If the test run detects database corruption, the time required to fix it is added on top. This is the only item that can be reliably quantified only after the analysis.
How much does it cost to migrate our own modules?
That depends less on the number of modules than on how they were built. Four questions determine the effort required per module:
- What was it built with? Standard Liferay portlets can be updated. Modules based on JSF or Vaadin are the most expensive case: These technologies are no longer relevant today; there is no migration path, so they must be rebuilt from scratch.
- How many EXT plugins are there? EXT directly interferes with the Liferay core. It no longer exists in modern versions—each EXT plugin must be rebuilt from scratch, often with the preliminary question of whether the feature is even still needed.
- How many hooks? Hooks now exist only in a highly limited form. Some can be implemented using built-in features, some using client extensions, and the rest must be developed from scratch.
- How many calls to APIs that no longer exist? This is the item most often overlooked when estimating. Some APIs have been removed; others now work differently—both issues only become apparent during compilation or, worse, during testing.
In addition, for upgrades from version 7.4 onward, there’s the transition from Java EE to Jakarta EE: Every import of javax.servlet must be changed to jakarta.servlet be changed. It’s a mechanical process, but it has to be done in every module—and it’s easily automatable.
Why do costs sometimes drop to zero?
Because part of the in-house development has become redundant due to the platform. This is the most welcome finding of an analysis and occurs more frequently than operators expect.
A real-world example: A module that adds multilingual friendly URLs was a sensible in-house development in older versions. Since Liferay 7.4, this feature has been built-in. The module is not migrated but removed entirely—the feature remains, and the maintenance effort is permanently eliminated.
The same applies to search functions, form components, authorization logic, and navigation elements, for which fragments, Liferay Objects, or standard widgets are now available. Every module eliminated in this way reduces not only the migration costs but also those of the next-but-one upgrade.
Before providing any quote, Portalworks conducts a preliminary analysis with a test run on a database copy and then issues a fixed-price quote, rather than billing on a time-and-material basis. The initial consultation is free of charge.
Migrate or build from scratch—which is more cost-effective for legacy portals?
With Liferay 6, this question is almost always worth asking, and the answer tends to favor building from scratch more often than operators expect. The reason lies not in Liferay itself, but in how development has changed since then.
A portal from 2014 consists of heavyweight portlets because nothing else was available at the time. Every tile, every list, every form was a Java module with its own deployment cycle. Today, the platform meets the same needs with significantly lighter-weight solutions:
- Client extensions instead of modifications to the platform—they survive version updates largely unscathed.
- Fragments and style books instead of custom theme logic—layout and design are created without Java code.
- Liferay Objects instead of custom-built data models—entities, forms, and lists are created using a low-code approach.
- Headless APIs instead of deeply integrated front ends.
This leads to an uncomfortable but honest conclusion: Anyone who migrates forty portlets from 6.2 one-to-one to 2026 is paying for forty new builds—and ends up with a portal whose architecture dates back to 2014 and will incur the same costs all over again with the next upgrade.
The right question regarding Liferay 6 isn’t “How do we migrate this?” but “What do we even still need from it?”
In practice, this review regularly eliminates a significant portion of the legacy system: features that no one uses anymore; custom developments that are now standard features; modules that exist only because a specific version had a particular gap. What remains is built on the current architecture—and is significantly cheaper when the next version is released.
Three criteria support building from scratch rather than continuing with the existing system:
- The starting version is 6.x—the customizations have to be rebuilt from scratch anyway.
- A significant portion of the custom development is now a standard feature or is no longer used.
- The portal is scheduled for a business-function overhaul anyway—otherwise, you’ll end up paying for the migration twice.
Arguments in favor of a version upgrade: a base version of 7.0 or higher, manageable in-house development, tightly integrated systems that run stably—and a portal that is intended to remain functionally as it is.
Why does migration become more expensive the longer you wait?
Not because Liferay becomes more complicated—but because your own code ages and the number of intermediate steps increases. Four factors work together:
- The number of steps increases. Liferay supports upgrade paths, but very old versions require intermediate steps. Each one takes time to go through and test.
- Your own code becomes outdated as well. Anyone who stopped updating in 2019 now faces not only OSGi but also the Jakarta EE transition—and APIs that no longer exist in that form.
- The database continues to accumulate data. Every year of operation produces new orphaned references and inactive records. The effort required to clean up grows over time, not with usage.
- Security is slipping away. The Community Edition has been discontinued; 7.4.3.132 was the last release. There are no longer any security updates.
The most expensive migration is the one you’ve postponed three times. Not because of the leap itself—but because of everything that’s been built around the portal in the meantime.
How quickly can a migration be completed within the 2026 versions?
In one day, including preparation and testing. A concrete example: Portalworks migrated its own website, portalworks.de, from Liferay DXP 2026.Q1.2 to 2026.Q3.1 on August 28, 2026.
- 485 database tables, 216 MB of documents, custom theme, custom modules
- Database upgrade and server startup combined: 61 seconds
- Zero errors in the upgrade log
- The site was briefly unavailable during the upgrade window, but ran faster afterward
This was possible because the migration had been run locally twice beforehand—once on a newer database version and once on the exact version of the production server. Both runs yielded insights that would have cost hours in a real-world scenario:
- The Tomcat bundle does not automatically perform the database upgrade. Without
upgrade.database.auto.run=true, the startup aborts with a schema error—cleanly, but surprisingly if you’re not expecting it. - The free activation key carries the product version
2026.Q1but is also accepted by 2026.Q3. A new key was not necessary. - A database upgrade was not required. Liferay 2026.Q3 runs on MariaDB 10.3 without any issues.
What makes a migration fast—and what makes it expensive?
The difference between a day and several weeks rarely lies with Liferay, but rather with decisions made years earlier. Anyone building a system today who wants to migrate cost-effectively in five years should follow these five rules:
- No patched core. If you override Liferay classes, you’ll pay the price again with every upgrade.
- Use client extensions instead of modifying the platform. They survive version changes largely unscathed.
- Standard fragments instead of custom theme logic. The fewer custom solutions in the frontend, the less rework is required.
- Headless instead of a deeply integrated front end. A front end connected via APIs is barely affected by a portal upgrade.
- Upgrade regularly. Two small increments are significantly less expensive than a single upgrade covering the same distance.
What does AI really contribute to a Liferay migration?
It significantly reduces the amount of repetitive work but does not replace architectural decisions. Through the Liferay MCP Server, AI agents can read and write content, structures, and configurations—which primarily impacts three areas:
- Content migration. Mapping old structural fields to new models is painstaking work that the agents reliably handle. Portalworks has published a technical article on this topic on the Liferay website.
- Code conversions. The transition from
javaxtojakartais rule-based and therefore easily automatable. - Testing. Comparing hundreds of pages before and after migration can be automated instead of being done manually on a sample basis.
What AI can’t handle: deciding which custom developments will be eliminated entirely, which will be replaced by built-in features, and which must be rebuilt from scratch. This is precisely where the main effort lies with legacy portals—and this is exactly why you need someone who is familiar with both versions.
How do you arrive at a reliable figure?
Through a preliminary analysis. Portalworks examines which Liferay version is in use, how many custom modules exist, what integrations are in place, and how the front end is built. This results in a migration plan with a fixed price.
This step is also worthwhile even if the migration isn’t imminent: it reveals which legacy issues will drive future costs—and which can be resolved cost-effectively beforehand.
Our migration calculator (see below) allows you to roughly estimate how much effort we anticipate your migration will require.