Migration Semarchy xDM : méthode et points de vigilance

Rester sur une ancienne version de Semarchy xDM finit par coûter cher : fin du support, correctifs de sécurité manqués, fonctionnalités inaccessibles, et un écart qui rend chaque montée de version suivante plus lourde. Une migration Semarchy xDM bien préparée se passe pourtant sans surprise. Voici la méthode que nous suivons, appuyée sur la documentation officielle de Semarchy (consultée le 11 novembre 2026).

Patch, version mineure, version majeure : ce qui change

Les versions de xDM suivent le format majeure.mineure.correctif. Semarchy distingue des versions dites Mainstream et des versions à support long, dites LTS. La nature de la montée de version change l'ampleur du travail :

• un correctif (patch) ne demande pas de mise à niveau du référentiel ni des data locations, et se défait facilement selon la documentation de l'éditeur ;
• une version mineure ou majeure demande en général la mise à niveau du référentiel (le repository, qui contient les modèles et la configuration) puis celle des data locations (les espaces où les modèles sont déployés et où vivent les données).

Ces deux mises à niveau sont irréversibles. Le seul retour arrière possible est la restauration des sauvegardes. Toute la méthode découle de ce point.

Sauf mention contraire de l'éditeur, le passage d'une version à une autre est direct. Il faut toutefois vérifier, pour votre version de départ et votre version cible, les actions particulières listées par Semarchy.

Étape 1 : préparer

Lire les notes de version

Les notes de version listent les nouveautés, les corrections et surtout les changements de comportement. On les lit avec une question en tête : qu'est-ce qui, dans notre modèle, nos règles, nos applications ou nos intégrations, peut être touché ?

Vérifier la compatibilité

On contrôle les prérequis techniques de la version cible, par exemple les versions de base de données prises en charge. Un changement de prérequis peut imposer une mise à jour de l'infrastructure avant la migration elle-même.

Faire l'inventaire

On recense ce qui doit fonctionner après la migration :

• les modèles et leurs data locations ;
• les applications et les workflows ;
• les flux d'intégration et de publication, en SQL ou par API REST ;
• les traitements planifiés et leurs dépendances ;
• les configurations d'authentification (LDAP, SSO) ;
• les développements spécifiques autour de xDM.

Repérer les actions avant et après migration

Semarchy publie, pour chaque version, des actions à mener avant et après la mise à niveau. Certaines ne concernent que des bases ou des versions de départ précises. Les ignorer peut faire échouer la mise à niveau en cours de route.

Étape 2 : choisir la méthode, en place ou hors place

La documentation de Semarchy décrit deux chemins :

• la mise à niveau en place : la nouvelle version s'installe à la place de l'ancienne et met à niveau les référentiels existants. En cas de problème, on revient à l'état initial en restaurant les sauvegardes des dossiers du serveur et des schémas de base de données ;
• la mise à niveau hors place : on duplique l'environnement et on met à niveau la copie. L'environnement d'origine reste intact.

La méthode en place est plus simple. La méthode hors place offre un retour arrière immédiat, au prix d'une infrastructure à doubler pendant la bascule. Le choix dépend de la politique de votre service informatique et de la tolérance à l'interruption.

Étape 3 : répéter sur un environnement de recette

On ne découvre pas une migration en production. On la répète d'abord sur une copie récente de la production, en suivant le déroulé prévu par l'éditeur :

1. mener les actions préalables ;
2. arrêter les instances du serveur et les connexions ;
3. sauvegarder l'installation : dossiers du serveur, schémas du référentiel et des data locations ;
4. en hors place, dupliquer les schémas de base de données ;
5. installer et configurer la nouvelle version ;
6. démarrer une seule instance ;
7. mettre à niveau le référentiel ;
8. mettre à niveau les data locations ;
9. redémarrer toutes les instances ;
10. mener les actions postérieures.

Cette répétition donne une durée réaliste pour la bascule, et une liste de surprises à régler avant le jour J.

Étape 4 : tester la non-régression

Après la migration de recette, on vérifie que le référentiel se comporte comme avant :

• les règles de qualité rejettent et acceptent les mêmes enregistrements ;
• le rapprochement et la survivance produisent les mêmes golden records sur un jeu de données de référence ;
• les applications s'ouvrent, et les workflows vont au bout ;
• les flux chargent et publient sans erreur, avec les volumes attendus ;
• les droits : chaque rôle voit ce qu'il doit voir, et seulement cela.

Les data stewards participent à ces tests. Ce sont eux qui repèrent le plus vite une fusion qui a changé.

Étape 5 : basculer en production

La bascule se planifie sur un créneau où le référentiel peut être arrêté, avec :

• une communication aux utilisateurs et aux équipes des systèmes connectés ;
• des sauvegardes vérifiées juste avant l'opération ;
• un critère de retour arrière décidé à l'avance : au-delà de quel problème, et à quelle heure, on restaure ;
• une surveillance renforcée des flux et des rejets les jours suivants.

Les points de vigilance

• Les sauvegardes non testées. Une sauvegarde qu'on n'a jamais restaurée n'est pas un plan de retour arrière.
• Les développements autour de xDM. Scripts, appels d'API et vues SQL utilisés par d'autres systèmes doivent faire partie des tests.
• Les règles de rapprochement. Un changement de comportement d'une fonction peut modifier les fusions sans erreur visible.
• L'écart de versions. Plus on attend, plus la liste des actions à mener s'allonge, et plus la migration devient un projet à part entière.

Questions fréquentes

Combien de temps dure une migration Semarchy xDM ?

Cela dépend de l'écart de versions, du nombre de modèles et d'intégrations, et des tests à mener. La répétition en recette donne la durée réelle de la bascule.

Faut-il redéployer les modèles après la migration ?

Cela dépend des versions concernées. Les actions postérieures publiées par Semarchy pour votre version précisent ce qui est nécessaire.

La migration peut-elle se faire dans le cadre d'une TMA ?

Oui. Les correctifs entrent souvent dans la maintenance courante, et une montée de version majeure se traite comme un petit projet. Voir notre article sur la TMA Semarchy xDM.

Vous préparez une montée de version de Semarchy xDM ? Découvrez notre offre MDM Engineering ou contactez-nous.

Source : documentation Semarchy xDM, « Upgrade Semarchy xDM », consultée le 11 novembre 2026.