Liferay 7.3 vs 7.4: Key Changes Every Developer Must Know 

Upgrading enterprise platforms (especially one as central as Liferay) is rarely just a version bump. It’s a strategic decision and one that should deliver measurable business value. In this post, I’ll walk you through Liferay 7.3 vs 7.4 differences, how the Liferay 7.4 upgrade tool changes the game, shifts in policy between 7.3 and 7.4 and what you should expect when estimating the cost to upgrade Liferay 7.3 to 7.4. My aim: give you clarity so you (as a CXO/VP/Director) can judge whether and how fast to move. 

Why upgrade at all? (Spoiler: there is a strong case) 

Before diving into changes, you need to see the forest, not just the trees. Liferay 7.4 marks a turning point: it shifts Liferay into a rolling-release model for fixes and updates (Liferay Learn). It also introduces modern features (A/B testing, deeper analytics, better dev tooling) and some breaking changes you can’t ignore.  

If you stay locked on 7.3, each passing quarter carries more maintenance risk, more debt and more missed opportunities to improve digital experience. 

So yes, there is a business imperative. But this is about making the upgrade safe, predictable, and value-driven. Let’s dig into what changes. 

Major differences: What 7.4 gives you that 7.3 didn’t (or changes meaningfully) 

Here’s a comparison table to help you see side-by-side: 

What this really means is: 7.4 is safer, more flexible and gives you more control but it also forces you to audit your configurations, modules and customizations more rigorously. 

The Liferay 7.4 upgrade tool: How it changes your path forward 

One of the biggest pain points historically has been upgrades failing halfway and leaving your database or modules in limbo. Liferay 7.4’s tool changes that. Here’s how: 

• The upgrade tool (a standalone client) handles schema migrations offline.

• If the upgrade fails, you don’t have to revert entirely, you can fix the error and resume.

• You can disable auto-run upgrades on startup (so you control when DB migration should happen).

• The migration tool supports preview runs, error logging, rollback hooks and detailed upgrade reports.

• Because 7.4 is moving to rolling updates, the upgrade tool becomes a central piece of how you maintain the system over time (not just a one-off).

In practice: you’ll run the upgrade tool in a staging environment, iterate through fixes and then apply to production. The safer resume behavior means fewer “all or nothing” rollbacks, which cuts downtime risk. 

Policy and architectural shifts: 7.4 vs 7.3 

“Policy” here is about how Liferay is pushing you to think about updates, defaults and architecture. Some shifts: 

1. Rolling release mindset. Liferay is deprecating the old “service pack/fix pack” model. From 7.4 onward, updates will be frequent, incremental and more modular.

2. Default settings cleaned up. Some defaults in 7.3 (portal.properties) are now either removed, moved, or replaced by OSGi configs that can be managed via the UI. If you relied heavily on default behavior, you must audit what’s changed.

3. Deprecation of legacy APIs. Some older APIs or internal modules are being pruned. You’ll want to scan your custom code or plug-ins for dependence on deprecated APIs.

4. Greater separation of concerns. 7.4 encourages more modular, decoupled components, pushing you toward cleaner OSGi-based modules rather than monolithic portlets.

5. Upgrade governance. Because updates are more frequent, your internal governance (when to adopt updates, test cycles, rollback plans) must sharpen. You can’t treat major versions as infrequent events anymore, you’ll engage in ongoing maintenance.

6. Control over upgrade timing. The new upgrade.database.auto.run property means you explicitly decide when DB migrations happen (good for containers or managed environments).

If you ignore these policy shifts, you risk drifting further from supported paths and creating tech debt. 

How to plan your upgrade: steps, best practices, gotchas 

Here’s a high-level roadmap (with insights drawn from practitioners): 

1. Audit your current 7.3 footprint 

• List all custom modules, portlets, themes, hooks and third-party apps.

• Identify dependencies on deprecated APIs or internal classes.

• Capture configuration overrides (portal.properties, system settings). 

2. Set up a staging clone 

Use a replica of your production DB + content. You’ll run trial upgrades here first. 

3. Backup & snapshot everything 

Don’t rely only on backups; snapshots, VM checkpoints, rollback paths are essential. 

4. Run the upgrade tool in dry mode 

Let it produce logs, catch issues and iterate corrections. Use its error resume behavior to avoid full rollback cycles. 

5. Migrate configurations 

Compare 7.3 defaults vs 7.4 defaults. For settings moved to OSGi, reapply custom settings in a new form. (See Default setting changes in 7.4 guide) Liferay Learn 

6. Refactor modules & custom code 

Address deprecated APIs, ensure modularization and test OSGi lifecycle interfaces. 

7. Functional & performance tests 

Load testing, regression testing, performance benchmarks. Ensure nothing degraded.

8. Plan your cutover window 

Minimize user impact, possibly use blue/green or rolling deployment. Because 7.4 supports smoother upgrades, you have more flexibility. 

9. Monitor post-upgrade 

Watch error logs, resource utilization and user reports. Be ready to rollback minor parts if needed. 

10. Adopt updated discipline 

Post-upgrade, build a cadence for applying quarterly updates, security patches and features, this avoids falling behind again. 

Strategic recommendations (for decision-makers) 

Let’s talk about some pointers that decision-makers like you can’t afford to ignore if you want to reach the next level in the AI digital arena. 

• Don’t wait until support pressure forces your hand. Upgrading proactively gives you room to plan, test, and de-risk. 

• Treat the upgrade as part of your platform roadmap, not a one-off cost. Once on 7.4, shifting to quarterly updates becomes routine.

• Get buy-in from architecture, operations, QA, and business stakeholders early, you’ll need cross-team coordination.

• Consider investing in external Liferay experts if in-house experience is thin. Their early warnings and patterns save you from dead ends.

• Prioritize mission-critical modules and integrations first, leave optional or low-usage modules for later phases.

• Define rollback criteria, performance benchmarks and success metrics up front.

• After upgrade, clean house. Remove unused code, re-examine old defaults and adopt the newer tooling and analytics.

In summary 

The shift from Liferay 7.3 to 7.4 is a change in how you treat upgrades, updates and your digital experience platform mindset. The Liferay 7.4 upgrade tool gives you more safety and flexibility. The policy shifts force you to modernize how you build and maintain. The differences in features (analytics, testing, modular support) let you deliver better business outcomes. And while the cost to upgrade Liferay 7.3 to 7.4 isn’t trivial, the investment pays back in lower risk, reduced technical debt and a platform you can evolve faster. 

Frequently Asked Questions