XP-GlobalBrand-Starting Point.png

In this a part of the migration collection, I’m going to have a look at migrating an current Sitecore Experience Platform (XP) “Global Brand” 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 your Sitecore platform answer over to a composable DXP structure.

The objective is to stroll by the instance migration and spotlight for you:

  • What challenges will you face alongside the way in which?
  • What choices can be found and when do they make sense?
  • What are the advantages of constructing sure adjustments to your structure?

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.

The “Global Brand” place to begin

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.

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.

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

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. 

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 JSS on React or Next.js. 

Not precisely the best highway to SaaS in entrance of this workforce! 

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.
 

Step 1: Track with Sitecore Personalize

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

XP-GlobalBrand-Step1.png

Why is that this a good suggestion?

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 “raise and shift” for all of the websites on the similar time. 

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. 

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.
 

Things to be careful for

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.

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.

Step 2: Go to the Edge

At this level we’re 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.

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

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.

XP-GlobalBrand-Step2.png

Is static publishing a shortcut?
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 SSG publishing of web sites information.  It 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’s in all probability finest to focus on content-only websites first.

Moving to static supply
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’t be migrated, thus decreasing the general effort.

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.

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’t been migrated. Unfortunately, we are able to’t remove all of it simply but.

Why is that this a good suggestion?

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

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.

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.
 

Things to be careful for

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

Also, any heavy personalization websites received’t 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’ll 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.

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’t magic and received’t 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’t a match for SSG publishing, one of many different strategies to get to Next.js ought to be checked out for that website.
 

Step 3: Transition to XM

It’s time to maintain transferring on. Now that we’ve transitioned a whole lot of the site visitors to edge supply, it’s 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.

XP-GlobalBrand-Step3.png

Why is that this a good suggestion?

Getting so far and eliminating all that XP infrastructure drastically reduces what the workforce is answerable for sustaining.

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’re virtually prepared for that transfer.

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.
 

Things to be careful for

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.

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’t 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.

Want extra particulars about migrating to Sitecore CDP/Personalize?

My colleague Dylan Young wrote a pleasant article to assist with a number of the selections round migrating to Sitecore CDP or Sitecore Personalize. It could be useful as you propose this step!

One last factor to say is that transitioning to XM could be finished just a few other ways:

  1. Upgrade: As a part of an improve to a brand new model.
  2. In-place: Make the change “in-place” on the prevailing set up.
  3. Lift-and-shift: Migrate to a brand new XM set up. 

We have seen that some clients who attempt to do an in-place transition begin eradicating performance and there are references that don’t get correctly eliminated. A lift-and-shift to new infrastructure might be one of the best ways to make sure that your goal infrastructure solely has the XM performance, however this now provides a content material migration effort into your transition.
 

But what if…?

At this stage, there are some things that you simply would possibly wish to select to do in a different way.

For instance, as an alternative of the Sitecore xDB knowledge migration, a workforce might select to skip that step and simply use the gathered session knowledge from Sitecore Personalize that was launched within the earlier stage.

Another factor to think about is using remoted tenants. Customers of this dimension might have to make use of separate Sitecore Personalize purposes, or they might want totally different tiers of performance for various groups, or maybe they should divide by area. Sometimes this would possibly imply one workforce wants a lighter-weight Sitecore Personalize for some eventualities, however different groups want to make use of a full CDP performance for one thing else. Any variety of these eventualities might imply the structure doesn’t have a single “Personalize” field within the structure.

Step 4: Migrate to Next.js JSS

By this stage we now have a Sitecore XM infrastructure utilizing Experience Edge with headless personalization. Some of these MVC websites are nonetheless relying on that static publishing function to get us right here, and a number of the websites are nonetheless counting on earlier customizations that had been launched on the CD layer. The subsequent objective is to take the brand new Sitecore XM structure and full the applying migration to Next.js with out Sitecore CDs.

XP-GlobalBrand-Step4.png

The first precedence is to take away any attainable customizations or Sitecore CD dependencies and transfer to completely Next.js purposes. This utility logic will normally transfer into your Next.js utility, however you’ll want to have a look at what the logic is doing and decide the place it suits finest (service layer, edge capabilities, and so forth.)

The workforce additionally must guarantee that any remaining MVC/SXA websites that have been counting on the static publishing function from the sooner stage have been utterly reworked to true Next.js headless purposes.

This work can all the time begin throughout earlier levels, however what we’re aiming for at this level is to ensure we’ve got accomplished the total migration off of MVC/SXA and CD customizations for all websites.

Why is that this a good suggestion?

In order to remove the Sitecore XM infrastructure, we have to first remove the dependency on Sitecore content material supply cases. That signifies that our Next.js purposes want be pulling all the things totally from Sitecore Experience Edge and API calls, with no reliance on customizations or server-side rendering. This step ensures the remaining structure is prepared for transferring to XM Cloud.

Things to be careful for

Just like within the XM Jamstack state of affairs, we face the problem of content material supply customizations. We should take away these customizations and rethink them in a headless means. This will not be all the time easy as you might have been used to constructing customizations towards Sitecore pipelines which might alter output at a particular level within the rendering cycle. You’ll want to search out the equal method in your Next.js utility.

Additionally, with this many websites operating on SXA or MVC, there could also be performance counting on CD server session info. Those have to be solved for in a headless means on the static website. Unfortunately, that is so scenario-specific there isn’t a lot steerage that may given right here aside from to search out it and change it.

Step 5: Migrate to XM Cloud

Finally, it’s time to tear out the Sitecore XM infrastructure! The structure has been prepped right into a Jamstack mannequin, similar to within the XM Jamstack state of affairs. All of the Next.js purposes have reached a state for a clean transition. Our objective is to take away the Sitecore XM infrastructure and change it with Sitecore XM Cloud infrastructure as an alternative, which would be the duty of Sitecore to handle.

XP-GlobalBrand-Step5.png

One or a number of XM Cloud cases?
One of the time-consuming elements of this process would be the content material migration. Content should transfer from our Sitecore XM cases into Sitecore XM Cloud for all areas and all websites. In this state of affairs, we began with a number of Sitecore content material repositories, which implies we’d have content material conflicts if we push all of the content material repositories collectively right into a single XM Cloud. Even with out conflicts, there could also be different enterprise causes to maintain a number of the content material repositories separate.

For this purpose, we may very well need a number of XM Cloud cases in several areas. We suggest deploying based mostly on particular initiatives/groups as wanted. From an structure perspective, content material reuse could also be an enormous deciding issue on whenever you’ll wish to share XM Cloud cases throughout groups.

Where ought to XM Cloud be?
Another issue to think about is the proximity to the content material workforce. The preliminary model of Sitecore XM Cloud will not be going to assist geo-replication throughout totally different areas, which signifies that it’s utilizing a single origin in a single area.

Tearing it down!
Once all of that content material has moved into the suitable XM Cloud cases and the purposes have been pointed on the new Experience Edge layer, it’s now time to tear down the Sitecore XM purposes and the underlying storage and platform. No extra Sitecore utility infrastructure in your setting!

XP-GlobalBrand-VendorSolutions.png

With the ultimate bits of the Sitecore XM Infrastructure gone, the infrastructure is now totally transitioned to the seller options layer. The technical workforce now has a totally headless structure with a composable community of purposes.

Through these steps, the purposes have transitioned from layers of utility and infrastructure duty to a community of related SaaS level options, fixing particular wants with the suitable software for the job. Now the workforce can give attention to bringing these items collectively and including extra performance to their answer by rolling out proper items on the proper time.

XP-GlobalBrand-ComposableCloud.png

Watch the session!

I recorded a session with Pieter Brinkman (@pieterbrink123) speaking in regards to the migration from the Sitecore platform to the Sitecore Composable DXP. You can watch it on YouTube now!

Other articles on this collection

You can get a list of all printed articles utilizing the tag: sitecore-guide-to-saas-migration

  1. XM Jamstack state of affairs
  2. XP Global model [YOU ARE HERE!]
  3. XP Marketing Automation [COMING SOON!]



Source link