La clé réside dans l'alignement des versions.

La solution la plus simple consiste à mettre à niveau votre environnement CE vers la version 7.4.3.132, la dernière version CE disponible. Cela vous rapproche autant que possible du code source DXP et minimise la complexité de la mise à niveau.

À partir de là, nous visons DXP 2025.Q1.22-lts.

Cette version est :

• La plus proche de CE 7.4.3.132

• La version à support à long terme (LTS) pour 2025

• Le point d'arrivée le plus stable pour la mise à niveau

En choisissant 2025.Q1.22, vous minimisez la dérive du schéma et bénéficiez d'une couverture de support étendue.

 

Chemin n° 1 : mise à niveau dans un espace de travail Liferay

Si votre instance CE est gérée via un espace de travail Liferay, c'est la voie la plus simple.

 

Étape 1 - Mettre à jour le produit Workspace

Dans gradle.properties, modifiez :

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

Cela indique à Blade et Gradle de cibler la version LTS de DXP de Liferay.

Étape 2 - Mettre à jour les dépendances API

Dans chaque fichier build.gradle, remplacez la dépendance du portail release.portal.api par release.dxp.api.

Cela garantit que les futures versions cibleront les API DXP.

À ce stade, vous n'avez pas besoin de tout reconstruire immédiatement. Les artefacts construits avec la version 7.4.3.132 devraient fonctionner avec la version 2025.Q1.22.

Il existe toutefois des exceptions importantes.

Actions manuelles que vous devez effectuer

Ensembles de fragments

Si vous avez des ensembles de fragments :

Vous devez les reconstruire et les redéployer.

Les ensembles de fragments remplacent les JSP. Entre CE 7.4.3.132 et le niveau de correctif DXP représenté par 2025.Q1.22, des modifications JSP ont pu être apportées. Vous devez vous assurer que votre fragment contient le contenu DXP approprié.

Après être passé aux dépendances DXP :

• Nettoyez chaque ensemble de fragments

• Déployez l'artefact reconstruit

Modules qui ne démarrent pas ou ne se résolvent pas

Si un module :

• Ne parvient pas à démarrer

• Ne parvient pas à se résoudre

• génère des erreurs de liaison

• Se comporte de manière inattendue

Procédez comme suit :

1. Nettoyez le module

2. Reconstruisez-le à l'aide des dépendances DXP

3. Redéployez-le

Même si aucune modification n'a été apportée au code.

L'artefact reconstruit régénérera les métadonnées OSGi et alignera les versions des paquets d'importation/exportation sur DXP au lieu de CE.

Étape 3 - Remplacer le bundle

Renommez votre bundle existant :

$ mv bundles bundles-old

Ne supprimez pas l'ancien bundle.

Puis exécutez :

$ blade server init

Cela crée un nouveau répertoire bundles/ ciblant DXP 2025.Q1.22.

Étape 4 - Copier les fichiers requis

À partir de bundles-old, copiez :

• portal-ext.properties

• portal-wizard.properties

• Fichiers de propriétés du client de mise à niveau de la base de données

• Modules personnalisés dans :

osgi/modules

osgi/wars

data/ (si vous utilisez HSQL)

Placez votre clé d'activation DXP dans osgi/modules

Étape 5 - Exécutez la mise à niveau de la base de données

Avant de démarrer Tomcat :

Accédez à tools/portal-tools-db-upgrade-client

Vérifiez :

• URL JDBC

• Nom d'utilisateur/mot de passe

• Pilote

• Toutes les propriétés spécifiques à l'environnement

Exécutez $ ./db_upgrade_client.sh -s

Une fois terminé, vous vous retrouverez dans le shell Gogo ; exécutez les commandes suivantes :

upgrade:executeAll

verify:executeAll

 

Quittez ensuite le shell Gogo.

 

Avertissement important

Une fois la mise à niveau de la base de données terminée, celle-ci est définitivement mise à niveau vers DXP.

CE ne démarrera pas avec cette version. Vous recevrez une erreur indiquant que « la version de la base de données est plus récente que celle du portail ».

Travaillez toujours à partir d'une copie de la base de données.

 

Chemin n° 2 : mise à niveau en dehors d'un espace de travail

Ceci s'applique aux bundles TEST, UAT, PRE, PROD ou autonomes.

 

Étape 1 - Mettre à niveau une copie de la base de données

Ne mettez jamais à niveau votre seule base de données CE.

Restaurez-la en tant que copie dans une nouvelle base de données.

Étape 2 - Installer la nouvelle version DXP 2025.Q1.22

Décompressez DXP dans un répertoire vierge.

Ne remplacez pas un bundle existant.

Placez votre clé d'activation dans osgi/modules

Étape 3 - Copier la configuration et les modules

À partir de CE, copiez :

• portal-ext.properties

• portal-wizard.properties

• Propriétés du client de mise à niveau de la base de données

• Modules personnalisés dans :

osgi/modules

osgi/wars

Assurez-vous que les deux éléments suivants sont présents :

• portal-ext.properties

• les propriétés du client de mise à niveau de la base de données

pointez vers la même base de données copiée.

Étape 4 – Exécuter la mise à niveau de la base de données

À partir de tools/portal-tools-db-upgrade-client, exécutez :

$ ./db_upgrade_client.sh -s

 

Une fois la mise à niveau terminée, vous vous retrouverez dans le shell Gogo. Exécutez les commandes :

upgrade:executeAll

verify:executeAll

 

Quittez ensuite le shell Gogo.

 

Pourquoi l'alignement des versions est-il important ?

Il y a deux raisons essentielles pour lesquelles nous ciblons DXP 2025.Q1.22-lts.

 

Complexité minimale de la mise à niveau

La version 2025.Q1.22 est la version DXP la plus proche de CE 7.4.3.132.

Cela signifie :

• Moins de changements de schéma

• Moins de refactorisations internes

• Moins de risques de rupture des modules personnalisés

• Moins de pression pour la reconstruction

La mise à niveau devient principalement un processus d'évolution du schéma.

 

Il s'agit de la version LTS

2025.Q1.22 est la version à support à long terme (LTS).

Les versions Q2, Q3 et Q4 ne bénéficient que d'un an de support. Si vous effectuez une mise à niveau vers une version trimestrielle non LTS, vous devez immédiatement commencer à planifier votre prochaine mise à niveau DXP.

En ciblant LTS :

• Vous bénéficiez d'une assistance prolongée

• Vous réduisez la fréquence des mises à niveau

• Vous stabilisez votre plateforme

• Vous évitez les changements fréquents de mise à niveau

Vous vous installez sur DXP une fois pour toutes et vous y restez pendant un certain temps.

 

Conclusion

Cette migration n'est pas une réécriture.

Si vous :

1. Mettez à niveau CE vers 7.4.3.132

2. Ciblez DXP 2025.Q1.22-lts

3. Mettez à niveau la base de données

4. Reconstruisez les ensembles de fragments

5. Reconstruisez tous les modules qui fonctionnent mal

La transition est contrôlée et prévisible.

Une fois cette étape franchie, vous disposez de DXP LTS et pouvez travailler à partir d'une base stable et prise en charge.

Vous avez des questions, des problèmes ou des commentaires ? Contactez-moi ci-dessous ou retrouvez-moi sur discuss.liferay.com !

 

Qu'en est-il de la version 2026.Q1.0 ?

Liferay va bientôt sortir la version 2026.Q1.0.

Oui, vous pouvez passer directement de CE à 2026.Q1.0 si vous le souhaitez.

Sachez simplement que cela signifie que vous devrez également gérer la migration vers Jakarta dans le cadre de cette opération.

C'est tout à fait faisable.

Personnellement, je diviserais le travail :

1. Passer de CE à DXP 2025.Q1.22 LTS

2. Stabilisation sur DXP

3. Puis planifier et exécuter la migration vers Jakarta séparément

Il est possible de combiner les deux efforts, mais les séparer réduit la complexité et les risques.

Pour la plupart des équipes, passer d'abord à la version 2025.Q1.22 LTS est la solution la plus claire et la plus contrôlée.