The key is version alignment.

The smoothest path starts by upgrading your CE environment to 7.4.3.132, the latest available CE release. This positions you as close as possible to the DXP codebase and minimizes upgrade complexity.

From there, we target DXP 2025.Q1.22-lts.

This version is:

• The closest match to CE 7.4.3.132
• The Long Term Support (LTS) release for 2025
• The most stable upgrade landing point

By choosing 2025.Q1.22, you minimize schema drift and gain extended support coverage.

Path #1: Upgrading in a Liferay Workspace

If your CE instance is managed via a Liferay Workspace, this is the cleanest path.

Step 1 - Update the Workspace Product

In gradle.properties, change:

liferay.workspace.product=dxp-2025.q1.22-lts

This tells Blade and Gradle to target the Liferay LTS version of DXP.

Step 2 - Update API Dependencies

In every build.gradle file, change the portal dependency from release.portal.api to release.dxp.api.

This ensures future builds target DXP APIs.

At this point, you do not need to rebuild everything immediately. Artifacts built against 7.4.3.132 should run on 2025.Q1.22.

However, there are important exceptions.

Manual Actions You Must Handle

Fragment Bundles

If you have fragment bundles:

You must rebuild and redeploy them.

Fragment bundles override JSPs. Between CE 7.4.3.132 and the DXP patch level represented by 2025.Q1.22, there may have been JSP changes, you should ensure that your fragment has the appropriate DXP fragment content.

After switching to DXP dependencies:

• Clean build each fragment bundle
• Deploy the rebuilt artifact

Modules That Fail to Start or Resolve

If any module:

• Fails to start
• Fails to resolve
• Throws linkage errors
• Behaves unexpectedly

Do this:

1. Clean the module
2. Rebuild it using the DXP dependencies
3. Redeploy it

Even if no code changes were made.

The rebuilt artifact will regenerate OSGi metadata and align import/export package versions to target DXP instead of CE.

Step 3 - Replace the Bundle

Rename your existing bundle:

$ mv bundles bundles-old

Do not delete the old bundle.

Then run:

$ blade server init

This creates a new bundles/ directory targeting DXP 2025.Q1.22.

Step 4 - Copy Required Files

From bundles-old, copy:

• portal-ext.properties
• portal-wizard.properties
• DB upgrade client property files
• Custom modules in:

osgi/modules
osgi/wars
data/ (if using HSQL)

Place your DXP activation key in osgi/modules

Step 5 - Run the Database Upgrade

Before starting Tomcat:

Navigate to tools/portal-tools-db-upgrade-client

Verify:

• JDBC URL
• Username/password
• Driver
• All environment-specific properties

Run $ ./db_upgrade_client.sh -s

When finished, you'll end in the Gogo shell; execute the following commands:

upgrade:executeAll
verify:executeAll

Then exit the Gogo shell.

Always work from a database copy.

Path #2: Upgrading Outside of a Workspace

This applies to TEST, UAT, PRE, PROD, or standalone bundles.

Step 1 - Upgrade a Database Copy

Never upgrade your only CE database.

Restore it as a copy to a new database.

Step 2 - Install Fresh DXP 2025.Q1.22

Explode DXP into a clean directory.

Do not overwrite an existing bundle.

Place your activation key into osgi/modules

Step 3 - Copy Configuration and Modules

From CE, copy:

• portal-ext.properties
• portal-wizard.properties
• DB upgrade client properties
• Custom modules in:

osgi/modules
osgi/wars

Ensure both:

• portal-ext.properties
• DB upgrade client properties

point to the same copied database.

Step 4 – Run DB Upgrade

From tools/portal-tools-db-upgrade-client run:

$ ./db_upgrade_client.sh -s

When the upgrade completes, you'll end up in the Gogo shell. Execute the commands:

upgrade:executeAll
verify:executeAll

Then exit the Gogo shell.

Why Version Alignment Matters

There are two critical reasons we target DXP 2025.Q1.22-lts.

Minimized Upgrade Complexity

2025.Q1.22 is the closest DXP release to CE 7.4.3.132.

That means:

• Fewer schema changes
• Fewer internal refactors
• Lower risk of custom module breakage
• Less rebuild pressure

The upgrade becomes primarily a schema evolution process.

It Is the LTS Release

2025.Q1.22 is the Long Term Support (LTS) release.

Q2, Q3, and Q4 releases only receive one year of support. If you upgrade to a non-LTS quarterly release, you must immediately begin planning your next DXP upgrade.

By targeting LTS:

• You gain extended support
• You reduce upgrade frequency
• You stabilize your platform
• You avoid upgrade churn

You land on DXP once and stay there for a while.

Final Thoughts

This migration is not a rewrite.

If you:

1. Upgrade CE to 7.4.3.132
2. Target DXP 2025.Q1.22-lts
3. Upgrade the database
4. Rebuild fragment bundles
5. Rebuild any misbehaving modules

The transition is controlled and predictable.

After that, you are on DXP LTS and operating from a stable, supported foundation.

Questions, problems, or comments? Hit me up below or find me on discuss.liferay.com!

What About 2026.Q1.0?

Liferay will be releasing 2026.Q1.0 soon.

Yes, you can go directly from CE to 2026.Q1.0 if you’d like.

Just understand that doing so means you’ll also need to handle the Jakarta migration as part of that effort.

It’s completely doable.

Personally, I would split the work:

1. Move from CE -> DXP 2025.Q1.22 LTS
2. Stabilize on DXP
3. Then plan and execute the Jakarta migration separately

Combining both efforts is possible, but separating them reduces complexity and risk.

For most teams, landing on the 2025.Q1.22 LTS release first is the cleaner and more controlled path.