1.1 Van monoliet naar best-of-breed 
Platform DXP, voorheen bekend als het Sitecore Experience Platform, is het oorspronkelijke alles-in-één Sitecore-product. Het heeft een monolithisch ontwerp en is daardoor minder flexibel in het selecteren van de ideale subcomponenten voor jouw gebruikssituatie. Bovendien is het veeleisender bij het upgraden naar een nieuwere versie vanwege alle implementatie-specifieke aanpassingen die erin zijn opgenomen. Maar deze alles-in-één benadering betekent ook dat het naast de CMS-functionaliteiten alle DXP-functionaliteiten biedt, zoals e-mailcampagnemanagement en een marketing suite met profiling, personalisatie en A/B testen. 

Dit product is nog steeds beschikbaar, wordt nog steeds ondersteund en onderhouden, en wordt nog steeds veel gebruikt. Maar het is logisch dat Sitecore naast Platform DXP ook een Composable DXP aanbiedt, vooral omdat het gebruik van onderhoudsvriendelijke SaaS-bouwstenen veel snellere ontwikkeling mogelijk maakt en de flexibiliteit biedt om je productstack aan te passen aan de steeds kortere innovatiecycli die we tegenwoordig zien.  

Sitecore XM Cloud is het CMS-product binnen het Composable DXP aanbod. En hoewel het minder functionaliteit biedt dan Platform DXP, wordt deze beperking ruimschoots gecompenseerd door de verbeterde flexibiliteit, integratiemogelijkheden en Developer Experience. En het gaat zelfs nog verder, omdat XM Cloud zelfs basisfunctionaliteit voor personalisatie en zeer nuttige ingebouwde analyses biedt! 

1.2 Moeiteloos nieuwe pagina’s bouwen met Sitecore Pages 
Naast de betere architectuur en verschillen in functionaliteit, biedt XM Cloud ook een volledig vernieuwde in-page bewerkingservaring: Sitecore Pages. Deze nieuwe tool voor redacteuren en marketeers is gebruiksvriendelijker dan de oorspronkelijke Experience Editor, is aanzienlijk sneller, maar introduceert ook een nieuw concept: componenten - samen met de Component Builder.  

Door gebruik te maken van Page Designs en Components als bouwstenen, kun je moeiteloos nieuwe pagina's binnen je site bouwen en zelfs volledig nieuwe componenten toevoegen met behulp van de Component Builder, zonder dat je iets hoeft te ontwikkelen of ook maar een regel code hoeft te schrijven!  

Het biedt ook de mogelijkheid om te schakelen tussen meerdere thema's en componentvariaties en het bevat een wizard voor het maken van een site, waardoor het gemak voor content editors naar nieuwe hoogten wordt gebracht. Deze aanzienlijk verbeterde bewerkingservaring op zichzelf is al een reden om te overwegen om over te stappen naar XM Cloud. De meeste andere motieven zijn van technische aard of hebben betrekking op het budget, maar dit is het belangrijkste voordeel voor iedereen die dagelijks met Sitecore werkt als CMS. 

1.3 Een SaaS oplossing met PaaS flexibiliteit
Waar Platform DXP zowel on-premises als op PaaS-architecturen zoals Azure Web Apps en SQL PaaS-databases kon worden gehost, is XM Cloud alleen beschikbaar als SaaS-oplossing. Hoewel typische SaaS-producten je toegang bieden tot een gedeelde omgeving, stelt XM Cloud je nog steeds in staat (of vereist het zelfs) om je eigen instantie binnen Sitecore's SaaS-omgeving op te zetten. Het geeft je de mogelijkheid om kleine aanpassingen te implementeren, samen met je eigen aangepaste front-end. Maar vanaf dat punt onderhoudt Sitecore de omgeving en zorgt het voor de noodzakelijke opschaling, (infrastructuur)onderhoud en reguliere updates. En je ontwikkelomgeving op basis van Docker-containerimages wordt parallel bijgewerkt.  

Op deze manier profiteer je van alle voordelen van SaaS, maar met de flexibiliteit van PaaS-architecturen. Dit verbetert echt de gehele ontwikkelervaring en maakt het opzetten van een nieuwe Sitecore-omgeving veel eenvoudiger.  

Wees echter voorzichtig, want je wilt de mogelijkheid om aanpassingen door te voeren niet te veel gebruiken: streef ernaar om de Sitecore-implementatie zo standaard mogelijk te houden! Ik zal je later laten zien hoe en waarom. 

1.4 Composable implementatiearchitectuur voor verbeterde standaardisatie, scheiding van verantwoordelijkheden en toekomstbestendigheid  
Met XM Cloud verandert ook de applicatiearchitectuur van je implementatie. Je bouwt er niet meer bovenop, maar ernaast. Maar wat betekent dit?  

De traditionele rol van CMS’en in website-implementaties 
Jarenlang werden CMS’en (niet alleen Sitecore) gezien als het fundament om een website-implementatie op te bouwen. Voor het headless tijdperk was dit noodzakelijk omdat het renderen werd gedaan door het CMS (bijvoorbeeld met behulp van MVC in .NET). Daarnaast bood Sitecore veel mogelijkheden om in te haken op de kernprocessen van het CMS: inhaken op events, render pipelinges wijzigen, en de UI of specifiek gedrag van het CMS aanpassen in bepaalde scenario’s. Deze eindeloze mogelijkheden leidden tot sterk aangepaste implementaties die sterk gekoppeld waren aan de code en installatie van het CMS zelf. Dit maakt een upgrade naar een nieuwere versie uitdagend, omdat je de standaard Sitecore-code en -configuratie moet scheiden van aangepaste code en configuratie om de vanille-installatie van Sitecore te kunnen updaten naar een nieuwere versie. 

Zoals aangegeven, bepaalt je huidige implementatie hoe je migratiepad eruit zal zien. Als je veel gebruik maakt van XP-functionaliteit, moet je dat er eerst uithalen. En vanuit een Composable oogpunt is het perfect mogelijk om dat te doen binnen je huidige implementatie voordat je daadwerkelijk met de migratie zelf begint. Over het algemeen kunnen we een typisch migratieproject in vier fasen verdelen:

2.2 Stap 2: De migratie voorbereiden met het verkleinen van het verschil tussen Platform DXP en XM Cloud 

Wanneer de beoordeling en planning zijn afgerond, kunnen we beginnen met de voorbereiding van de daadwerkelijke migratie. In deze fase zijn er geen migratietaken, maar we gaan onze huidige implementatie of oplossing voorbereiden op de geplande migratie. Deze fase heeft twee doelen: het verkleinen van het verschil tussen uw Platform DXP en de functionaliteit van XM Cloud, en het minimaliseren van de implementatiegrootte voor de uiteindelijke migratie. 

Het voordeel van Composability is dat Composable en MACH-gebaseerde componenten, of Packed Business Capabilities (PBC's), ook kunnen integreren met niet-Composable architecturen. Dus elk Composable- of SaaS-product dat je nu aan je huidige implementatie toevoegt, kan al vrijwel in zijn eindstaat geïmplementeerd worden. En door functionaliteit te verwijderen uit je monolithische DXP-implementatie, zal je uiteindelijke migratie eenvoudiger en goedkoper worden, terwijl de doorlooptijden korter zullen zijn. Dit proces noemen we het isoleren van je huidige bedrijfslogica: 

2.3 Stap 3: De front-end herschrijven met headless & GraphQL 
Nu is het tijd om de front-end grondig te bekijken. Logischerwijs is deze fase het meest variabel wat betreft de impact op de benodigde investering om over te stappen naar XM Cloud. Als je al een headless architectuur gebruikt, is het perfect mogelijk om je renderings te behouden. Zo niet, dan moet je rekening houden met een gedeeltelijke of volledige herbouw van de front-end. 

2.3.1 Rendering pipelines 
Als je aangepaste rendering pipelines gebruikt, moet je deze laten vervallen en je rendermechanisme opnieuw ontwerpen of overschakelen naar een standaard JSS-implementatie. Het hele concept van rendering pipelines is verouderd met de komst van XM Cloud, omdat het alleen een headless setup ondersteunt. Content wordt statisch gepubliceerd naar Edge als het CDN en van daaruit kun je content opvragen vanuit je JavaScript front-end. De Sitecore Layout Service Client behandelt routing en page requests, en extra GraphQL-query's kunnen worden gebruikt om specifieke content op te halen, zoals het laatste nieuws of een lijst met alle items van een bepaald type. 

2.3.2 Content resolvers (voor JSS) 
Ten tweede moeten maatwerk content resolvers vermeden worden in een nieuwe XM Cloud-implementatie, maar in sommige gevallen functioneren ze nog steeds correct. Dus voor migratiedoeleinden kun je ze behouden en later beslissen of je ze wilt vervangen of opnieuw wilt ontwerpen.  

De reden voor gedeeltelijke compatibiliteit met maatwerk content resolvers ligt opnieuw bij het mechanisme van publiceren naar de Edge. Traditioneel werd content gepubliceerd vanuit uw werkdatabase (master) naar uw gepubliceerde database (web) en werd deze alleen gedurende het web request resolved, wat het exacte moment was waarop de content resolvers werden uitgevoerd. Dit maakte dynamische en contextuele content resolvers mogelijk.  

Maar met XM Cloud wordt de webdatabase niet langer gebruikt en wordt bij het publiceren van content een statische inhouds- en lay-outsnapshot gemaakt die op het CDN wordt geplaatst. Dus in feite voert de publicatie nu de content resolver uit en stuurt het resultaat naar de Edge. Tijdens een verzoek kun je dat gecachte en resolved stukje content ophalen, maar je kunt het proces van content resolvers of de backend niet bereiken, dus dynamische of contextuele resolving is niet langer mogelijk.

2.3.3 Herbouwopties 
Afhankelijk van je startpunt kunnen verschillende scenario's van toepassing zijn bij het herbouwen van je front-end voor de migratie naar XM Cloud: 

• Als je op 10.x draaide met behulp van JSS zonder aangepaste content resolvers, kun je de hele front-end naar XM Cloud overzetten met minimale aanpassingen. 

• Als je al JSS gebruikt op een eerdere versie van Sitecore en ook maatwerk content resolvers gebruikt, moet je jouw Sitecore-versie upgraden (indien nog niet gedaan in de voorbereidingsfase) en de delen herontwerpen die incompatibele content resolvers gebruiken. 

• Als je MVC gebruikt met een React front-end met aangepaste rendering pipelines, kun je mogelijk delen van je React-renderings hergebruiken in de nieuwe Next.js-setup, maar moet je de Sitecore-implementatie herontwerpen om van MVC over te stappen naar een headless aanpak. Hoewel dit scenario vrij exotisch is en als je zo'n aangepaste setup gebruikt, kan herbouwen met behulp van de standaard Next.js- en JSS-setup een betere keuze zijn. 

• Als je het klassieke MVC-model gebruikt, moet je zowel je front-end als de Sitecore-implementatie herbouwen, wat betekent dat het vervangen of moderniseren van je gehele front-end als onderdeel van het migratieproject de beste keuze zou zijn. 

2.4 Stap 4: Migreren en je Cloud-omgeving aanmaken 
De laatste fase van de migratieroute omvat de daadwerkelijke migratie of overgang naar XM Cloud. Begin met het opzetten van een nieuwe oplossing op basis van de XM Cloud template van Sitecore en update je Nuget Feed naar Sitecore.XMCloud.*. Update de standaard buildconfiguratie in het xmcloud.build.json-bestand om je itemserialisatie te configureren, de projecten te compileren (die tot een minimum beperkt moeten worden!) en je rendering hosts in te stellen. 

Daarna, ter voorbereiding van de contentmigratie, configureer je Sitecore Content Serialization (SCS). Als je nog steeds Unicorn of TDS gebruikt, raad ik aan om SCS te overwegen, omdat het een Sitecore-native technologie is die erg snel en krachtig is. Wanneer je jouw serialization hebt ingesteld, kun je beginnen met het migreren van je content. Dit werkt net als elke andere contentmigratie van de ene naar de andere Sitecore-omgeving, en je kunt zowel content packages als het SCS-proces gebruiken om je bestaande templates, lay-outs en content items in je nieuwe Sitecore-oplossing te injecteren. Ook Razl kan handig zijn bij het vergelijken van databases (met je lokale Sitecore XM Cloud-instantie) of om een enkel content item naar je nieuwe omgeving te pushen buiten de SCS-configuratie. 

Als je personalisatieregels opnieuw moet toepassen (op basis van je nieuwe ontwerp), is dit nu een goed moment daarvoor. Afhankelijk van je planning en mogelijke content freeze, kan het echter ook verstandig zijn om dit te doen nadat je nieuwe XM Cloud-website naar productie is gebracht. 

Ten slotte moet je nieuwe CI/CD-pipelines ontwerpen en implementeren. Die pipelines kunnen gebruikmaken van de Sitecore XM Cloud-native CLI-commando's en zullen vrij eenvoudig in te stellen zijn in tegenstelling tot wat je gewend bent van een PaaS-infrastructuur of aangepaste on-premises Sitecore-implementatie. Je kunt je front-end los van Sitecore uitrollen, zodat je elk bestaand of nieuw zelfonderhouden proces daarvoor kunt gebruiken. 

Na alle stappen van een typische migratieroute naar XM Cloud te hebben behandeld, is er nog één beslissing die genomen moet worden om ons actieplan voor de migratie af te ronden: hoe om te gaan met deze overgang terwijl de winkel openblijft? Grofweg gezien zijn er twee mogelijke scenario's.