Guides

Migration Sitecore : guide étape par étape de XP vers XM Cloud

Jean-Nicolas GauthierDernière mise à jour:

Partenariat Sengo et Sitecore, format vertical

En bref. Passer de Sitecore XP à SitecoreAI (anciennement XM Cloud) se fait en cinq phases : évaluation, architecture, construction, exploitation en parallèle et bascule. Pour une plateforme d'entreprise de taille moyenne, prévoyez de 9 à 14 mois; les grandes plateformes multisites peuvent dépasser 18 mois. L'essentiel de l'effort va à la reconstruction des rendus en composants Next.js, à la refonte des intégrations et à la migration du contenu en plusieurs passes.

Mise à jour d'octobre 2026. Sitecore a lancé SitecoreAI en novembre 2025 comme évolution de XM Cloud. Lisez donc « XM Cloud » dans ce guide comme SitecoreAI. Cette mise à jour ajoute un échéancier par phase, les pièges cachés, un plan de 90 jours et une FAQ. Pour valider votre propre parcours, commencez par notre audit Sitecore gratuit.

La migration de Sitecore de XP vers XM Cloud est désormais la voie de modernisation la plus courante pour les grandes organisations utilisant la pile sur site de Sitecore. Sitecore a clairement défini sa stratégie : XM Cloud est l'avenir, et le support étendu pour XP ne durera pas indéfiniment. Les organisations qui retardent leur migration Sitecore font face à des coûts de maintenance croissants, à une diminution des bassins de talents familiers avec l'architecture héritée, et à des écarts grandissants entre leurs capacités et ce que l'écosystème Sitecore moderne offre.

  Partenariat Sengo et Sitecore, format vertical

Pourquoi migrer vers XM Cloud?

XM Cloud offre plusieurs avantages architecturaux par rapport à XP. C'est une plateforme SaaS entièrement gérée : plus besoin de gestion d'infrastructure, de correctifs ou de cycles de mise à niveau. L'architecture headless avec la prise en charge de Next.js permet le développement front-end moderne et la livraison mise en cache en périphérie. L'éditeur visuel Pages offre aux marketeurs une création de pages par glisser-déposer en plus du contenu headless. Depuis novembre 2025, SitecoreAI réunit la gestion de contenu, les données clients, la personnalisation et la recherche dans une seule plateforme, avec un Agentic Studio d'agents IA qui comprend des agents d'outillage de migration.

D'un point de vue commercial, les organisations qui effectuent la migration de Sitecore vers XM Cloud visent généralement moins de gestion d'infrastructure, un délai de mise sur le marché plus rapide pour les modifications de contenu et une amélioration du recrutement de développeurs (les développeurs JavaScript modernes préfèrent Next.js au .NET MVC hérité). Chez Sengo, notre équipe, qui compte une double reconnaissance MVP Sitecore, a accompagné de nombreux clients d'entreprise dans cette transition. Ce guide reprend la méthodologie que nous avons affinée au cours de ces missions.

Évaluation préalable à la migration

Toute migration Sitecore réussie commence par une évaluation approfondie de ce que vous migrez. Ignorer cette étape est la principale cause des dépassements de budget et des retards dans les projets de migration.

Inventaire de contenu. Documentez tous les types de contenu, modèles et rendus dans votre instance Sitecore XP actuelle. Identifiez le nombre d'éléments de contenu existants, comment ils sont structurés dans l'arborescence de contenu, et quels modèles ils utilisent. Cartographiez les ressources de la médiathèque et leurs références. Cet inventaire détermine la portée de votre effort de migration de contenu.

Audit de personnalisation. Cataloguer tout le code personnalisé : pipelines, gestionnaires d'événements, champs personnalisés, actions de workflow, et intégrations de modules tiers. Pour chaque personnalisation, déterminer s'il existe un équivalent dans XM Cloud, s'il doit être reconstruit différemment, ou s'il peut être éliminé. XM Cloud ne prend pas en charge les pipelines .NET personnalisés comme le fait XP. Ainsi, chaque personnalisation côté serveur nécessite une stratégie de migration.

Mappage d'intégration. Énumérez tous les systèmes externes connectés à votre instance Sitecore : CRM, ERP, DAM, automatisation du marketing, analyse, recherche et CDN. Documentez le fonctionnement de chaque intégration (API, synchronisation de base de données, connecteur personnalisé) et si le modèle d'intégration changera dans l'architecture XM Cloud. De nombreuses intégrations passeront de modèles côté serveur à des modèles côté client ou des fonctions périphériques.

Revue de la personnalisation et de l'analyse. Si vous utilisez les règles d'analyse et de personnalisation xDB intégrées de Sitecore, ces composants n'existent pas dans XM Cloud. Ils migrent vers Sitecore CDP et Personalize, qui sont des produits distincts avec des architectures différentes. Planifiez cette transition tôt : elle affecte à la fois les coûts de licence et le calendrier de mise en œuvre.

Sengo's Service d'audit Sitecore fournit une évaluation pré-migration structurée qui couvre les quatre dimensions. Le résultat est une feuille de route de migration détaillée avec des estimations d'effort, des domaines de risque et une séquence recommandée.

Parcours de migration : direct vs hybride

Il existe deux approches principales pour la migration de Sitecore de XP vers XM Cloud : une bascule directe et une approche hybride progressive. Le choix idéal dépend de la complexité de votre site, de votre tolérance au risque et de vos exigences de continuité des activités.

Migration directe implique la reconstruction du front-end en Next.js à l'aide du Content SDK de Sitecore (le SDK officiel de SitecoreAI; JSS 22 arrive en fin de vie en juin 2026), la migration du contenu vers XM Cloud et le basculement complet. Cette approche est la plus adaptée aux organisations dont les sites sont relativement simples (moins de 50 modèles, peu de code personnalisé) et dont les équipes sont à l'aise avec une transition nette. L'avantage est la simplicité : vous vous retrouvez avec une architecture entièrement moderne sans maintenir deux systèmes. Le risque est que tout doit fonctionner au lancement, laissant moins de place à la validation progressive.

Migration hybride par phases exécute les deux systèmes en parallèle pendant la transition. Vous pourriez migrer d'abord les pages marketing vers XM Cloud tout en gardant temporairement la fonctionnalité d'application complexe sur XP. Un proxy inverse achemine le trafic entre les deux systèmes en fonction des modèles d'URL. Cette approche réduit le risque de mise en production car vous migrez section par section, en validant chaque section avant de passer à la suivante. Cependant, elle augmente la complexité à court terme et nécessite la maintenance des deux environnements.

D'après notre expérience, la plupart des projets de migration Sitecore d'entreprise bénéficient de l'approche hybride. La possibilité de migrer de manière incrémentielle, en commençant par les sections à plus forte valeur et à plus faible risque, donne confiance aux équipes et rend les progrès visibles aux parties prenantes. La migration directe fonctionne bien pour les sites plus petits ou les refontes complètes où l'ancienne architecture n'offre rien qui vaille la peine d'être préservé.

Choisir l'approche : transposer, réarchitecturer ou remplacer

Avant de choisir un mode de bascule, décidez quelle part de l'implantation actuelle vous conservez.

  • Transposer. Déplacer les modèles et les composants avec le moins de changements possible. C'est l'option la plus rapide, mais elle transporte la dette de conception et de code vers la nouvelle plateforme.
  • Réarchitecturer. Garder Sitecore, mais repenser le modèle de contenu, les composants et les intégrations pour une diffusion headless. C'est le choix le plus courant pour les grandes plateformes.
  • Remplacer. Quitter Sitecore pour une autre plateforme comme Contentful, Optimizely CMS (SaaS), Storyblok ou Kentico. Utilisez la même évaluation pour comparer les options avant de vous engager.

Échéancier réaliste par phase

Les présentations des éditeurs évoquent souvent 4 à 6 mois. Pour une plateforme d'entreprise de taille moyenne, 9 à 14 mois est un plan plus réaliste, et les grandes plateformes multisites peuvent dépasser 18 mois. Ce sont des fourchettes typiques; votre périmètre, le nombre d'intégrations et votre équipe déterminent où vous vous situez.

PhaseFourchette typiqueContenu
Évaluation2 à 6 semainesInventaire du contenu, des personnalisations, des intégrations et des flux éditoriaux
Architecture et planification3 à 8 semainesModèle de contenu cible, carte des composants, modèles d'intégration et carnet de travail
Construction et refonte4 à 9 moisComposants Next.js, intégrations, recherche, formulaires et passes de migration du contenu
Exploitation en parallèle4 à 8 semainesLes deux plateformes en ligne pendant que les sections migrent et sont validées
Bascule et mise hors service2 à 6 semainesMigration delta finale, changement DNS, surveillance et retrait de XP

Deux postes manquent souvent aux plans : prévoyez 3 à 6 semaines de refonte par intégration majeure, et 2 à 4 semaines pour ajuster les règles de Personalize après le lancement.

À titre de comparaison, une mise à niveau est plus courte qu'une migration. Pour la Commission de la construction du Québec (CCQ), Sengo a dirigé la mise à niveau de Sitecore 9 à 10, ainsi que de Coveo et de Node.js, en six mois (lire l'histoire de la CCQ). Changer de plateforme ajoute la reconstruction, la migration du contenu et l'exploitation en parallèle à ce type de travail.

Processus de migration du contenu

La migration de contenu est généralement la phase la plus longue d'un projet de migration Sitecore. Le défi n'est pas seulement de déplacer les données, mais de transformer le contenu de la structure arborescente de XP vers le modèle de contenu basé sur des composants de XM Cloud.

Étape 1 : Conception du modèle de contenu. Avant de migrer quoi que ce soit, concevez le modèle de contenu cible dans XM Cloud. Mappez les modèles XP aux composants et aux modèles de données XM Cloud. Identifiez où les structures de contenu doivent changer : par exemple, les champs de niveau de page XP peuvent devenir des sources de données de niveau composant dans XM Cloud. Cette étape nécessite une collaboration entre les stratèges de contenu et les développeurs.

Étape 2 : Extraction automatisée. Utilisez les outils de sérialisation de Sitecore (Sitecore CLI ou des outils tiers comme Unicorn) pour extraire les éléments de contenu de XP au format YAML ou JSON. Filtrez les éléments système, les modèles inutilisés et le contenu orphelin. L'objectif est d'obtenir un jeu de données propre représentant uniquement le contenu que vous avez l'intention de migrer.

Étape 3 : Transformation du contenu. Scripts pour transformer le contenu extrait dans le format XM Cloud cible. Cela implique la restructuration des données, la cartographie des types de champs, la résolution des liens internes et la gestion des références médias. Portez une attention particulière aux champs de texte enrichi : les liens internes et les références médias nécessitent souvent une réécriture d'URL. De plus, le contenu multilingue exige une gestion minutieuse pour maintenir les versions linguistiques et les règles de repli.

Étape 4 : Importation et validation. Importer le contenu transformé dans XM Cloud en utilisant Sitecore CLI ou API de gestion de contenu. Exécutez des vérifications de validation automatisées : vérifiez si le nombre d'éléments correspond, si les liens sont corrects, si les ressources multimédias se chargent et si les versions linguistiques sont complètes. La vérification manuelle ponctuelle par les éditeurs est essentielle : les outils automatisés détectent les problèmes structurels, mais pas les problèmes de qualité du contenu.

Étape 5 : Raffinement itératif. Planifiez plusieurs passes de migration. La première passe révèle les problèmes de transformation, les mappages manquants et les cas limites. Affinez vos scripts, corrigez les problèmes et réexécutez. La plupart des projets nécessitent 3 à 5 passes de migration avant d'obtenir des résultats clairs. La dernière passe de migration a lieu pendant la fenêtre de mise en production.

Refactorisation du code pour le headless

La phase de refactorisation du code d'une migration Sitecore est celle où l'architecture change fondamentalement. XP utilise des rendus .NET MVC côté serveur : contrôleurs, vues et modèles qui s'exécutent sur le serveur Sitecore. XM Cloud utilise une architecture headless où le front-end est une application Next.js séparée qui récupère le contenu via l'API Layout Service de Sitecore.

Conversion de rendu. Chaque rendu XP nécessite un composant Next.js correspondant. Mappez chaque rendu MVC à un composant JSS React. La logique de rendu passe du code côté serveur C# au code JavaScript/TypeScript côté client. Les données qui étaient accessibles via l'API .NET de Sitecore sont maintenant récupérées via le Layout Service ou les points de terminaison GraphQL. C'est souvent la partie la plus laborieuse de la migration Sitecore.

Migration de la logique métier. Les pipelines personnalisés, les gestionnaires d'événements et les tâches planifiées dans XP n'ont pas d'équivalent direct dans XM Cloud. La logique métier doit être déplacée vers l'un des trois emplacements : les routes d'API Next.js (pour la logique au moment de la requête), les fonctions edge (pour le traitement critique en matière de performance) ou les services externes/webhooks (pour le traitement en arrière-plan). La prise en charge des webhooks par Sitecore dans XM Cloud permet des architectures pilotées par les événements qui remplacent de nombreux modèles basés sur des pipelines.

Implémentation de la recherche. Si votre site XP utilise les index Solr ou Azure Search intégrés de Sitecore, ceux-ci doivent être remplacés dans XM Cloud. Les options incluent Sitecore Search (le produit composable), Coveo, Algolia ou des implémentations de recherche personnalisées. La structure de l'index de recherche, les facettes et la logique des requêtes doivent tous être repensés pour l'architecture headless.

Gestion des formulaires. Les formulaires Sitecore de XP ne migrent pas directement vers XM Cloud. Remplacez-les par Sitecore Forms en tant que service composable, ou intégrez des solutions de formulaires tierces. Toutes les données des formulaires et la logique de soumission devront être réimplémentées.

Tout au long du processus de refactoring, maintenez un document de mappage qui suit chaque composant XP et son équivalent XM Cloud. Ce document devient la liste de contrôle des tests d'acceptation et garantit que rien n'est oublié pendant la migration.

Pièges cachés à prévoir

  • Repli linguistique. Les règles de repli se comportent autrement quand le contenu est diffusé en headless. Testez chaque langue explicitement, y compris le contenu en français canadien.
  • Les URL des médias changent. Les liens de la médiathèque changent de forme : vérifiez le texte enrichi, les redirections et les références externes.
  • Données de Sitecore Forms. Les formulaires et leurs soumissions enregistrées ne migrent pas proprement. Exportez les données à conserver avant la bascule.
  • Moment de publication. La publication événementielle change le moment où le contenu apparaît en ligne. Vérifiez les publications planifiées et les règles de cache.
  • Modèle budgétaire. Passer des licences et des serveurs à un abonnement déplace les dépenses du CapEx vers l'OpEx. Modélisez tôt le coût total de possession sur 3 ans pour les finances.
  • Retour arrière. Gardez XP en lecture seule pendant au moins 30 jours après la bascule avant de le mettre hors service.

Liste de contrôle de mise en production pour la migration Sitecore

La phase de mise en production d'une migration Sitecore nécessite une planification méticuleuse. Manquer une étape à ce niveau peut entraîner des interruptions de service, des expériences brisées ou des dommages au référencement. Utilisez cette liste de contrôle pour assurer une transition harmonieuse de XP à XM Cloud.

Avant la mise en production (2 semaines avant) :

  • Compléter la dernière exécution de migration de contenu et valider tous les éléments
  • Exécuter les tests de régression complets dans l'environnement XM Cloud
  • Vérifier que toutes les intégrations (CRM, CDP, analytique, recherche) sont fonctionnelles
  • Implémenter les redirections 301 pour tout changement de structure d'URL
  • Tester le contenu multilingue et le routage des locales
  • Valider les sitemaps XML et la configuration robots.txt
  • Tester la charge du front-end XM Cloud + Next.js sous le trafic attendu
  • Informer l'équipe de contenu des nouveaux flux éditoriaux dans Pages

Jour de mise en production :

  • Exécuter la migration du contenu delta final (changements depuis la dernière exécution complète)
  • Mettre à jour le DNS ou le routage CDN pour pointer vers le nouveau front-end
  • Vérifier les certificats SSL et les redirections HTTPS
  • Surveiller les journaux d'erreurs, les métriques de performance et la console de recherche
  • Tester les parcours utilisateur critiques : page d'accueil, pages clés, formulaires, recherche
  • Confirmer que le suivi analytique se déclenche correctement sur toutes les pages

Après la mise en production (2 premières semaines) :

  • Surveiller les classements de recherche et les erreurs d'exploration dans Google Search Console
  • Suivre les Core Web Vitals pour les régressions de performance
  • Résoudre tout problème de contenu signalé par l'équipe éditoriale
  • Valider que les règles de personnalisation se déclenchent correctement dans CDP/Personalize
  • Désactiver l'environnement XP une fois stable (conserver les sauvegardes)

Une migration Sitecore réussie n'est pas qu'un exercice technique : c'est un projet de changement organisationnel. Les équipes de contenu ont besoin de formation sur la nouvelle expérience éditoriale, les développeurs ont besoin d'une initiation à l'architecture headless, et les parties prenantes ont besoin de visibilité sur les progrès et les risques. Chez Sengo, nous gérons cela de bout en bout : de l'évaluation préalable à la migration jusqu'au support post-lancement et à l'optimisation.

Un plan de 90 jours pour démarrer

Jours 1 à 30 : dresser le portrait. Réalisez un audit structuré du contenu, des personnalisations, des intégrations et des flux éditoriaux. Jumelez-le à un modèle de coûts sur 3 ans qui compare le maintien sur XP, le passage à SitecoreAI et au moins une autre plateforme.

Jours 31 à 60 : choisir la forme. Choisissez entre transposer, réarchitecturer ou remplacer. Décidez si vous adoptez toute la suite SitecoreAI ou conservez des outils que vous utilisez déjà, comme Coveo pour la recherche. Calez l'échéancier sur les jalons d'affaires : campagnes, fins de période financière ou audits.

Jours 61 à 90 : confirmer l'équipe. Désignez l'équipe de base, informez le comité directeur et menez un sprint d'architecture qui produit le carnet de travail détaillé, le budget et le registre des risques.

Questions fréquentes

Combien de temps dure une migration de Sitecore XP vers SitecoreAI?

Pour une plateforme d'entreprise de taille moyenne, prévoyez de 9 à 14 mois entre l'évaluation et la mise hors service de XP. Les grandes plateformes multisites avec beaucoup d'intégrations peuvent dépasser 18 mois. Ce sont des fourchettes typiques, pas une soumission : le volume de contenu, le code personnalisé et le nombre d'intégrations déterminent votre échéancier réel.

Qu'est-il arrivé à XM Cloud?

Sitecore a lancé SitecoreAI le 4 novembre 2025 comme évolution de XM Cloud. La plateforme réunit la gestion de contenu, les données clients, la personnalisation et la recherche. Selon Sitecore, les clients XM Cloud existants passent à SitecoreAI sans migration (annonce de Sitecore, en anglais).

Faut-il passer de JSS au Content SDK?

Oui, si vous êtes sur SitecoreAI. Le Content SDK est le SDK officiel de SitecoreAI, et Sitecore demande aux utilisateurs de JSS sur SitecoreAI d'y passer avant la fin de vie de JSS 22 en juin 2026 (Sitecore KB1004260, en anglais).

Jusqu'à quand Sitecore XP est-il soutenu?

Cela dépend de la version. Le soutien étendu de XP 10.0 et 10.1 prend fin le 31 décembre 2026, celui de 10.2 le 31 décembre 2027, de 10.3 le 31 décembre 2028 et de 10.4 le 31 décembre 2030. XP 10.5, sorti en août 2026, a un soutien étendu jusqu'au 31 décembre 2032. Depuis juin 2026, les mises à jour de sécurité en soutien étendu sont une option payante (Sitecore KB0641167, en anglais).

Peut-on garder notre recherche ou nos autres outils actuels?

Oui. Beaucoup d'équipes gardent les outils qu'elles utilisent déjà, comme Coveo pour la recherche, au lieu d'adopter toute la suite. Chaque outil conservé demande quand même du travail d'intégration : prévoyez 3 à 6 semaines par intégration majeure.

Sources

Avant de planifier, vérifiez si votre organisation est prête avec notre liste de vérification prémigration, ou comparez les options avec notre cadre décisionnel pour un CMS headless.

Réservez une évaluation de migration

Votre Sitecore mérite un deuxième avis.

Audit Sitecore gratuit dirigé par un double Sitecore MVP. Vérifiez les dates de soutien de votre version et comparez rester sur XP, mettre à niveau ou passer à SitecoreAI.

Demandez votre audit gratuit