1.1 Du monolithe au best-of-breed  
Platform DXP, anciennement connu sous le nom de Sitecore Experience Platform, est le produit tout-en-un d’origine de Sitecore. Sa conception monolithique le rend moins flexible dans la sélection des sous-composants les mieux adaptés à votre situation d’utilisation. En outre, il est plus exigeant lors de la mise à niveau vers une version plus récente, en raison de toutes les modifications spécifiques à l’implémentation qui y sont incluses. Mais cette approche tout-en-un signifie également qu’en plus des fonctionnalités CMS, il offre toutes les fonctionnalités DXP, telles que la gestion des campagnes d’e-mailing et une suite marketing avec profilage, personnalisation et tests A/B.  

Ce produit est toujours disponible, il bénéficie toujours du support Sitecore et est encore largement utilisé. Mais il est logique que Sitecore propose un DXP composable en plus de Platform DXP, d’autant plus que l’utilisation de blocs SaaS faciles à entretenir permet un développement beaucoup plus rapide et la flexibilité d’adapter votre stack de produits aux cycles d’innovation de plus en plus courts que nous connaissons aujourd’hui. 

Sitecore XM Cloud est le produit CMS au sein de l’offre DXP composable. Bien qu’il offre moins de fonctionnalités que Platform DXP, cette limitation est plus que compensée par sa flexibilité accrue, ses capacités d’intégration et son expérience développeur. Et cela va encore plus loin, puisque XM Cloud offre même une fonctionnalité de personnalisation de base et des analyses intégrées très utiles !  

1.2 Construire de nouvelles pages sans efforts avec Sitecore Pages  
En plus de son architecture améliorée et de ses fonctionnalités différentes, XM Cloud offre également une expérience d’édition in-page complètement remaniée : Sitecore Pages. Ce nouvel outil pour les rédacteurs et les experts en marketing est plus convivial que l’Experience Editor original, mais aussi significativement plus rapide, et il introduit un nouveau concept : les composants – ainsi que le Component Builder. 

En utilisant Page Designs et Components comme blocs de construction, vous pouvez créer sans effort de nouvelles pages sur votre site web, et même ajouter des composants entièrement nouveaux à l’aide du Component Builder, sans avoir à développer quoi que ce soit ou à écrire ne serait-ce qu’une ligne de code !  

Il offre également la possibilité de basculer entre plusieurs thèmes et variations de composants, et comprend un wizard de création de site, ce qui permet aux éditeurs de contenu d’atteindre de nouveaux sommets en termes de facilité d’utilisation. Cette expérience d’édition considérablement améliorée est déjà en soi une raison d’envisager de passer à XM Cloud. La plupart des autres raisons sont techniques ou budgétaires, mais il s’agit là du principal avantage pour tous ceux qui travaillent quotidiennement avec Sitecore en tant que CMS. 

1.3 Une solution SaaS avec une flexibilité PaaS
Alors que Platform DXP pouvait être hébergé à la fois on-site et sur des architectures PaaS telles qu’Azure Web Apps et les bases de données SQL PaaS, XM Cloud est uniquement disponible en tant que solution SaaS. Alors que les produits SaaS typiques vous donnent accès à un environnement partagé, XM Cloud vous permet (voire vous oblige) à configurer votre propre instance dans l’environnement SaaS de Sitecore. Il vous permet d’implémenter des adaptations mineures ainsi que votre propre front-end personnalisé. Mais, à partir de là, Sitecore se charge de la maintenance de l’environnement et de l’infrastructure, de la mise à l’échelle nécessaire et des mises à jour régulières. Et votre environnement de développement basé sur des images de conteneurs Docker est mis à jour en parallèle. 

Ainsi, vous bénéficiez de tous les avantages du SaaS, mais avec la flexibilité des architectures PaaS. Ce qui améliore véritablement l’expérience de développement et facilite grandement la mise en place d’un nouvel environnement Sitecore.  

Attention cependant à ne pas abuser des possibilités de personnalisation : essayez de garder l’implémentation de Sitecore aussi standard que possible. Je vous montrerai comment et pourquoi un peu plus loin.  

1.4 Architecture d’implémentation composable pour une meilleure standardisation, une séparation des responsabilités et un système pérenne  
Avec XM Cloud, l’architecture applicative de votre implémentation change aussi. Vous ne construisez plus au-dessus, mais à côté. Qu’est-ce que cela signifie au juste ?  

Le rôle traditionnel des CMS dans les implémentations de site web 
Pendant des années, les CMS (et pas seulement Sitecore) ont été considérés comme la base pour construire une implémentation de site web. Avant l’ère du headless, c’était nécessaire car le rendu était effectué par le CMS (par exemple en utilisant MVC dans .Net). De plus, Sitecore offrait de nombreuses opportunités de se raccrocher aux processus centraux du CMS : se raccrocher aux événements, modifier le pipeline de rendu, personnaliser l’interface utilisateur ou le comportement spécifique du CMS dans certains scénarios. Ces possibilités infinies ont conduit à des implémentations hautement personnalisées qui étaient fortement liées au code et à l’installation du CMS lui-même. Cela rend la mise à jour vers une version plus récente difficile, car vous devez séparer le code et la configuration standard de Sitecore du code et de la configuration personnalisés, pour mettre à jour l’installation « vanille » de Sitecore vers une version plus récente. 

Comme indiqué, votre implémentation actuelle détermine à quoi ressemblera votre trajet de migration. Si vous utilisez beaucoup de fonctionnalités XP, vous devrez d’abord les supprimer. Et d’un point de vue « composable », il est parfaitement possible de le faire au sein de votre implémentation actuelle avant de débuter la migration proprement dite. En général, il est possible de diviser un projet de migration typique en quatre phases :

2.2 Étape 2 : préparation de la migration en réduisant les différences entre Platform DXP et XM Cloud  
Une fois l’évaluation et la planification terminées, nous pouvons commencer à préparer la migration proprement dite. Dans cette phase, il n’y a pas de tâches de migration, mais nous préparons notre implémentation ou solution actuelle pour la migration prévue. Cette phase a deux objectifs : réduire la différence entre les fonctionnalités de votre plateforme DXP et celles de XM Cloud, et minimiser la taille de l’implémentation pour la migration finale.  

L’avantage de la composabilité est que les composants composables et basés sur MACH, ou Packed Business Capabilities (PBC) peuvent également s’intégrer à des architectures non composables. 

2.3 Étape 3 : réécriture du front-end avec headless & GraphQL  
Il est maintenant temps d’examiner le front-end en profondeur. Logiquement, cette étape est la plus variable en termes d’impact sur l’investissement nécessaire pour passer à XM Cloud. Si vous utilisez déjà une architecture headless, il est tout à fait possible de conserver vos rendus. Dans le cas contraire, il faut envisager une refonte partielle ou complète du front-end.  

2.3.1 Pipeline de rendus  
Si vous utilisez des pipelines de rendu personnalisés, vous devez les abandonner et revoir votre mécanisme de rendu ou passer à une implémentation JSS standard. Le concept même de pipeline de rendu est obsolète depuis l’avènement de XM Cloud, car il ne prend en charge qu’une configuration headless. Le contenu est publié statiquement sur Edge en tant que CDN et, de là, vous pouvez envoyer une requête pour le contenu à partir de votre front-end JavaScript. Le Layout Service Client de Sitecore gère le routage et les requêtes de page, et des requêtes GraphQL supplémentaires peuvent être utilisées pour récupérer un contenu spécifique, comme les dernières actualités ou une liste de tous les éléments d’un type particulier. 

2.3.2 Résolveurs de contenu (pour JSS)  
Deuxièmement, les résolveurs de contenu personnalisés devraient être évités dans une nouvelle implémentation XM Cloud mais, dans certains cas, ils fonctionnent encore correctement. À des fins de migration, vous pouvez donc les conserver et décider plus tard de les remplacer ou de les remanier. 

La raison de la compatibilité partielle avec les résolveurs de contenu personnalisés réside à nouveau dans le mécanisme de publication vers Edge. Traditionnellement, le contenu était publié depuis votre base de données de travail (master) vers votre base de données publiée (web) et résolu uniquement lors de la requête web, c’est-à-dire au moment précis où les résolveurs de contenu étaient exécutés. Cela permettait d’avoir des résolveurs de contenu dynamiques et contextuels. 

Mais avec XM Cloud, la base de données web n’est plus utilisée et, lors de la publication de contenu, un instantané statique du contenu et de la mise en page est créé et placé sur le CDN. Ainsi, la publication exécute désormais le résolveur de contenu et envoie le résultat à Edge. Lors d’une requête, vous pouvez récupérer cet élément de contenu mis en cache et résolu, mais vous ne pouvez pas atteindre le processus de résolution de contenu ou le back-end, de sorte que la résolution dynamique ou contextuelle n’est plus possible. 

2.3.3 Options de reconstruction  
En fonction de votre point de départ, différents scénarios peuvent s’appliquer lors de la reconstruction de votre front-end pour la migration vers XM Cloud : 

• Si vous tourniez sur 10.x en utilisant JSS sans résolveur de contenu personnalisé, vous pouvez transférer l’ensemble du front-end vers XM Cloud avec des modifications minimales. 

• Si vous utilisez déjà JSS sur une version antérieure de Sitecore ainsi que des résolveurs de contenu personnalisés, vous devez mettre à jour votre version de Sitecore (si cela n’a pas déjà été fait lors de la phase de préparation) et reconstruire les parties qui utilisent des résolveurs de contenu incompatibles. 

• Si vous utilisez MVC avec un front-end React et des pipelines de rendu personnalisés, vous pouvez être en mesure de réutiliser des parties de vos rendus React dans la nouvelle configuration Next.js, mais vous devrez revoir la conception de l’implémentation Sitecore pour passer de MVB à une approche headless. Bien que ce scénario soit assez exotique et si vous utilisez une telle configuration personnalisée, la reconstruction en utilisant la configuration standard de Next.js et JSS peut être un meilleur choix. 

• Si vous utilisez le modèle MVC classique, vous devrez reconstruire à la fois votre front-end et votre implémentation Sitecore, ce qui signifie que le remplacement ou la modernisation de l’ensemble de votre front-end serait le meilleur choix dans le cadre du projet de migration. 

2.4 Étape 4 : migration et création de votre environnement Cloud  
La dernière phase de ce trajet consiste en la migration elle-même, c’est-à-dire la transition effective vers XM Cloud. Commencez par configurer une nouvelle solution basée sur le template XM Cloud de Sitecore et mettez à jour votre Nuget Feed vers Sitecore.XMCloud.*. Mettez à jour la configuration de construction par défaut dans le fichier xmcloud.build.json pour configurer la sérialisation de vos éléments, compiler les projets (qui doivent être réduits au minimum !) et configurer vos rendering hosts.  

Ensuite, en préparation de la migration du contenu, configurez Sitecore Content Serialization (SCS). Si vous utilisez encore Unicorn ou TDS, je vous recommande d’envisager de passer à SCS, car c’est une technologie native de Sitecore qui est très rapide et puissante. Une fois que vous avez configuré votre sérialisation, vous pouvez commencer à migrer votre contenu. Cela fonctionne comme n’importe quelle autre migration de contenu d’un environnement Sitecore à un autre, et vous pouvez utiliser à la fois les paquets de contenu et le processus SCS pour injecter vos templates, lay-out et éléments de contenu existants dans votre nouvelle solution Sitecore. Razl peut également se révéler utile pour comparer les bases de données (avec votre instance Sitecore XM Cloud locale) ou pour pousser un seul élément de contenu vers votre nouvel environnement en dehors de la configuration SCS.  

Si vous devez réappliquer les règles de personnalisation (sur la base de votre nouveau design), c’est le bon moment pour le faire. Toutefois, en fonction de votre calendrier et d’un éventuel content freeze, il peut également être judicieux de le faire après la mise en production de votre nouveau site web XM Cloud. 

Enfin, vous devez concevoir et implémenter de nouveaux pipelines CI/CD. Ces pipelines peuvent utiliser les commandes CLI natives de Sitecore XM Cloud et seront assez faciles à mettre en place, contrairement à ce que vous avez l’habitude de faire avec une infrastructure PaaS ou une implémentation personnalisée de Sitecore on-site. Vous pouvez déployer votre front-end séparément de Sitecore, vous pouvez donc utiliser pour cela n’importe quel processus existant ou nouvellement créé. 

Après avoir couvert toutes les étapes d’un trajet de migration typique vers XM Cloud, il reste une décision à prendre pour finaliser notre plan d’action : comment gérer cette transition tout en gardant la boutique ouverte ? En gros, il y a deux scénarios possibles.