Migrer vers Sitecore XM Cloud: le passage à un DXP composable

Date
7 juin 2024

XM Cloud est le CMS du nouveau DXP composable de Sitecore. Il s’agit d’un développement de leur CMS original, mais avec des différences notables. C’est un SaaS dont la maintenance est plus simple. Il est plus rapide et plus facile à développer, et aussi beaucoup plus facile à utiliser pour les éditeurs de contenu, tout en étant toujours aussi puissant et polyvalent qu’auparavant. Ainsi, lors du lancement d’une nouvelle implémentation Sitecore, le choix de XM Cloud par rapport à la plateforme DXP d’origine est une évidence.

Mais qu’en est-il de la migration de votre implémentation existante vers XM Cloud ? Il n’y pas de trajet de mise à niveau fixe, et votre position de départ aura une grande influence sur le chemin que vous souhaitez emprunter, ainsi que sur les considérations commerciales qui sous-tendent une telle migration. Dans cet article, je partage avec vous mon point de vue sur les principales différences, les défis, les avantages, les préoccupations et les approches possibles pour un trajet de migration, ainsi que tout ce que vous devez savoir et prendre en compte avant de vous embarquer dans ce voyage.

Cloud _ Infrastructuur | iO

1. Qu’est-ce qui différencie XM Cloud de Platform DXP?

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. 

Implémentation typique d’un CMS monolithique avec des intégrations intégrées dans une implémentation.

Migrating to Sitecore XM Cloud

Le passage à une architecture décentralisée et ses avantages 
Avec l’introduction de la capacité headless de Sitecore JSS, la possibilité de séparer complètement le front-end du CMS – à la fois en termes d’architecture et d’infrastructure – a créé une séparation claire entre l’implémentation du CMS lui-même et le front-end basé sur JavaScript.   

Néanmoins, les habitudes de personnalisation sont restées. Par exemple, l’utilisation de résolveurs de contenu personnalisé dans Sitecore pour modifier l’output envoyé au front-end. Pour ces résolveurs de contenu personnalisé, une solution d’implémentation personnalisée a dû être implémentée sur l’instance Sitecore, faisant de l’ajout de fonctionnalités supplémentaires à l’installation Sitecore la solution par défaut ; parfois même des fonctionnalités non liées à Sitecore, telles que des intégrations avec des logiciels externes.  

Implémentation headless avec un front-end déconnecté, mais le même back-end monolithique.

Migrating to Sitecore XM Cloud

« En tant qu’architecture composable, XM Cloud est l’étape suivante en matière de headless, offrant une architecture plus efficace et plus évolutive avec une maintenance plus facile, ce qui permet d’améliorer l’évolutivité, la flexibilité et la productivité. »

De l’importance de la standardisation et de la séparation des responsabilités avec XM Cloud 
Avec XM Cloud, Sitecore envoie un message clair : « En tant que produit SaaS  et Cloud native, nous maintenons votre implémentation CMS à jour et nous gérons l’évolutivité et l’infrastructure, tant que vous conservez une implémentation CMS standard. »  

En suivant le principe MACH pour maximiser la maintenabilité et la flexibilité, la séparation des responsabilités est très importante. Par conséquent, je recommande fortement de garder votre implémentation Sitecore aussi standard que possible en déployant toutes les personnalisations et intégrations dans un microservice séparé. Et c’est ce que j’entends par construire « à côté » plutôt qu’«au-dessus ». 

Votre instance CMS ne forme pas la base de votre projet web, c’est juste l’une des sources de données et l’un des outils pour maintenir votre site web. Séparez votre front-end (en optant pour le headless), mais séparez aussi toute logique business de celui-ci dans des microservices. Et, en conservant des éléments standards, par exemple en évitant d’utiliser des résolveurs de contenu personnalisés, vous améliorez considérablement la maintenabilité de l’architecture de votre plateforme web et permettez des mises à niveau automatiques faciles et sans heurts à l’avenir. 

Une véritable implémentation CMS composable avec un front-end headless et toutes les intégrations séparées dans différents microservices, dans laquelle toutes les intégrations sont déplacées vers le front-end, et le CMS est traité comme l’une des sources de données externes.

Migrating to Sitecore XM Cloud

1.5 Tableau comparatif des fonctionnalités DXP
Comme je l’ai mentionné précédemment, XM Cloud est un produit plus ciblé qui offre moins de fonctionnalités que Platform DXP. XM Cloud fait toutefois partie du nouveau DXP composable de Sitecore, qui consiste en plusieurs produits suivant les mêmes principes que XM Cloud : SaaS et best-of-breed, avec une forte attention pour l’intégration. Dans le tableau ci-dessous, vous pouvez voir quel produit correspond à quelle fonctionnalité au sein de Platform DXP.

Migrating to Sitecore XM Cloud

Pour préparer la migration vers XM Cloud, il est intéressant de commencer par définir les fonctionnalités que vous utilisez actuellement sur Platform DXP, car cela influencera fortement le trajet de mise à niveau nécessaire ou souhaité. XM Cloud prend en charge la personnalisation et l’analyse de base, mais si vous souhaitez par exemple utiliser une personnalisation plus avancée, telle que la personnalisation cross-session ou des règles de personnalisation adaptées, vous devez ajouter Sitecore Personalize à votre stack composable. Quant au complément Sitecore CDP (Customer Data Platform), il vous permet de créer des profils utilisateurs personnalisés, de configurer et d’analyser des personas sur votre site web, et d’obtenir des informations approfondies sur le comportement de vos visiteurs. 

Si votre implémentation Sitecore actuelle inclut une fonctionnalité de recherche personnalisée basée sur les index (Solr) tournant sur votre instance Sitecore, vous devrez trouver une solution alternative. Bien que XM Cloud utilise Solr en interne, l’architecture ne vous permet plus d’utiliser vos propres index pour rechercher un contenu spécifique. Pourquoi ? Parce que l’architecture sépare désormais l’instance Sitecore qui publie le contenu vers Edge (un CDN tournant sur Sitecore) de l’implémentation front-end headless dans un framework JavaScript tel que Next.js. Cela signifie qu’il n’y a aucun moyen d’accéder aux index derrière l’instance Sitecore depuis votre implémentation front-end. Toutes les recherches de contenu sont effectuées par le biais de requêtes GraphQL sur Edge.   

L’une des meilleures façons de rechercher du contenu (et l’une des plus simples) tout en obtenant des informations précieuses sur le comportement de recherche de vos visiteurs, est d’ajouter Sitecore Search à votre stack composable. Ce produit fonctionne indépendamment et peut même fonctionner sur Platform DXP pour permettre une transition facile (nous y reviendrons plus tard !).  

Sitecore EXM (Email Experience Manager) n’est pas compatible non plus avec XM Cloud, donc pour gérer les campagnes d’e-mailing, vous pouvez opter pour Sitecore Send

Enfin, si vous n’utilisez pas encore JSS sur votre Platform DXP, mais les rendus MVC classiques, vous devrez reconstruire votre front-end avec JSS et (par exemple) Next.js. Pour la plupart des implémentations Sitecore existantes, c’est ce changement qui aura le plus grand impact sur le planning et la stratégie. Si vous aviez prévu de moderniser votre front-end de toute façon, c’est une bonne idée de combiner ces deux innovations. Construisez un nouveau front-end headless directement sur XM Cloud, tout en migrant vos templates de données de contenu et les éléments de contenu de votre implémentation existante vers XM Cloud.  

2. Feuille de route de la migration : passer à XM Cloud en quatre phases

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 :

Migrating to Sitecore XM Cloud

2.1 Étape 1 : évaluation des adaptations, des intégrations et de la personnalisation
La première étape consiste à réaliser un inventaire. Listez toutes les adaptations au sein votre CMS, en tenant compte des résolveurs de contenu, des pipelines de rendu et d’autres configurations non standard, tant pour l’UI que pour la logique du CMS. Disposez-vous d’intégrations avec des sources de données externes ou envoyez-vous des données depuis votre site web Sitecore vers d’autres systèmes via le back-end Sitecore ? Pensez par exemple à l’introduction de réservations dans un système de réservation, au transfert de données analytiques vers GA, à la récupération d’informations de profil à partir d’un CRM ou d’offres d’emploi à partir de Saleforce, ou encore à l’envoi de commandes vers Salesforce. Si vous utilisez également la personnalisation sur votre site web, il est conseiller d’analyser et de documenter toutes les règles de personnalisation configurées, car vous devrez les reconfigurer plus tard dans Sitecore XM Cloud ou Personalize.  

La deuxième partie de la phase d’évaluation est une analyse de l’écart entre la fonctionnalité XP que vous utilisez actuellement et la fonctionnalité offerte par XM Cloud. Il est également important de savoir quelle version de Sitecore vous utilisez, et si vous utilisez déjà JSS. Cela vous aidera à déterminer les étapes de votre trajet de migration et la meilleure approche. Je reviendrai plus en détail sur ce point lorsque j’évoquerai les scénarios de migration possibles. 

Pour terminer la phase d’évaluation, commencez à planifier votre trajet de migration : isolez et réécrivez les composants en vue de la migration. Les fonctionnalités non XM peuvent être remplacées par des produits composables distincts (par exemple, remplacer EXM par Send), la logique business personnalisée doit être supprimée de votre implémentation Sitecore, tout comme le contenu et les composants superflus ou obsolètes, afin de réduire la taille et la complexité de la migration dès le début. L’ordre dans lequel vous effectuez ces tâches est critique. 

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. 

Migrating to Sitecore XM Cloud

Déplacez les intégrations vers le front-end, transférez toute éventuelle logique business intégrée vers des microservices séparés et remplacez les fonctionnalités telles que la fonction de recherche et la gestion des campagnes d’e-mailing par Sitecore Search et Sitecore Send par exemple. La fonctionnalité de recherche nécessite un code adapté, des index Solr personnalisés et une infrastructure plus complexe en termes d’hébergement et de maintenance. En éliminant cette complexité de votre implémentation Sitecore, les étapes suivantes seront moins complexes et prendront moins de temps. 

La dernière étape de la préparation de votre solution Sitecore peut être la mise à niveau vers la dernière version de Platform DXP de Sitecore, la version 10.4. Cependant, celle-ci est optionnelle et dépend de votre volonté de conserver le code d’implémentation existant. Si votre implémentation actuelle utilise MVC et que vous devez reconstruire votre front-end de toute façon, et si vous voulez seulement copier les éléments de contenu Sitecore vers la nouvelle implémentation XM Cloud, une mise à niveau de Sitecore peut se révéler inutile. Mais si la différence est relativement faible et que vous utilisez déjà une version récente de Sitecore (ce qui rend la mise à niveau plus petite et plus rapide), il peut être bénéfique de passer d’abord à la version 10.4. La prise en compte de toutes les différences, telles que les versions JSS, les dépendances externes et votre version Next.js, aide également à simplifier le processus de migration lui-même. 

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. 

Migrating to Sitecore XM Cloud

En bref : si votre résolveur de contenu personnalisé contient des données dynamiques ou effectue des opérations supplémentaires (ad hoc), vous ne pouvez pas le migrer vers XM Cloud et vous devez déplacer cette logique vers votre front-end JavaScript. Toutes les autres utilisations d’un résolveur de contenu personnalisé restent compatibles, mais ne sont pas optimale pour la maintenance future. 

Toutes les modifications de données ou les tâches de réorganisation du contenu peuvent être effectuées avec des requêtes GraphQL personnalisées, ce qui est plus facile en termes de maintenance, plus élégant, et garde votre implémentation Sitecore standard. De plus, la restructuration du contenu dans la structure de contenu peut également être une solution pour minimiser le besoin de résolveurs de contenu personnalisés. Dans la plupart des cas, les résolveurs standards Datasource, Data Source Item Children, Context Item (Children) ou Folder Filter suffiront.  

Bien entendu, tout ceci ne s’applique que si vous utilisez déjà JSS. Si votre solution utilise MVC pour le rendu, cela ne s’applique pas et vous devriez passer directement à JSS, de préférence en évitant complètement l’utilisation des résolveurs de contenu personnalisés. 

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éé. 

Découvrez-en davantage sur Sitecore

Avec Sitecore, vous disposez d'un CMS flexible et robuste. Il nous permet de développer des sites web et des services d'intégration avec une attention particulière pour le contenu, la personnalisation, l'e-commerce et les workflows. Voilà qui mérite vraiment le label d'une All-in-one Digital Experience Platform.

Colleague working on laptop with iO drink bottle

3 Choix pour une migration vers XM Cloud : carve out versus approche hybride

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. 

Migrating to Sitecore XM Cloud

Si la différence entre votre implémentation actuelle et les best practices pour XM Could est négligeable, vous pouvez utiliser l’approche « carve out ». Cela implique de déplacer la logique business vers des microservices, de redéfinir votre implémentation Sitecore et de tout déplacer vers XM Cloud. Étant donné que le délai d’exécution de cette dernière étape sera relativement court et que vous pouvez mettre en live chaque étape intermédiaire jusqu’à la migration vers XM Cloud, cette approche peut être divisée en plusieurs versions plus petites, ce qui minimisera le temps de chevauchement nécessaire des deux plateformes. 

Cependant, si les différences sont plus importantes et si vous avez besoin de reconstruire votre front-end, que ce soit entièrement ou partiellement, il peut être préférable d’utiliser l’approche hybride. Avec cette approche, vous conservez intacte votre implémentation existante de la plateforme DXP et créez un nouveau projet XM Cloud en tant que nouvelle instance, parallèlement à votre environnement actuel. Vous pouvez commencer par transférer les modèles de données et le contenu que vous souhaitez conserver, et construire de nouveaux rendus en réutilisant autant de code que possible et en le plaçant dans la nouvelle architecture composable. Comme cela prend généralement plus de temps, je recommande de convertir votre nouveau site web en plusieurs partie – par fonctionnalité, section ou page – et d’utiliser un reverse proxy pour acheminer le trafic vers le bon environnement en fonction de l’URL. Cela vous donne le temps d’apprendre, de faire des ajustements en fonction des commentaires des utilisateurs et des best practices

4 Conclusion

J’espère que cet article vous a donné un aperçu des différences entre les deux plateformes et quelques conseils précieux pour vous aider à débuter votre migration vers Sitecore XM Cloud à partir d’une implémentation existante sur Platform DXP

L’effort requis peut varier considérablement en fonction de votre situation, mais l’investissement en vaut vraiment la peine, car non seulement vous rendrez votre implémentation Sitecore future-proof, mais vous moderniserez également l’ensemble de votre stack et de votre plateforme, tout en établissant une meilleure architecture globale qui améliore de manière significative la maintenabilité et la flexibilité de votre plateforme web. Si le pas vers la composabilité est trop grand, vous pouvez toujours opter pour une transition plus graduelle sur plusieurs trimestres, en adoptant une approche progressive de la reconstruction et de l’introduction de nouveaux composants. 

Rob Habraken - iO
About the author

Rob Habraken

Technology Director - iO

Software expert Rob is what you get when you take a dedicated engineer and put him on that fine line between techy humans and human tech. His favourite view is helicopter and his mode of choice inspiration. DevOps, developer happiness and coaching get his attention today more than ever.

Articles sur le même sujet