Migrating Liferay Instances - DXP 2026.q1.2-lts

Capabilities
1

I enabled Feature flag LPD-11342 but migrating virtual instances across different Liferay installations fails.

I describe the process for asking for help from those who know and have already used this feature introduced in Liferay DXP 2025.Q2/Portal GA148.

The export phase is successful, but the import phase produces no results.
I don’t know if it’s a problem with the feature, which is in beta, or with the documentation, or just my own mistake.

I followed the documentation here: Migrating Liferay Instances - Liferay Official Documentation - Liferay Learn

  1. The migration attempt occurs between two perfectly identical Liferay DXP 2026.q1.2-lts installations as the bundle is the same copy for both servers.

Portal final build number: 7413
Portal final schema version: 38.2.2

  1. The database server is MySQL 8.0.33 version and hosts the databases of both Liferay installations.

  2. I use the tool to validate database partitions before performing a migration with the following command:
    java -jar com.liferay.portal.tools.db.partition.migration.validator.jar export --company-id 69697099524243 --jdbc-url jdbc:mysql://localhost/lportal_nt27_2026_q1_2 --password *** --user ***
    The command creates the file “20260516183924_export_69697099524243.json”.

  3. I follow the instructions that say: “Execute the command again for the target database.”.
    I chose any company-id already present in the target database with a different company-id.
    java -jar com.liferay.portal.tools.db.partition.migration.validator.jar export --company-id 90256445023424 --jdbc-url jdbc:mysql://localhost/lportal_nt103_2026_q1_2 --password *** --user ***
    The command creates the file “20260517091044_export_90256445023424.json”.

  4. I run the following command in Validation Mode:
    java -jar com.liferay.portal.tools.db.partition.migration.validator.jar validate --source-file 20260516183924_export_69697099524243.json --target-file 20260517091044_export_90256445023424.json

I get the following error:

[ERROR] Module com.liferay.search.experiences.service needs to be installed in the source database before the migration
[WARN] Table fvsactiveentry is not present in the target database
[WARN] Table fvscustomentry is not present in the target database
[WARN] Table fvsentry is not present in the target database
[WARN] Table sxpblueprint is not present in the source database
[WARN] Table sxpelement is not present in the source database
[WARN] Module com.liferay.hello.velocity.web is not present in the target database
[WARN] Module com.liferay.frontend.view.state.service is not present in the target database
[WARN] Module com.liferay.portal.search.elasticsearch.monitoring.web is not present in the source database

  1. I still perform the Database Partition Extraction:

In the Global Menu (Global Menu), navigate to Control Panel → Configuration → System Settings.
Go to Platform → Virtual Instances.
In the Extract Company ID field, enter the standalone partition’s company ID: 69697099524243.

The export creates the database schema with the name “lexported_69697099524243”.

Instead, the documentation says:
“This process creates a new database called lextracted_[companyId] which can be imported in the target Liferay installation to perform the insertion process.”

  1. I still perform the Insert Database Partition phase:

In the Global Menu (Global Menu), navigate to Control Panel → Configuration → System Settings.
Go to Platform → Virtual Instances → Portal Instance Insertion.
Fill the Insert Company ID field with the company ID of the standalone partition.
The ID must be different from any in the target installation.

So I used 69697099524243 in the Insert Company ID field.

Nothing happens.

Thanks in advance for any help.

5 Answers

5
2

Hi @icarrara,

Heads-up first: the learn.liferay.com page on instance migration is out of date.

The actual code uses “export/import” everywhere; the doc says “extract/insert.” Concretely:

Item Docs say Actual (code / Language.properties)
Extracted schema prefix lextracted_[companyId] lexported_[companyId]
Extract config PID …ExtractPortalInstanceConfiguration …ExportPortalInstanceConfiguration
Extract config key extractCompanyId=L"…" exportCompanyId=L"…"
Extract UI section / field (under Virtual Instances) / “Extract Company ID” “Instance Export” / “Export Company ID”
Insert config PID …InsertPortalInstanceConfiguration …ImportPortalInstanceConfiguration
Insert config key insertCompanyId=L"…" importCompanyId=L"…"
Insert UI section / field “Portal Instance Insertion” / “Insert Company ID” “Instance Import” / “Import Company ID”
Rename step lextracted_[id] → lpartition_[id] lexported_[id] → lpartition_[id]

If your .config files used the doc’s names, file install would happily drop them in osgi/configs but the operation components never fire on them — which would match the “nothing happens” symptom.

A few more diagnostic questions:

  1. After you saved the form, did the Instance Import entry disappear from System Settings, or is it still there? The activation code deletes its own configuration when it runs (success or failure). If the entry persists, @Activate never fired. If it disappeared, the operation ran and the result is in the log.

  2. Any log line at the moment you triggered the import — INFO, WARN, ERROR? The operation is mostly silent: on success it logs one INFO line (Portal instance with company ID X imported successfully); on failure it logs one ERROR (Unable to perform operation on portal instance with the exception attached). If nothing appears at that timestamp, the import code didn’t run. If anything appears, please paste it.

  3. Is database.partitioning.enabled=true in portal-ext.properties on the target? The migration feature is database partitioning — each virtual instance lives in its own schema (lpartition_<companyId>), and the import has no meaning without per-schema routing — so the operation throws UnsupportedOperationException immediately when the flag is off.

  4. Does the lexported_<companyId> schema exist on the target’s database server, populated from the source extract? Confirm with SHOW DATABASES LIKE 'lexported\_%'; on the target DB. Note: this copy is not automated — after extraction on the source, you must manually move the lexported_<companyId> schema to the target DB server (e.g. mysqldump on the source → mysql import on the target) before triggering the import. The portal does not transfer schemas across DB servers for you.

  5. Is the target’s default partition already holding a Company row with that companyId? If yes, the operation logs Portal instance with company ID X already exists and silently returns.

  6. What did you do with the validator’s schema-parity errors? The missing sxpblueprint/sxpelement (source) and fvs* (target) tables indicate the two bundles don’t have identical module sets. The import path does not re-check schema parity, so a partition extracted from a mismatched source can import “successfully” but fail at runtime on the first query against the missing tables. Worth aligning modules across both bundles and re-running the validator before retrying.

3

Hello @Jorge.Diaz Thank you so much for your detailed analysis and the corrections you provided.

I’ll proceed with a new attempt based on your updates.

In the meantime, I’ll address one of your points that concerns me most:

  1. What did you do with the validator’s schema-parity errors?

The Liferay DXP server binary code is the same between source and target for the simple reason that I installed the target by copying the source binary.

I don’t understand why they are reported as different.
Do you have any further suggestions on this?

In any case, I’ll update you after my second attempt.

4

For reference, the messages you’re seeing come from com.liferay.portal.tools.db.partition.migration.validator.util.ValidatorUtil: the Table X is not present in the Y database warnings come from _validatePartitionedTables, which does a symmetric diff of the schema’s table list (dbInspector.getTableNames minus control and object tables); the Module X is not present warnings and the Module X needs to be installed in the source database before the migration error come from _validateRelease, which compares the Release_ rows of each side by servletContextName / schemaVersion / verified and escalates a missing .service module to ERROR while leaving non-service modules at WARN.

Dug into the validator code and git history — a couple of things worth sharing:

The fvs* tables (fvsactiveentry, fvscustomentry, fvsentry) come from a module that was removed from the portal two years ago — LPD-25904, May 2024, deleted the whole frontend-view-state app. Since Liferay doesn’t drop tables when a module is removed, the rows just stay on disk. No code in 2026.Q1 reads them anymore, so they’re harmless leftovers; you can DROP them on the target after the migration and nothing will notice.

The presence of those tables tells us something though: at least one of your two installations was upgraded through a pre-2024.Q3 Liferay version — fresh installs of any 2025.Q* or 2026.q1.* bundle don’t create them. So even if the binaries on disk are identical today, the runtime state isn’t, because one has an upgrade history and the other doesn’t.

sxpblueprint / sxpelement are the opposite case — those are current, active entities on master and 2026.q1. The “must be installed on source” ERROR for com.liferay.search.experiences.service is the real blocker in your output: the module is deployed on target but not on source, so the Release_ rows and tables it owns are missing on the source side.

tl;dr — ignore the FVS warning, but deploy the missing search-experiences module on the source side and re-run the validator before the next migration attempt.

5

Hi @Jorge.Diaz , thanks for the further analysis.

The source instance comes from subsequent upgrades starting from Portal CE 7.4.3.88-ga88.
The target instance comes from subsequent upgrades starting from Portal CE 7.4.3.132-ga132.

So I understood that I can ignore the FVS warning.

I still don’t understand what to do to deploy the missing search-experiences module on the source side.

In both source and target instance in portal-ext.properties I have this: enterprise.product.enterprise.search.enabled=false

This is the only thing I added after upgrading both instances to 2026.q1.2-lts.

Can you please help me understand how to deploy the missing search-experiences module on the source side?

6

Hi @icarrara — after double-checking the code, short answer to your direct question: there’s nothing to deploy. The SXP modules ship with the 2026.q1.2-lts bundle on both sides — they either activate at startup or they don’t. The asymmetry you’re seeing in the Release_ table comes from past activations, not from anything missing on disk.

Also a clarification: enterprise.product.enterprise.search.enabled doesn’t gate SXP module activation. It only controls whether Search Experiences appears in the omniadmin product notification banner (EPNManager). So that property isn’t what’s making the Release_ rows diverge.

A few hints:

  1. The validation ERROR exists because import renames lexported_<id> into lpartition_<id>, and since the source has no sxpblueprint / sxpelement tables, the new partition won’t either. On the target, run SELECT COUNT(*) FROM sxpblueprint; SELECT COUNT(*) FROM sxpelement;. If both are 0, SXP isn’t in use and the ERROR is effectively cosmetic. If either is non-zero, align the modules first.

  2. SXP activation is gated by the DXP license bundle, not by that property. In Gogo, lb | grep -i "license.enterprise.app" and lb | grep -i "search.experiences" on both sides will show whether the source even tries to start SXP.

  3. The other WARNs (hello.velocity.web, frontend.view.state.service, portal.search.elasticsearch.monitoring.web) are the same pattern — old or optional modules carried by one upgrade lineage and not the other. None are blocking.

Hope that helps.