In this part of the migration series, I am going to look at migrating an existing Sitecore Experience Platform (XP) solution that has been built as a classic Sitecore MVC implementation with simple personalization implemented.

The scenario breakdown:

• Single MVC site built on Sitecore XP 8.2
• Basic session-based personalization in use, primarily using Geo IP to determine user location and campaign IDs in the URL
• No SXA or Sitecore JSS in use
• No custom site search, using third party search engine for site search
• Development team is all .NET developers, no desire to move to a JavaScript framework

Follow the series to look at different Sitecore XM and XP scenarios and how you can gradually migrate your Sitecore platform solution over to a composable DXP architecture.

The goal is to walk through the example migration and highlight for you:

• What challenges will you face along the way?
• What options are available and when do they make sense?
• What are the benefits of making certain changes to your architecture?

Every project is a little different, so hopefully this series can help you understand some of the questions to ask, and what options you have, to guide you in the right direction.

The Classic XP with Simple Personalization starting point

In this example, the customer is running on an older version of Sitecore XP that just went out of extended support. They are looking to get back into a supported deployment model so they can get security fixes and patches. The site was last refreshed about 5-7 years ago, depending on which part of the site you look at, and all of it was built by the implementation team using traditional Sitecore MVC. At the time, SXA and JSS were not part of the Sitecore XP license being used so the team built without these modules. Currently, there is only a single corporate site being run, and all campaigns are run through landing pages on the main domain.

There has been some personalization implemented. The team has defined some campaigns in Sitecore XP and personalizes a few banners or promotion components if somebody reaches a landing page based on a specific campaign ID. A few promotional components will also switch the content based on the geographic location of the visitor. On the home page, there is some updated text to welcome a user back when they return, whereas new visitors see a standard welcome message. In general, there are only a few variations for each page.

The brand team wants to do a refresh of the site, and the technical team is taking advantage of this to propose a modernization of their solution to a headless architecture that better aligns with the way the industry is headed. Marketing does not want to lose their current WYSIWYG content editing or personalization functionality in the process but they are open to adjusting how this is being done.

The big question: Should this be a Platform DXP upgrade or a Composable DXP migration?

The choice here is between upgrading Sitecore XP to the latest version, or transitioning to XM Cloud. Industry-wide, many businesses are choosing to slim down and focus on business priorities instead of running IT infrastructure. In this case, the IT team is really leaning towards pushing the responsibility for the infrastructure over to Sitecore so that they can focus on developing features for the site and supporting the business IT needs. The business doesn’t have any specific requirements around controlling the infrastructure or data storage, so the SaaS hosting model works for them. After looking at the Sitecore XP 10.x new infrastructure for xDB and xConnect services, they are also not keen to add on all that infrastructure to their existing systems.

It’s no surprise that, in an article about migrating to SaaS, this scenario is a good fit for SaaS hosting of their stack!

However, a few things could have influenced their decision, and led to an upgrade, staying on the Platform DXP:

1. Recent refresh investment.
   If the business had invested very recently in refreshing the site, they likely aren’t going to be up for another big investment right now to purchase new software and services, and move to a headless architecture. Since MVC renderings are not currently supported in XM Cloud, this would mean that the team would choose to go for an upgrade project instead and keep using the platform with their current solution approach.
2. Recent upgrade that supports headless.
   In the described scenario, the team was on an older version that wasn’t supported and were running Sitecore MVC. However, what if they had already done an upgrade project to a more recent version and obtained access to SXA and JSS? In that case, they might get a lot more benefit staying on their current system and transitioning gradually towards using Experience Edge and Headless SXA, and then ultimately XM Cloud. Sort of like what was seen in the XM Jamstack scenario. The move to a SaaS offering could come later, without needing to reinvest as much right now.
3. Very rigid infrastructure or data control requirements.
   In some industries or organizations there is a need to tightly control access to certain elements of the infrastructure, or place the infrastructure in very specific regions. This is definitely a place where Sitecore’s Platform DXP plays well. A Sitecore Managed Cloud solution, for example, might be a better fit here so the team can offload some infrastructure responsibility but still maintain a very large control over the infrastructure.

There could be other factors as well applying pressure one way or another, but at the core you want to choose the option that gets you the best return on investment and aligns best with your business needs.

Step #1 to Composable: Migrate content to XM Cloud

In my other XP guides, the first thing I suggested was adding Personalize right away to get the tracking going and make it easier to gradually move over. But we don’t need that here! The site’s personalization needs session-based primarily, not really relying on visitor history, and are firmly within what can be handled with embedded personalization in XM Cloud. That means we don’t need to get a separate Personalize application right now. Maybe one day, but for now, it’s best to keep things simple.

Instead, we’re going to move over as much content as possible. Since the brand team wants to do a refresh, there might be new content items that are needed, or old content items that can be dropped, so you might not need everything.

Why do this step?

The marketing team has put a lot of effort into the content on the website, and it’s unlikely it will all be dropped. Even just focusing on media like imagery, white papers, PDF files, guides, product data sheets… moving these gives you a big step up. Since XM Cloud is based on the Sitecore XM data model, you can most likely import all of this as is. You will then be able to use this content later during the build of the new site. That being said, it is usually recommended that you do an audit of your content and clean it up to make sure that you aren’t moving over unused, outdated, or irrelevant content.

Things to watch out for

Custom modules

In many existing solutions there are custom modules that have been installed from the community or from third-party vendors to provide additional functionality that doesn’t come out-of-the-box with Sitecore XM or Sitecore XP. With Sitecore XM Cloud, customers currently cannot install modules directly so these modules need to be identified, analyzed, and then a new plan made for how to include that functionality in your solution.

Sitecore Forms no longer available

A specific thing to watch out for in the content migration is the use of Sitecore Forms (or WFFM on an older build). Right now, this content can be moved over as items but the Sitecore Forms functionality is not available in XM Cloud, so probably should be excluded and then refactored to a headless solution.

Unnecessary presentation details

A Sitecore MVC build usually has a lot of presentation details on the content items that help pull everything together for the layout. These aren’t going to work in XM Cloud, and also won’t match to the new UI designs. After bringing the content into XM Cloud, the team likely has to scrub the presentation details out and build new presentation using Pages that matches to the new refreshed design templates and renderings.

Big changes from really old versions

In this case, the team has Sitecore XP 8.2 which isn’t the oldest version they could go from, but it is still a significant change in versions to go to XM Cloud. There will be a lot of new features and default data model changes introduced across the versions, plus adding in SXA and JSS concepts. The team will likely want to treat their existing site content as raw data to work from and build new site structures using the headless SXA scaffolding feature that then reuse the content as data sources, where possible.

Misalignment to new design

One common thing that happens during a refresh is a complete review of the information architecture of the current site. A lot of content might get dropped, or completely restructured. There might be a request for a lot of new content. This can be a pain when the dev team puts in the work to automate some content migration but then the new design makes it irrelevant. I suggest waiting on design and content decisions for the new site BEFORE making decisions on content migration. This will slow you down, but make it a lot easier to migrate your content appropriately.

Content freezes and duplication

Typically there is a period of time where both the current site and the new site’s content need to be kept in sync. Many teams keep both sites up to date manually and then eventually freeze content entry during the production transition. Automation for this is rarely worth the effort.

Step #2: Implement the new design on XM Cloud

This is a classic “side-by-side” approach where you keep your current architecture up while building the new headless implementation on the new infrastructure. In this case, you’ll use XM Cloud as the new hosted infrastructure.

During a design refresh, an agency will usually provide an HTML mockup or sample implementation, or potentially a wireframe example. The goal at this stage is to take that design and build it out in your desired headless language, connected to your XM Cloud CMS using the Sitecore headless SDK.

I make it sound easy here, but this step is usually a bit of work. Sitecore ships a Next.js sample so you can see how to hook into the SDK, so that’s a good starting point to learn. Check out the XM Cloud learning resources on the Developer Portal, including open source repos.

In this particular scenario, the team is very skilled in .NET. Most of the Sitecore documentation, samples, etc. are focused on Next.js and Typescript, though. For a lot of teams, this transition to Next.js is fine, but some teams would rather reuse their C# logic and skills in a headless application. ENTER THE ASP.NET RENDERING SDK!

With the .NET headless SDK, this team can use a lot of the business-specific logic that was built for the existing site, but instead connect to Sitecore XM Cloud headlessly.

Why do this step?

In this scenario, a refresh was already planned to happen. This is the perfect time for the technical team to make sure the new site build has the headless architecture they want, and move the hosting to SaaS.

Choosing the .NET headless SDK will increase their initial startup time for any proof of concepts that are being done, since the samples are in Next.js right now, but over the course of the project the team will likely save build time by using their existing technology knowledge with .NET. They get to use what they know and have all the features that XM Cloud provides!

Things to watch out for?

Remove Sitecore Content Delivery (CD) logic and dependencies

When migrating the existing Sitecore MVC application over, there may be some logic that depended on running on the Sitecore CD server. These might be pipelines that were injected into the config, or specific presentation controls that had been built assuming use of the Sitecore MVC rendering engine. These sorts of dependencies will likely need to be removed so that the new app can be built headlessly and consume the Experience Edge API instead.

.NET + Embedded Personalization SDK must be invoked directly

On the .NET front, there is also a caution around the Engage SDK that will drive the personalization in XM Cloud. XM Cloud Embedded Personalization was built specifically for Next.js and does not currently support the .NET headless rendering host. Page view events can be captured using the Sitecore Engage SDK directly, though. You can look at this walkthrough for setting up the Engage SDK.

Content and examples mostly focus on Next.js

Another thing to watch out for is community documentation and support. A lot of Sitecore and community content (and also in the industry) has been very hyper-focused on front-end frameworks over the last several years. While there are a lot of community members who have built out .NET MVC applications on the platform DXP, most of the community members working with XM Cloud have chosen a front-end framework like React or Next.js. This will initially mean less community support until the Sitecore .NET community catches up and creates more content about using .NET with XM Cloud.

Step #3: Launch XM Cloud and take down Sitecore XP

In some more risk-averse organizations, they may want to wait until all steps are done before launching. I believe it is best to launch early and get a return on the investment as early as possible. The team hasn’t done the personalization bit yet, but other than that there’s a fresh new site that everybody is excited about. And nobody can see it right now!

Not to mention that every day that goes by the content authoring team needs to keep two sites up to date with content updates.

Launching the site at this point, even without personalization, allows the team to transition fully into XM Cloud and roll forward from here. The team can also start recouping infrastructure costs of running side-by-side implementations.

REMEMBER: You will want to have a local developer installation of Sitecore XP and a copy of your current production database available for referencing the existing personalization implementation. During the next step you will test and validate your new XM Cloud personalization against the original implementation.

Step #4: Implement personalization variants

The previous step is likely going to take the biggest amount of time to get right, but once the new design is implemented and authors can begin managing the site content, it’s time to start moving personalization over from XP to XM.

• Read more about the embedded personalization features of XM Cloud in the Embedded Personalization FAQ on the Sitecore Developer Portal.
• There’s documentation too! Learn about creating targeted digital experiences.

A general approach that can be taken is to look at your pages in Sitecore XP and the personalization variations that had been created. In Sitecore XP, personalization rules are typically set at a component level. There are likely a limited number of variations in your existing pages, based on the user that would come in with this type of scenario.

The key here is to document those page variations. These are essentially your target audiences that you want to personalize for. From this list, you want to identify the key variants you still want to keep on the new site with the new content, and then implement XM Cloud page variants to target your audiences with the new XM Cloud personalization rules.

Why do this step?

In this scenario, the team had already implemented personalization on their existing site. They were using this to increase engagement and customer loyalty, to make customers feel connected with the brand. At this point, they have launched the main site on XM Cloud but they are still missing that key piece. The digital marketing team should likely analyze what value they were getting from their existing personalization strategy, as that will impact how they do this step.

From a return on investment perspective, it’s also important to get the most out of what XM Cloud can deliver. Implementing analytics and personalization is a key piece to making sure the business is getting full value for what they are paying for.

Things to watch out for?

XM Cloud embedded personalization != XP personalization

A key piece to look out for is that XM Cloud’s embedded personalization is not at all the same as the personalization rules in XP. While some have similar concepts, this is not a copy/paste job.

In this particular scenario that I’ve described, XM Cloud has some well-matched capabilities to what the fictional customer is using. There is geolocation that can cover the regional personalization scenario here. There is also a concept of personalizing via UTM codes, which is similar to the campaign IDs that were used previously in Sitecore XP. For the ‘welcome back’ personalization, this can be accomplished using the check for whether a user is new or returning. However, not all XP rules have an equivalent in XM Cloud, so the analysis will determine if Personalize might be needed.

Limitations on variants/conditions

Specific to the embedded personalization in XM Cloud, it should be noted that there is a limit of 8 page variants per page, and only five conditions per page. That is fine for this specific scenario that has limited variations, but in your scenario you may need to trim down the number of variations you have or add a full Sitecore Personalize to get additional options.

Mismatch of previous personalization to new UX

Another thing to keep in mind is that in this scenario, there is a massive refresh happening to overhaul the site. This could drastically affect both the UX and the information architecture. The previous personalization implementation may no longer map well to the new design.

Thanks for reading through and keep tuned for more scenarios!

Other articles in this series

You can get a listing of all published articles using the tag: sitecore-guide-to-saas-migration

1. XM Jamstack scenario
2. XP Global brand
3. XP Marketing Automation
4. Classic XP with Simple Personalization [YOU ARE HERE!]