Sitecore Architect’s Guide to SaaS Migration – XP Marketing Automation

In this part of the migration series, I am going to look at migrating an existing Sitecore Experience Platform (XP) solution that has implemented marketing automation, including email marketing.

The scenario breakdown:

• MVC site built on Sitecore XP
• Multiple delivery regions
• Heavy personalization usage on components and multiple profiles defined
• EXM used for customer email marketing
• Marketing Automation plans triggered by events on the website
• Integrated with a third-party CRM for customer data

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.

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 XP Marketing Automation starting point

In this scenario, we have a long-time Sitecore Experience Platform (XP) solution that has taken advantage of a lot of XP capabilities. The development team has implemented a traditional MVC application that runs directly on Sitecore Content Delivery (CD) instances.

The development team has been looking at Next.js as a possibility for the future but have felt that their heavy use of personalization would require them to run SSR more than static with client-side personalization. A migration to headless would require migrating that personalization as well.

The team has gotten a great return on investment by taking advantage of the full breadth of capabilities. They have a scaled xDB storage of user data, with load-balanced xConnect services to support their performance needs. They have implemented a lot of personalization rules on components and have several profiles configured. The digital strategy team have configured multiple marketing automation plans and have also built out email marketing with Email Experience Manager (EXM) to execute regular outreach to their customer base.

To execute their marketing automation, they have integrated into other systems in their stack like their CRM and some back-office systems that provide additional data on the site and about their visitors. Their CRM is considered the ‘source of truth’ about customer data.

To handle their global delivery needs, they have rolled out a few different delivery clusters that are critical to their current target customer regions. This is similar to what we saw in the XP Global Brand scenario, but not as large of an infrastructure footprint.

This complex implementation led to a robust infrastructure that must be maintained. The business is looking to focus more on key business projects and wants to reduce the responsibility for their digital infrastructure, especially as they look to expand across more regions in the coming years. They are not willing to cut functionality but want the infrastructure to be easier to manage. Ideally, no responsibility at all.

Should we even be migrating this solution to SaaS?

I initially thought about adding EXM into the earlier scenarios, but decided to save it for its own post because EXM is a tricky one! Marketing automation functionality is in this scenario too, as these are often used together. In Sitecore’s composable DXP, you can use Sitecore Send as an alternative for marketing automation and email marketing. You can even import your lists from XP to help with the migration. So, there is a possible path for migration to Sitecore composable solutions, but even if the business wants to focus less on infrastructure management, is it the right thing to do?

Here are a few things to consider when looking at a migration for this specific scenario:

1. EXM is not Send.
   The two products are very different and the vision for how they solve business problems is very different. This is not a data migration, but a full feature replacement (some data can be migrated, like contact lists). Outside of data, functionality is different as well. For example, EXM can use component-based personalization, leveraging visitor data in xDB. Sitecore Send has a personalization capability that can tailor messages, offers, and tone based on customer’s details and segments, but these are not the same features.

2. There is a non-trivial rebuild effort.
   There is no import of your EXM templates or marketing automation configurations into Sitecore Send, so this will require a rebuild of those parts. There will also be little content sharing or personalization integration (at the time of writing) as was previously had with EXM, so there is a loss of functionality if that is being used. (Note that the integrations with Sitecore Content Hub and Sitecore Personalize are still in progress on the roadmap and may be available at the time you are reading this. At the time of writing, the only integration available is for images in the Sitecore Content Hub DAM).

3. Dependency updates are needed.
   The head application (typically your website or mobile app) likely has some sort of triggers built in to trigger Marketing Automation or EXM. These will definitely need to be updated to the new products.

4. No native visitor interaction data integration.
   With EXM and Marketing Automation features in Sitecore XP, the xDB data is right there in the system. The platform has full native integration with personalization, content, and visitor data. By moving to Sitecore Send there is more flexibility in the tech, less responsibility for the infrastructure, and the stack becomes API-driven and composable. But now you have to make sure the necessary data for your marketing automation is now available to Sitecore Send. (Note that the integration with Sitecore CDP and other user data stores are on the roadmap and may be available at the time you are reading this).

5. SaaS will offload infrastructure responsibility and control.
   The business has said they want to focus and manage less infrastructure. SaaS options will solve this problem, which could be a key to making the decision. The existing team may not be ready to relinquish all the control, along with the responsibility. There are middle grounds as well, so it is key to understand how much infrastructure management is a problem right now.

6. Warmup is needed for any migration.
   Whether it is moving to Sitecore Send or another service, when you transition between email marketing tools you need to warm up your new service.

Does this mean that EXM and Sitecore XP might be the right choice?

Some customers use EXM because it meets their needs and was already “in the box”, so there was no need to buy a separate tool just for email and marketing automation. The “monolith” approach here works for them by giving them more functionality in a single solution. Other customers are very happy with EXM because it solves the specific problem they have. Sitecore Send and other marketing automation tools might fit better to address other challenges or to meet more modern business requirements. If a particular solution falls into these categories, it may not be a fit for this type of transition. So, the real questions to ask are:

1. Does Sitecore Send meet the business requirements?
2. Is the customer ready to move everything into a new tool?
3. Is the customer wanting to let go of managing the infrastructure?

If the answer is “yes” to all those questions, then it’s time to start the migration!

Step 1: Track with Sitecore Personalize

This starting point is the same as with the XP Global Brand scenario. We want to start tracking and building up visitor data in Personalize as soon as possible. This is to enable the move away from XP personalization to Personalize. Please read the other article for Why is this a good idea? and Things to watch out for!

NOTE: As with all good things – “it depends”. In some cases, you might not be comfortable paying for Personalize only for tracking at this point and you would rather jump straight to Send and start tracking later. With a composable solution, this is possible and makes a lot of financial sense, but it does mean a delay later when introducing Personalize. If this case applies for you, you may want to flip Step 1 and Step 2 here.

Step 2: Migrate EXM and Marketing automation to Sitecore Send

I suggest tackling this big part of XP migration right away. By putting Sitecore Send in place early, the team can start building new marketing automation plans and migrating their lists, usually during a free trial period. This is a low-cost way to get started on the migration and reduce dependency on XP functionality.

Once the full Sitecore Send is in place with all the configurations, the team can launch their full production license and start warming up their dispatch server and gaining reputation. When everything looks good, EXM can be turned off in their XP infrastructure and XP Marketing Automation plans can be turned off.

Step 3: Migrate to Personalize and transition to Sitecore XM

This step is the same as Step 3 in the XP Global Brand scenario, where we want to reduce the XP infrastructure footprint by moving all our remaining personalization needs into Sitecore Personalize. Please refer to the other article for details about this step.

In general, the goal here is to gradually migrate things into Personalize until there is no reliance on Sitecore XP personalization rules. Once the personalization has been removed, the XP infrastructure can be transitioned to an XM infrastructure and reduce infrastructure management responsibility.

Want more details about migrating to Sitecore CDP/Personalize?

My colleague Dylan Young wrote a nice article to help with some of the decisions around migrating to Sitecore CDP or Sitecore Personalize. It might be helpful as you plan this step!
READ THE ARTICLE ➡

Shouldn’t we move to headless delivery first?

In the XP Global Brand scenario, it was recommended to move to the Edge with the application before transitioning to Personalize. So why is the recommendation different here?

In that global case, the brand had a major investment in content delivery instances to meet their extreme global delivery needs. That was a lot of infrastructure to manage, and the best return on investment was to focus first on reducing that infrastructure cost and management overhead.

In this case, while there are a few content delivery clusters in different regions, the infrastructure complexity and costs are heavier on the XP backend side of things, rather than delivery nodes. If there are a lot of email personalizations or lots of monthly email sends, the implementation team would have needed multiple dedicated EXM dispatch servers. In this particular scenario, I would suggest simplifying the underlying infrastructure for content management and marketing automation, then switch to focusing on the delivery infrastructure after.

So, the thing to consider here when planning your migration: Where is the infrastructure complexity and costs coming from? That is where you need to focus!

Step 4: Go to the Edge and Migrate to Next.js JSS

This step is similar to Step 2/Step 4 in the XP Global Brand scenario, where we need to migrate all our MVC applications into headless technology built against the Experience Edge API. This is going to remove dependencies on the Sitecore Content Delivery instances, prepping for the eventual move to XM Cloud. Please refer to the other article for details about these steps.

The difference in this situation is that we’re going to move everything all at once, rather than doing a gradual push using the static publishing capabilities. Ideally, we want this rebuilt on Next.js so we can take advantage of Vercel to remove all the content delivery infrastructure.

Another alternative could be migrating to .NET headless services if the team really wanted to stay with .NET, but then they would lose the benefits of static sites and also still have to manage some infrastructure for content delivery.

A key piece here is to remove all dependencies on customizations in the content delivery instance. By the end of this step, we don’t want any content delivery instances in the infrastructure.

Step 5: Migrate to XM Cloud

Now we’ve caught up exactly to the same stage as we had in the XP Global Brand scenario and can now migrate to XM Cloud! Please refer to the other article for details about this step.

Once we’ve migrated to XM Cloud, we now have our personalization, marketing automation, email sending, content delivery, and website hosting all composable and SaaS hosted.

Infrastructure responsibility challenge: COMPLETED! 🎉

Want to learn more about Sitecore Send?

My colleague Ahmed suggested some good links if you want to know more about Sitecore Send product features. If you’re trying to figure out if it will fit for your team, you may want to take a look! I also added a link to Developer Portal resources too!

• Product overview ➡
• Developer resources ➡
• Email marketing and customer journey automation ➡
• Personalization in recommendations and one-to-one messages ➡
• Website tracking ➡