{"id":15744,"date":"2023-01-23T14:16:35","date_gmt":"2023-01-23T14:16:35","guid":{"rendered":"https:\/\/it-management.cornerd.com\/?p=15744"},"modified":"2023-01-23T14:17:37","modified_gmt":"2023-01-23T14:17:37","slug":"sitecore-architects-guide-to-saas-migration-xp-global-brand-scenario","status":"publish","type":"post","link":"https:\/\/cornerd.com\/sitecore-architects-guide-to-saas-migration-xp-global-brand-scenario\/","title":{"rendered":"Sitecore Architect\u2019s Guide to SaaS Migration \u2013 XP Global Brand state of affairs"},"content":{"rendered":"
<\/p>\n
\n
In this a part of the\u00a0migration collection<\/u>, I’m going to have a look at migrating an current Sitecore Experience Platform (XP) \u201cGlobal Brand\u201d answer, with many websites and deep personalization utilization, over to Sitecore XM Cloud and Sitecore Personalize. Follow the collection to have a look at totally different Sitecore XM and XP eventualities and how one can regularly migrate\u00a0your Sitecore platform answer over to a\u00a0composable DXP structure<\/u>.<\/p>\n
The objective is to stroll by the instance migration and spotlight for you:<\/p>\n
\n
What challenges will you face alongside the way in which?<\/li>\n
What choices can be found and when do they make sense?<\/li>\n
What are the advantages of constructing sure adjustments to your structure?<\/li>\n<\/ul>\n
Every challenge is a bit of totally different, so hopefully this collection can assist you perceive a number of the inquiries to ask, and what choices you have got, to information you in the suitable route.<\/p>\n
The \u201cGlobal Brand\u201d place to begin<\/h2>\n
Some clients can have very complicated Sitecore implementations. Sometimes you have got years of technical debt, a number of separate utility installations, other ways of constructing websites, other ways of deploying, totally different variations.<\/p>\n
For this state of affairs, we’re taking a look at a world model that’s doing supply all all over the world, with a whole lot of web sites. Some of web sites are long-lived, multilingual, and multiregion websites just like the official company model websites. Others are short-lived marketing campaign microsites that spin up after which spin down when the marketing campaign is completed. Personalization has been carried out on a lot of the bigger websites, and a number of the marketing campaign websites.<\/p>\n<\/figure>\n
In this state of affairs, the client is at present operating totally different remoted cases of Sitecore XP in a number of areas, with totally different variations. Some are on model 9, others on model 10. They have totally different Sitecore\u00a0xDB knowledge shops for the totally different areas to satisfy with regional knowledge compliance guidelines, and the group has a number of totally different authoring areas to assist all their manufacturers and totally different advertising groups all over the world.<\/p>\n
The must ship globally is a must have and the group want to offload a number of the duty for this supply infrastructure scaling, in addition to the general administration of the Sitecore content material and personalization infrastructure.\u00a0<\/p>\n
From an implementation perspective, the dev groups have been constructing with totally different tech through the years. Many of the websites are conventional MVC or SXA websites, although just a few at the moment are operating headless with Sitecore\u00a0JSS on React or Next.js.\u00a0<\/p>\n
Not precisely the best highway to SaaS in entrance of this workforce!\u00a0<\/p>\n
In this state of affairs, the client had already began transferring in direction of a distributed mesh of built-in methods. There are a number of vendor options of their structure comparable to a DAM, a CDN, a SaaS advertising automation software, and others. They now wish to align their Sitecore utility infrastructure with this structure method and eventually go totally headless and SaaS internet hosting. \u00a0<\/p>\n
Step 1: Track with Sitecore Personalize<\/h2>\n
The first step on this highway is including Sitecore Personalize into the combination in order that we are able to begin monitoring guests. This will begin increase the customer knowledge and make sure that any website that migrates over to Sitecore\u00a0Personalize could have knowledge already populated. Any new websites that get launched, like a brand new marketing campaign website, may be began instantly on Sitecore Personalize with out utilizing Sitecore XP personalization.<\/p>\n<\/figure>\n
Why is that this a good suggestion?<\/h3>\n
Adding Sitecore Personalize in at this stage to any website is a comparatively low effort for the technical workforce, as soon as the tenants are configured. By doing Sitecore Personalize first whereas nonetheless utilizing Sitecore XP permits for the group to regularly migrate the personalization from Sitecore XP to Sitecore Personalize. There are just too many websites and an excessive amount of personalization already constructed into this state of affairs to do an entire \u201craise and shift\u201d for all of the websites on the similar time.\u00a0<\/p>\n
Additionally, this enables for the software to be rolled out to the client groups regularly. As extra groups are introduced on board, the group can refine its onboarding course of for every model. Each workforce can begin studying and constructing out personalization guidelines inside Sitecore Personalize, with Sitecore XP nonetheless serving up the prevailing personalization guidelines whereas they study.\u00a0<\/p>\n
This method additionally signifies that we cut back the variety of new Sitecore XP personalization guidelines being constructed, which makes the later migration effort simpler. \u00a0<\/p>\n
Things to be careful for<\/h3>\n
One draw back to this method is that we begin having totally different analytics knowledge in several shops. Teams are probably already utilizing Google Analytics, and a number of Sitecore xDB sources, and at the moment are including Sitecore Personalize monitoring into the combination. If there are groups doing reporting, this might add some trouble to their means to report on knowledge. One choice right here could be to disregard Sitecore Personalize knowledge in reporting till a website is accomplished moved off of Sitecore XP.<\/p>\n
There can be some confusion when making an attempt to find out the place a personalization is coming from with two personalization methods operating on the similar time. It is probably going finest to strive to ensure a given website or web page will not be utilizing each Sitecore XP personalization and Sitecore Personalize guidelines on the similar time. This will make it simpler for implementation groups to isolate the place personalization points could be occurring and keep away from potential conflicts.<\/p>\n
Step 2: Go to the Edge<\/h2>\n
At this level we\u2019re going to imagine that the groups have Sitecore Personalize added to the websites. The personalization guidelines could not have migrated totally but, however we’re assuming that monitoring is in place. Now we wish to give attention to decreasing that large Sitecore content material supply layer. We wish to cut back the variety of Sitecore content material supply cases which are required to satisfy customer calls for.<\/p>\n
By including Sitecore Experience Edge as a layer we are able to roll content material supply caching globally, that means that requests for content material don’t want to return to the Sitecore CD layer. This signifies that apps like Next.js can deploy a static website to a number like Netlify or\u00a0Vercel and get the information from an edge layer, as an alternative of going again to origin each time, finally dashing up construct occasions and decreasing the necessity for Sitecore CD cases.\u00a0<\/p>\n
But to get that benefit, which means we have to transfer to static websites, as a lot as attainable, to place our finish consumer website internet hosting onto a SaaS supply platform. To get there, the implementation workforce must align to the most recent Sitecore XP model which has the Next.js JSS SDK.<\/p>\n<\/figure>\n
Is static publishing a shortcut?<\/strong> Some of those websites could also be simpler to maneuver to Next.js than others. Rebuilding a bunch of MVC websites may not be the most suitable choice proper now, however we are able to benefit from static publishing capabilities launched in Sitecore XP 10.2 and migrate some MVC\/SXA websites to Next.js supply with much less effort utilizing the brand new\u00a0SSG publishing of web sites information. \u00a0It ought to be famous that that is for particular sorts of websites, and a few complicated websites may not be the suitable match for static website publishing, which implies they might want extra of a rework. It\u2019s in all probability finest to focus on content-only websites first.<\/p>\n
Moving to static supply<\/strong> Migrating over to a static method is more likely to contain a whole lot of coordination of groups, however this course of could be finished regularly. One secret is to first determine which websites are going to be retired and received\u2019t be migrated, thus decreasing the general effort.<\/p>\n
As these purposes transfer to static supply, the necessity for the prevailing Sitecore content material supply infrastructure will go down. It is feasible to even goal elements of a website to transition to static, and benefit from routing configuration to serve up sure routes from the prevailing infrastructure when you migrate.<\/p>\n
When full, most customer site visitors ought to now be going to the static website supply layer. There will nonetheless be a necessity for a excessive availability Sitecore CD layer, although. These remaining cases will reply to server-side requests for XP personalization or different wants that haven\u2019t been migrated. Unfortunately, we are able to\u2019t remove all of it simply but.<\/p>\n
Why is that this a good suggestion?<\/h3>\n
By constructing an structure with Next.js+Experience Edge+SSG the enterprise will get just a few large advantages with out doing a full rebuild of all of the purposes and websites.\u00a0 With Sitecore Experience Edge and static websites, groups ought to have the ability to get higher world core net vitals, with much less effort, which is able to profit total buyer expertise and website positioning.\u00a0<\/p>\n
The ongoing want for world supply additionally turns into a lot simpler to realize, and extra easy to increase into new areas and goal with new campaigns. All of this additionally combines with much less duty for the supply infrastructure, offloading that to Experience Edge and the static website host.<\/p>\n
This method additionally permits for regularly transferring purposes and particularly concentrating on websites the place the most effective Return on Investment (ROI) will probably be. \u00a0<\/p>\n
Things to be careful for<\/h3>\n
There are some things to consider. I discussed aligning to Sitecore model 10.2 to get entry to the instruments you want for the static website publishing, plus aligning higher to the eventual transfer to XM Cloud. Upgrades are sometimes not trivial, particularly when transferring from earlier variations. If a selected website is on a model earlier than Sitecore XP model 9, it could be higher ROI to do a full rebuild\/redesign challenge for that website and construct instantly onto the SaaS host relatively than making an attempt to maneuver regularly by these levels. (This assumes the positioning is being deliberate to be stored in any respect.)<\/p>\n
Also, any heavy personalization websites received\u2019t be seeing a lot profit from this transition, until the advertising workforce has already been migrating personalization guidelines to Sitecore Personalize. If the websites use heavy server-side personalization, they\u2019ll be pinging again to the prevailing Sitecore CD layer, and bypassing the advantages of the static supply layer. If we actually wish to cut back the content material supply load right here for websites which have a whole lot of server-side personalization, these websites ought to in all probability begin transitioning to Sitecore Personalize as early as attainable to scale back the variety of requests again to the CD layer.<\/p>\n
One last factor to look out for is the match of MVC websites to static publishing. As a lot as I want it was, the static publishing out there with Sitecore XP 10.2 isn\u2019t magic and received\u2019t be a match for all websites. Right now, it does have some limitations that have to be thought of (no multilingual, no media library, kinds limitations, different limitations). If a website isn\u2019t a match for SSG publishing, one of many different strategies to get to Next.js ought to be checked out for that website. \u00a0<\/p>\n
Step 3: Transition to XM<\/h2>\n
It\u2019s time to maintain transferring on. Now that we\u2019ve transitioned a whole lot of the site visitors to edge supply, it\u2019s time to begin ripping out all that managed XP infrastructure that isn’t going for use. This means migrating the personalization in Sitecore XP over to Sitecore Personalize.<\/p>\n<\/figure>\n
Why is that this a good suggestion?<\/h3>\n
Getting so far and eliminating all that XP infrastructure drastically reduces what the workforce is answerable for sustaining.<\/p>\n
This structure can also be very near what will probably be utilized in a Sitecore Composable DXP state of affairs with XM Cloud and Experience Edge, so we\u2019re virtually prepared for that transfer.<\/p>\n
Finally, by totally adopting Sitecore Personalize the group is nearer to that totally composable structure and this opens up alternatives for headless personalization throughout different channels too. \u00a0<\/p>\n
Things to be careful for<\/h3>\n
One problem is that Sitecore Personalize doesn’t configure or execute in the identical means that Sitecore XP does. Sitecore Personalize can also be not natively built-in into the Sitecore XM editor (on the time of writing). Add to that the truth that the information migration will not be a easy push or a 1:1 mapping, and this migration would possibly imply a whole lot of digital technique is required to plan out how one can obtain the enterprise targets of personalization another way.<\/p>\n
Some clients on this state of affairs could have already got one other CDP in play, through which case migrating xDB knowledge into Personalize or SmartHub CDP isn\u2019t an excellent ROI. The knowledge ought to go to the prevailing CDP after which Personalize ought to combine with that CDP to get the information.<\/p>\n
\n
\n
\n
\n
Want extra particulars about migrating to Sitecore CDP\/Personalize?<\/h2>\n
<\/figure>\n
<\/figure>\n
<\/figure>\n
<\/figure>\n
<\/figure>\n
<\/figure>\n
<\/figure>\n