Sitecore 10 vers Sitecore AI : le chemin de migration que personne n'explique

Point de depart : la place de Sitecore 10 a l'ere de Sitecore AI

Sitecore 10 a été la dernière version majeure de la plateforme classique et monolithique Sitecore Experience Platform avant que l'entreprise ne s'engage pleinement dans un avenir composable et axé sur le SaaS. Il utilise toujours Solr, s'attend toujours à une empreinte Windows et SQL Server, et considère toujours la personnalisation comme une fonctionnalité pilotée par xDB. Sitecore AI, en revanche, réside dans XM Cloud, Sitecore Search, Sitecore Personalize, Sitecore CDP et Sitecore Content Hub ONE. La couche d'intelligence n'est plus une fonctionnalité ; c'est la plateforme.

Cela signifie qu'une migration de Sitecore 10 vers Sitecore AI n'est pas une mise à niveau. C'est une migration technologique. Vos modèles, rendus, pipelines, extensions xDB personnalisées et votre infrastructure sur site ne survivront pas à la transition intacts. De plus, les hypothèses du modèle de données intégrées à votre solution Sitecore 10 correspondent rarement à ce qu'en attend XM Cloud. Reconnaître cela tôt recadre le projet d'une “ correction et déploiement ” à une “ conception et reconstruction ”, ce qui est la seule approche honnête.

Le chemin de migration que Sitecore n'expose pas clairement

Les propres directives de Sitecore se concentrent sur les outils : les scripts de migration de XM vers XM Cloud, les formats de sérialisation de contenu, les SDK headless. Ce qu'elles énoncent rarement, c'est la séquence, le personnel ou la durée réaliste. En pratique, une migration de Sitecore 10 vers Sitecore AI suit cinq étapes que la plupart des équipes découvrent à leurs dépens.

Les cinq étapes sont l'évaluation, la planification, la révision, l'exécution parallèle et le basculement. Chaque étape a une durée typique pour une entreprise du marché intermédiaire : l'évaluation prend de 2 à 4 semaines, la planification prend de 3 à 6 semaines, la révision consomme de 4 à 9 mois selon la profondeur d'intégration, l'exécution parallèle dure de 4 à 8 semaines, et le basculement plus la mise hors service s'étendent sur 2 à 6 semaines. En additionnant le tout, une migration réaliste de Sitecore 10 vers Sitecore AI se situe entre 9 et 14 mois, et non les 4 à 6 mois qu'un argumentaire commercial pourrait suggérer.

Etape 1 : evaluer votre instance Sitecore 10 actuelle

Avant de dessiner le moindre diagramme d'architecture, vous avez besoin d'un inventaire brutalement honnête. La plupart des équipes sautent cette étape et le paient plus tard. L'évaluation doit couvrir quatre dimensions : le contenu, le code, les intégrations et les flux de travail éditoriaux. Chacune recèle des surprises.

Côté contenu, comptez vos modèles, la profondeur de votre héritage, vos valeurs par défaut et vos modèles de branche. Identifiez le nombre de champs réellement utilisés par rapport au nombre de champs obsolètes. Dans une instance Sitecore 10 classique, environ 30 à 40 % des champs n'ont pas été modifiés depuis deux ans. C'est une dette de migration. Côté code, cataloguez chaque pipeline personnalisé, chaque gestionnaire d'événements, chaque script PowerShell Sitecore et chaque module Helix. XM Cloud n'autorise pas le code côté serveur de la même manière, donc chaque processeur personnalisé a besoin d'un nouveau lieu, généralement dans une fonction middleware Next.js ou une fonction Edge.

Les intégrations sont là où l'évaluation devient pénible. Dressez la liste de tous les systèmes qui communiquent avec Sitecore : votre CRM, votre automatisation du marketing, votre DAM, votre plateforme de commerce, votre outil de traduction, vos analyses. Pour chacun d'eux, documentez la direction, le protocole et le volume de données. Cette liste devient votre backlog de retravail. Une solide Audit Sitecore surgie typiquement 15 à 25 points d'intégration dans un parc de taille moyenne, et au moins un tiers d'entre eux reposent sur des hypothèses qui ne tiennent pas dans XM Cloud.

Etape 2 : planifier votre strategie de migration de contenu

La migration de contenu est l'étape que tout le monde sous-estime. La migration de Sitecore 10 vers Sitecore AI ne peut pas être une copie d'élément un-pour-un car le modèle de contenu sous-jacent doit changer. XM Cloud privilégie des modèles plats et adaptés au headless ; Sitecore 10 a souvent des modèles de page profondément imbriqués avec des dizaines de champs liés à la présentation. Vous devez d'abord redessiner le modèle, puis mapper les anciens éléments dans la nouvelle structure.

Planifiez trois parcours de contenu en parallèle. Premièrement, un parcours automatisé pour le contenu structuré à haut volume tel que les pages produits ou les articles d'actualité. Deuxièmement, un parcours manuel pour les pages principales, les pages de destination de campagnes et tout ce qui a une mise en page personnalisée. Troisièmement, un parcours d'archivage pour le contenu que vous ne migrerez pas du tout. Soyez impitoyable sur le troisième parcours. Supprimer 25 % du corpus économise généralement deux mois de temps de projet et améliore la pertinence de Sitecore Search après le lancement car l'IA ne s'entraîne pas sur du matériel obsolète.

Utilisez le format de sérialisation de contenu de Sitecore et les outils de migration de XM Cloud, mais ne leur faites pas aveuglément confiance. Ils gèrent bien les éléments, mais mal les médias. Les champs de texte enrichi avec des balises de média intégrées se cassent souvent, et les champs de liens pointant vers des éléments supprimés disparaissent silencieusement. Créez un script de validation qui compare les comptes d'éléments et les hachages de champs après chaque exécution à blanc.

Etape 3 : refaire les integrations pour Sitecore AI

C'est là que le budget se dissipe. Toutes les intégrations qui reposaient auparavant sur l'API d'éléments Sitecore, le xDB ou un point de terminaison SOAP personnalisé doivent être déplacées vers le GraphQL Edge de XM Cloud, les API REST de Sitecore CDP ou des flux pilotés par des webhooks. Les refontes sont rarement un remplacement identique ; il s'agit d'une refonte.

Prenons comme exemple une synchronisation CRM typique. Dans Sitecore 10, vous pourriez envoyer des mises à jour de contacts xDB à Salesforce via un pipeline personnalisé. Dans Sitecore AI, le flux équivalent passe par Sitecore CDP, et le modèle de données est différent. CDP utilise des profils d'invités avec des attributs d'extension ; xDB utilisait des facettes. Mapper ces concepts de manière propre demande un travail de conception, pas seulement de codage. Prévoyez 3 à 6 semaines par intégration majeure, et supposez que deux ou trois intégrations nécessiteront une discussion architecturale complète avec l'équipe propriétaire.

C'est aussi le moment de se demander si chaque intégration doit survivre. Si un système est à peine utilisé, retirez-le. Si deux systèmes font des choses similaires, consolidez-les. Une migration de Sitecore 10 vers Sitecore AI est l'excuse la plus propre que vous obtiendrez jamais pour simplifier votre parc informatique, alors utilisez-la. Notre service de migration CMS et DXP permet généralement de réduire le nombre d'intégrations de 20 à 30 % à ce stade, ce qui se répercute sur des coûts d'exploitation inférieurs pendant des années.

Etape 4 : exploitation en parallele et tests

Une fois le nouvel environnement XM Cloud construit et le contenu migré, vous devez exécuter les deux plateformes côte à côte. Sauter l'exécution parallèle est la principale cause des échecs de migration Sitecore que j'ai constatés. Pourtant, cela n'apparaît presque jamais dans les échéanciers des fournisseurs car cela ressemble à du temps perdu. Ce n'est pas du temps perdu ; c'est une assurance.

Lors de l'exécution parallèle, dirigez un petit pourcentage du trafic vers la nouvelle plateforme via un fractionnement CDN ou un indicateur de fonctionnalité. Surveillez quatre signaux : correction du rendu, pertinence de la recherche, décisions de personnalisation et continuité analytique. La personnalisation est la partie la plus délicate car Sitecore Personalize évalue les règles différemment du moteur de règles hérité de Sitecore 10. Attendez-vous à une période d'ajustement de 2 à 4 semaines avant que la nouvelle plateforme ne produise les mêmes résultats que l'ancienne.

Testez également l'expérience éditoriale. Les auteurs qui utilisent Sitecore 10 depuis des années résisteront au nouvel éditeur de pages XM Cloud. Organisez des ateliers pratiques pendant la période de fonctionnement parallèle, pas après la bascule. Les auteurs qui sont confiants dès le premier jour protègent le lancement ; ceux qui ne le sont pas inonderont votre file d'attente de support.

Etape 5 : bascule et mise hors service

La bascule proprement dite est anticlimatique si les étapes précédentes ont été bien réalisées. Vous figez le contenu dans Sitecore 10, effectuez une dernière migration incrémentale, redirigez le DNS ou l'origine du CDN, et surveillez. L'ensemble de la période dure généralement de 4 à 8 heures pour un site de taille moyenne. Le risque ne réside pas dans la bascule elle-même ; il réside dans les 72 heures qui suivent, lorsque les classements de recherche, le préchauffage de la personnalisation et les habitudes éditoriales entrent tous en collision.

Planifiez le démantèlement avec soin. N'éteignez pas Sitecore 10 le lendemain de la bascule. Gardez-le en lecture seule pendant au moins 30 jours afin de pouvoir récupérer du contenu ou comparer les comportements. Après 30 jours, archivez les bases de données, prenez un instantané des VM, et ce n'est qu'alors que vous pourrez libérer les licences. D'après mon expérience, les clients qui ont précipité le démantèlement ont fini par reconstruire des données de campagne perdues à partir de sauvegardes d'e-mails, ce qui n'est pas une histoire que vous voudrez raconter à votre directeur marketing.

Pièges cachés que Sitecore ne mentionnera pas

Enfin, voici les choses qui n'arrivent jamais dans le journal officiel Documentation Sitecore mais assurez-vous toujours qu'il soit documenté dans le postmortem. Premièrement, le repli linguistique se comporte différemment dans XM Cloud ; si vous vous fiez au repli en chaîne pour le français canadien ou d'autres locales, testez-le explicitement. Deuxièmement, les URL des médias changent de forme, ce qui brise tous les modèles d'e-mails et toutes les références codées en dur dans les systèmes tiers. Troisièmement, les données de Sitecore Forms ne migrent pas de manière propre ; prévoyez d'exporter les soumissions et de reconstruire les formulaires à partir de zéro.

De plus, le nouveau XM Cloud Le modèle de publication est piloté par les événements, ce qui signifie que vos délais de livraison de contenu ne sont plus prévisibles à la seconde près. Pour la plupart des sites, cela convient, mais pour les publications sensibles au facteur temps, comme les communiqués de presse liés à l'ouverture du marché, vous devez repenser le flux de travail. Enfin, le modèle de coût passe de CapEx à OpEx, ce qui surprend les équipes financières. Budgétez une analyse des coûts de fonctionnement sur 3 ans avant de signer quoi que ce soit, car les économies de la première année disparaissent souvent la deuxième année avec la croissance de l'utilisation.

Aucun de ces pièges ne constitue un obstacle insurmontable. Ce sont simplement les éléments qui distinguent une migration fluide de Sitecore 10 vers Sitecore AI d'une migration difficile. Si vous souhaitez voir comment votre parc informatique spécifique se compare à ces pièges, la prochaine étape consiste en un audit structuré. Notre équipe en a réalisé plus de 50, et le schéma est remarquablement cohérent : les surprises sont prévisibles une fois que l'on sait où chercher. Pour un contexte stratégique plus large sur la question de savoir s'il faut migrer ou non, notre dossier decisionnel Sitecore AI se promène à travers les alternatives, et notre Page plateforme Sitecore couvre la pratique Sitecore plus large.