In this part of the migration series, I am going to take a look at moving an existing Sitecore Experience Platform (XP) “Worldwide Brand name” service, with numerous websites and deep customization use, over to Sitecore XM Cloud and Sitecore Personalize. Follow the series to take a look at various Sitecore XM and XP situations and how you can slowly move your Sitecore platform service over to a composable DXP architecture

The objective is to stroll through the example migration and emphasize for you:

• What difficulties will you deal with along the method?
• What alternatives are readily available and when do they make good sense?
• What are the advantages of ensuring modifications to your architecture?

Every job is a little bit various, so ideally this series can assist you comprehend a few of the concerns to ask, and what alternatives you have, to direct you in the ideal instructions.

The “Worldwide Brand name” beginning point

Some clients can have extremely intricate Sitecore applications. In some cases you have years of technical financial obligation, great deals of different application setups, various methods of constructing websites, various methods of releasing, various variations.

For this circumstance, we are taking a look at an international brand name that is doing shipment all around the world, with numerous websites. A few of websites are long-lived, multilingual, and multiregion websites like the main business brand name websites. Others are short-term project microsites that spin up and after that spin down when the project is done. Customization has actually been carried out on the majority of the bigger websites, and a few of the project websites.

In this circumstance, the consumer is presently running various separated circumstances of Sitecore XP in numerous areas, with various variations. Some are on variation 9, others on variation 10. They have various Sitecore xDB information shops for the various areas to consult with local information compliance guidelines, and the company has numerous various authoring areas to support all their brand names and various marketing groups around the globe.

The requirement to provide worldwide is an essential and the company wants to unload a few of the duty for this shipment facilities scaling, along with the general management of the Sitecore material and customization facilities.

From an execution point of view, the dev groups have actually been constructing with various tech for many years. Much of the websites are standard MVC or SXA websites, though a couple of are now running headless with Sitecore JSS on React or Next.js.

Not precisely the most convenient roadway to SaaS in front of this group!

In this circumstance, the consumer had actually currently begun moving towards a dispersed mesh of incorporated systems. There are numerous supplier services in their architecture such as a DAM, a CDN, a SaaS marketing automation tool, and others. They now wish to align their Sitecore application facilities with this architecture method and lastly go totally headless and SaaS hosting.

Action 1: Track with Sitecore Personalize

The primary step on this roadway is including Sitecore Customize into the mix so that we can begin tracking visitors. This will begin developing the visitor information and guarantee that any website that moves over to Sitecore Personalize will have information currently occupied. Any brand-new websites that get released, like a brand-new project website, might likewise be begun instantly on Sitecore Personalize without utilizing Sitecore XP customization.

Why is this an excellent concept?

Including Sitecore Personalize in at this phase to any website is a reasonably low effort for the technical group, as soon as the occupants are set up. By doing Sitecore Personalize initially while still utilizing Sitecore XP enables the company to slowly move the customization from Sitecore XP to Sitecore Personalize. There are just a lot of websites and excessive customization currently constructed into this circumstance to do a total “lift and shift” for all the websites at the exact same time.

Furthermore, this enables the tool to be presented to the consumer groups slowly. As more groups are employed, the company can fine-tune its onboarding procedure for each brand name. Each group can begin finding out and constructing out customization guidelines inside Sitecore Personalize, with Sitecore XP still dishing out the existing customization guidelines while they discover.

This method likewise implies that we lower the variety of brand-new Sitecore XP customization guidelines being constructed, that makes the later migration effort simpler.

Things to look out for

One disadvantage to this method is that we begin having various analytics information in various shops. Groups are most likely currently utilizing Google Analytics, and numerous Sitecore xDB sources, and are now including Sitecore Personalize tracking into the mix. If there are groups doing reporting, this might include some trouble to their capability to report on information. One alternative here would be to overlook Sitecore Personalize information in reporting up until a website is finished moved off of Sitecore XP.

There can likewise be some confusion when attempting to identify where a customization is originating from with 2 customization systems performing at the exact same time. It is most likely finest to attempt to ensure an offered website or page is not utilizing both Sitecore XP customization and Sitecore Personalize guidelines at the exact same time. This will make it simpler for execution groups to separate where customization problems may be taking place and prevent possible disputes.

Action 2: Go to the Edge

At this moment we’re going to presume that the groups have Sitecore Personalize contributed to the websites. The customization guidelines might not have actually moved totally yet, however we are presuming that tracking remains in location. Now we wish to concentrate on minimizing that huge Sitecore material shipment layer. We wish to lower the variety of Sitecore material shipment circumstances that are needed to satisfy visitor needs.

By including Sitecore Experience Edge as a layer we can roll content shipment caching worldwide, suggesting that ask for material do not require to return to the Sitecore CD layer. This implies that apps like Next.js can release a fixed website to a host like Netlify or Vercel and get the information from an edge layer, rather of returning to origin each time, eventually accelerating construct times and minimizing the requirement for Sitecore CD circumstances.

However to get that benefit, that implies we require to transfer to fixed websites, as much as possible, to put our end user website hosting onto a SaaS shipment platform. To arrive, the execution group requires to line up to the most recent Sitecore XP variation which has the Next.js JSS SDK.

Is fixed releasing a faster way?
A few of these websites might be simpler to transfer to Next.js than others. Restoring a lot of MVC websites may not be the very best alternative today, however we can benefit from fixed publishing abilities presented in Sitecore XP 10.2 and move some MVC/SXA websites to Next.js shipment with less effort utilizing the brand-new SSG publishing of websites guide. It must be kept in mind that this is for particular kinds of websites, and some complex websites may not be the ideal suitable for fixed website publishing, which implies they might require more of a rework. It’s most likely best to target content-only websites initially.

Transferring to fixed shipment
Moving over to a fixed method is most likely to include a great deal of coordination of groups, however this procedure can be done slowly. One secret is to very first recognize which websites are going to be retired and will not be moved, hence minimizing the general effort.

As these applications transfer to fixed shipment, the requirement for the existing Sitecore material shipment facilities will decrease. It is possible to even target parts of a website to shift to fixed, and benefit from routing setup to dish out specific paths from the existing facilities while you move.

When total, many visitor traffic need to now be going to the fixed website shipment layer. There will still be a requirement for a high accessibility Sitecore CD layer, however. These staying circumstances will react to server-side ask for XP customization or other requirements that have not been moved. Sadly, we can’t remove all of it right now.

Why is this an excellent concept?

By constructing an architecture with Next.js+ Experience Edge+ SSG business will get a couple of huge advantages without doing a complete restore of all the applications and websites. With Sitecore Experience Edge and fixed websites, groups need to have the ability to improve international core web vitals, with less effort, which will benefit general consumer experience and SEO.

The continuous requirement for international shipment likewise ends up being a lot easier to accomplish, and more easy to broaden into brand-new areas and target with brand-new projects. All of this likewise integrates with less duty for the shipment facilities, unloading that to Experience Edge and the fixed website host.

This method likewise enables slowly moving applications and particularly targeting websites where the very best Roi (ROI) will be.

Things to look out for

There are a couple of things to think of. I discussed lining up to Sitecore variation 10.2 to get access to the tools you require for the fixed website publishing, plus lining up much better to the ultimate transfer to XM Cloud. Upgrades are typically not unimportant, particularly when moving from earlier variations. If a specific website is on a variation prior to Sitecore XP variation 9, it might be much better ROI to do a complete rebuild/redesign job for that website and construct straight onto the SaaS host instead of attempting to move slowly through these phases. (This presumes the website is being prepared to be kept at all.)

Likewise, any heavy customization websites will not be seeing much take advantage of this shift, unless the marketing group has actually currently been moving customization guidelines to Sitecore Personalize. If the websites utilize heavy server-side customization, they’ll be pinging back to the existing Sitecore CD layer, and bypassing the advantages of the fixed shipment layer. If we truly wish to lower the material shipment load here for websites that have a great deal of server-side customization, those websites need to most likely begin transitioning to Sitecore Personalize as early as possible to lower the variety of demands back to the CD layer.

One last thing to watch out for is the match of MVC websites to fixed publishing. As much as I want it was, the fixed publishing readily available with Sitecore XP 10.2 isn’t magic and will not be a suitable for all websites. Today, it does have some restrictions that require to be thought about (no multilingual, no media library, forms restrictions, other restrictions). If a website isn’t a suitable for SSG publishing, among the other techniques to get to Next.js need to be taken a look at for that website.

Action 3: Shift to XM

It’s time to keep carrying on. Now that we have actually transitioned a great deal of the traffic to edge shipment, it’s time to begin removing all that handled XP facilities that is not going to be utilized. This implies moving the customization in Sitecore XP over to Sitecore Personalize.

Why is this an excellent concept?

Getting to this point and removing all that XP facilities significantly lowers what the group is accountable for preserving.

This architecture is likewise extremely near what will be utilized in a Sitecore Composable DXP circumstance with XM Cloud and Experience Edge, so we’re practically prepared for that relocation.

Lastly, by totally embracing Sitecore Customize the company is better to that totally composable architecture and this opens chances for headless customization throughout other channels too.

Things to look out for

One obstacle is that Sitecore Personalize does not set up or perform in the exact same method that Sitecore XP does. Sitecore Personalize is likewise not natively incorporated into the Sitecore XM editor (at the time of composing). Contribute to that the reality that the information migration is not an easy push or a 1:1 mapping, and this migration may suggest a great deal of digital method is required to plan how to accomplish business objectives of customization in a various method.

Some clients in this circumstance might currently have another CDP in play, in which case moving xDB information into Personalize or SmartHub CDP isn’t an excellent ROI. The information need to go to the existing CDP and after that Customize need to incorporate with that CDP to get the information.

One last thing to discuss is that transitioning to XM can be done a couple of various methods:

1. Upgrade: As part of an upgrade to a brand-new variation.
2. In-place: Make the modification “in-place” on the existing setup.
3. Lift-and-shift: Move to a brand-new XM setup.

We have actually seen that some clients who attempt to do an in-place shift start getting rid of performance and there are recommendations that do not get effectively gotten rid of. A lift-and-shift to brand-new facilities is most likely the very best method to guarantee that your target facilities just has the XM performance, however this now includes a content migration effort into your shift.

However what if …?

At this phase, there are a couple of things that you may wish to select to do in a different way.

For instance, rather of the Sitecore xDB information migration, a group might select to avoid that action and simply utilize the collected session information from Sitecore Personalize that was presented in the earlier phase.

Another thing to think about is using separated occupants. Consumers of this size might require to utilize different Sitecore Personalize applications, or they might require various tiers of performance for various groups, or maybe they require to divide by area. In some cases this may suggest one group requires a lighter-weight Sitecore Personalize for some situations, however other groups require to utilize a complete CDP performance for something else. Any variety of these situations might suggest the architecture does not have a single “Customize” box in the architecture.

Action 4: Move to Next.js JSS

By this phase we now have a Sitecore XM facilities utilizing Experience Edge with headless customization. A few of those MVC websites are still depending upon that fixed publishing function to get us here, and a few of the websites are still counting on previous modifications that had actually been presented on the CD layer. The next objective is to take the brand-new Sitecore XM architecture and finish the application migration to Next.js without Sitecore CDs.

The very first top priority is to eliminate any possible modifications or Sitecore CD dependences and transfer to totally Next.js applications. This application reasoning will normally move into your Next.js application, however you’ll require to take a look at what the reasoning is doing and identify where it fits finest (service layer, edge functions, and so on)

The group likewise requires to ensure that any staying MVC/SXA websites that were counting on the fixed publishing function from the earlier phase have actually been entirely remodelled to real Next.js headless applications.

This work can constantly begin throughout earlier phases, however what we are going for at this moment is to ensure we have actually finished the complete migration off of MVC/SXA and CD modifications for all websites.

Why is this an excellent concept?

In order to remove the Sitecore XM facilities, we require to very first remove the dependence on Sitecore material shipment circumstances. That implies that our Next.js applications require be pulling whatever totally from Sitecore Experience Edge and API calls, without any dependence on modifications or server-side making. This action guarantees the staying architecture is prepared for relocating to XM Cloud.

Things to look out for

Similar To in the XM Jamstack circumstance, we deal with the obstacle of material shipment modifications. We need to eliminate these modifications and reconsider them in a headless method. This is not constantly uncomplicated as you might have been utilized to constructing modifications versus Sitecore pipelines which can modify output at a particular point in the rendering cycle. You’ll require to discover the comparable method in your Next.js application.

Furthermore, with this numerous websites working on SXA or MVC, there might be performance counting on CD server session info. Those requirement to be resolved for in a headless method on the fixed website. Sadly, this is so scenario-specific there isn’t much assistance that can provided here besides to discover it and change it.

Step 5: Move to XM Cloud

Lastly, it’s time to remove the Sitecore XM facilities! The architecture has actually been prepped into a Jamstack design, similar to in the XM Jamstack circumstance. All of the Next.js applications have actually reached a state for a smooth shift. Our objective is to eliminate the Sitecore XM facilities and change it with Sitecore XM Cloud facilities rather, which will be the duty of Sitecore to handle.

One or numerous XM Cloud circumstances?
Among the lengthy parts of this job will be the content migration. Material should move from our Sitecore XM circumstances into Sitecore XM Cloud for all areas and all websites. In this circumstance, we began with numerous Sitecore material repositories, which implies we may have material disputes if we press all the material repositories together into a single XM Cloud. Even without disputes, there might be other company factors to keep a few of the material repositories different.

For this factor, we might in fact desire numerous XM Cloud circumstances in various areas. We advise releasing based upon particular projects/teams as required. From an architecture point of view, material reuse might be a huge choosing aspect on when you’ll wish to share XM Cloud circumstances throughout groups.

Where should XM Cloud be?
Another aspect to think about is the distance to the material group. The preliminary variation of Sitecore XM Cloud is not going to support geo-replication throughout various areas, which implies that it is utilizing a single origin in one area.

Tearing it down!
As Soon As all of that material has actually moved into the proper XM Cloud circumstances and the applications have actually been pointed at the brand-new Experience Edge layer, it is now time to take down the Sitecore XM applications and the underlying storage and platform. No more Sitecore application facilities in your environment!

With the last littles the Sitecore XM Facilities gone, the facilities is now totally transitioned to the supplier services layer. The technical group now has a totally headless architecture with a composable network of applications.

Through these actions, the applications have actually transitioned from layers of application and facilities duty to a network of linked SaaS point services, fixing particular requirements with the ideal tool for the task. Now the group can concentrate on bringing these pieces together and including extra performance to their service by presenting right pieces at the correct time.

View the session!

I tape-recorded a session with Pieter Brinkman (@pieterbrink123) discussing the migration from the Sitecore platform to the Sitecore Composable DXP. You can enjoy it on YouTube now!

Other posts in this series

You can get a listing of all released posts utilizing the tag: sitecore-guide-to-saas-migration

1. XM Jamstack circumstance
2. XP Worldwide brand name [YOU ARE HERE!]
3. XP Marketing Automation [COMING SOON!]