I developed an AI-powered migration framework that streamlines the migration of Sitecore XP websites to XM Cloud, automating and eliminating 70% to 90% of the manual effort typically required. This solution accurately preserves each page’s presentation structure, including the full hierarchy of components and placeholders the entire set of migrated content, and the rendered HTML output. All Sitecore assets retain their original structure, hierarchy, item IDs, and paths after migration.
The framework requires only two inputs: 1) a backup of the master database and 2) access to any operable site environment, may it be UAT, Production, or even Local. Since direct database operations in the cloud are not possible, the actual migration always runs locally. Having the original source code is optional, but providing it greatly enhances the accuracy of component markup conversion.
At a high level, he migration framework performs the following steps:
- conducts pre-execution sanity checks and flags potential issues, such as media items exceeding 50Mb or broken layout/references at the origin
- copies the actual content from XP to XM Cloud
- converts rendering definitions to ensure XM Cloud compatibility
- converts ASP.NET MVC Razor Views (
*.cshtml files) into Next.js components with TypeScript (*.tsx files)
- migrates site presentation from the XP format to the XM Cloud format, processing each page individually
- rebinds datasources as needed for XM Cloud compatibility
For demonstration purposes, I used the well-known Habitat site running on Sitecore 9.2, which I was able to recover from some of my archived VM snapshots. Having a running instance of the site is essential, regardless of the environment. In this example, I configured the VM's hostname rssbplatform.dev.local via my hosts file so it would be accessible from my host machine.
It’s important to note that Sitecore XP and XM Cloud handle presentation differently in defining the page's presentation and dealing with the dynamic placeholders. Unlike XM Cloud, which has a rendered page layout JSON per each of the pages, MVC-powered XP websites did not keep the hierarchy: resolving and preserving the correct hierarchy during migration requires access to a working runtime instance of the source site..
Disclaimer: the demonstration video shows the entire migration of a Habitat website in just 12 minutes, starting with the content migration and ending up recreating the site on XM Cloud, including all the converted pages with the entire layout/structure converted to each of them.
I am not a front-end developer in the first place; thus, I decided to skip this part of conversion for now. When it comes to static files, there are two ways:
- If you don't have an original source code, just place compiled JS/CSS files under
/public folder in Next.js app and adjust the references; no changes are possible.
- With the source original code, you can compile and deploy static files under
/publiс folder; that includes any changes you may have down the way.
Please take into account that not all styles are picking up automatically: that is expected and falls into a remaining 10%-25% of things to do manually.
When converting styles, they fall into three main categories:
- Fixed styles: These are automatically picked up during conversion.
- Parametrized styles: Since the migration framework processes rendering parameters, many of these at least default values are also migrated automatically.
- Dynamic styles: Styles generated at runtime or claculatev via scripts require custom build logic to be reimplemented on the Next.js side.
With further stages of development, the goal is to entirely convert parametrized and as much of dynamic classes, as it is possible.
What previously took months of manual labor for a decent team can now get done in minutes. Isn't that incredible?
I wish to hear youк thoughts, drop me a message!