Liferay DXP Migration: A Practical Guide to a Smooth Upgrade (Including CE to DXP & 2026 Q1 LTS)

A Liferay DXP migration is rarely “just an update.” In practice, it is a structured modernization project: database upgrade, customization of custom code, infrastructure review (Java/application server), regression testing, cutover planning—and then an update regimen that works long-term.

Why this guide? Many articles explain the process in broad phases. That’s helpful, but they often lack the crucial details that determine costs, risk, and schedule in real projects (e.g., version/LTS strategy, Jakarta migration, client extensions as an upgrade lever, test design, rollback). We fill exactly these gaps here, with practical and actionable advice.

By 2026 at the latest, “simply staying with CE” will no longer be a viable option for many organizations: With the 2026 release model, Liferay is transitioning to a unified platform where features are unlocked via an activation key (instead of separate CE/DXP distributions).

Implications for your migration planning:

Upgrade decisions are more closely tied to your operating model, support, and security.

For many, the move to 2026.Q1 LTS is a sensible strategic milestone (modernization + predictable support path).

If you use CE, be sure to read our article “Liferay CE is ending.”

Liferay releases updates quarterly; Q1 is the annual LTS (Long-Term Support) release, which has a significantly longer support period than Q2–Q4.

Best practices for the roadmap:

• Define a target version (e.g., “migration to LTS” instead of “any current quarter”)
• Consider a two-part strategy: Land on a stable version (LTS), then continuously modernize (minor updates).
• Establish “upgradeability” as a product goal: Fewer overrides, clear extension strategy, CI/CD, automated testing.

Typical migration paths we see in projects:

• Liferay 6.2 → DXP (7.4/Quarterly):  
  Most technically complex (legacy architecture, themes, plugins, data).
• Liferay 7.0–7.3 → 7.4:  
  Usually easy to plan, but custom code and themes are the bottleneck.
• Liferay 7.4 → 2026 Q1 LTS:  
  Often driven by platform strategy, Jakarta/runtime changes, and infrastructure modernization.
• CE → DXP:  
  Often less of a “rewrite” than expected, but version alignment and build/dependency migration are critical.
• On-Prem → Liferay Cloud:  
  Additional considerations: data freeze, artifact/config migration, operational processes

1) Assessment & Inventory (Scope, Risk, Timeline)

The goal of the first step is to gain an overview. To this end, it is helpful to create a “Migration Map” containing the following:

• Customization Catalog (Modules, Themes, Fragment/JSP Overrides, Hooks, Scheduler, SSO, Search, Commerce, Objects)
• Integrations (IAM, CRM, DMS, SAP, Payment, Shipping, Email)
• Operational artifacts (Configs, Secrets, JVM flags, DB settings, Monitoring)
• Content/data volume (DLStore, Index, Structures, Versioning)

Deliverable: Architecture and migration concept + risk matrix.

The compatibility matrix is essential reading, especially when planning for 2026: supported combinations of application servers, databases, and Java versions change over the years.

Deliverable: “Certified Stack” decision, including hosting model (on-premises/cloud) and operational requirements (HA, DR, RPO/RTO).

Based on experience from numerous migrations, the biggest time sink is not the database, but custom code that is tightly coupled to internal APIs or UI details.

Client extensions are the key to reducing upgrade stress. They allow for customizations without deploying Java code to Liferay and are therefore more loosely coupled (API-first)—a major advantage for future upgrades.

Deliverable: Refactoring backlog (Must/Should/Could), including a plan specifying which customizations will be converted to client extensions, which will remain as OSGi components—and which will be eliminated.

Plan this step with particular care:

• Perform backup and restore tests (otherwise, a “rollback” remains purely theoretical)
• Create upgrade runbooks (step-by-step procedures, execution times, logs, stop/go criteria)
• Validation: Spot checks + automated checks (counts, key objects, permissions, workflows)
• Depending on the scope of the migration and the operational processes, a “freeze window” and a two-stage data transfer (DB + Document Library) may also be required

Key tests that really matter in Liferay projects:

• Smoke tests for core user journeys (login/SSO, search, download, forms, etc.)
• Regression testing of key roles/permissions
• Performance baseline (before/after)
• Security checks (headers, session, permissions, audit-relevant functions)

Deliverable: Acceptance report + go-live approval (including “known issues” and workarounds).

A professional cutover includes:

• Clear communication about downtime
• Data freeze rules
• “Last sync” steps (if applicable)
• Rollback point (until when is it possible?)
• Hypercare (monitoring, error budget, hotfix window)

Migration from older versions – two proven paths

Path A: Split the risk / Jakarta separately

Teams can reduce risk by first migrating to a current LTS (e.g., 2025.Q1 LTS) and planning the (potentially larger) Jakarta/runtime upgrade only afterward.

Path B: Directly to 2026.Q1 LTS

This path makes sense if you need to modernize your infrastructure anyway and want to make the big leap all at once (including testing and refactoring). 2026.Q1 LTS is officially available; check the release notes and the compatibility matrix.

• The GDPR serves as the foundation for data protection requirements (e.g., access control, data minimization, and the right to erasure and access).
• DORA (EU) 2022/2554 has been in effect since January 17, 2025, and, among other things, makes ICT risk and operational resilience even more critical in regulated environments.

Practical migration tip: Don’t wait until “after go-live” to address compliance. Build requirements directly into the target architecture, logging/monitoring, authorization concept, and operational processes.

A Liferay DXP migration is truly successful when it not only reaches its destination but also ensures long-term upgradeability: a clear LTS strategy, a certified stack, more stable customizations based on Client Extensions, robust testing, and a practical update schedule.