Umbraco migrations vs transitions

A new release of Umbraco is on the horizon with version 14 slated to be released by the end of the month; we want to revisit the question of upgrading or migrating your CMS.

In Enterspeed, we kind of stumbled into the space of migrating CMSs by accident. Our Umbraco and Sitecore source integrations work by sending a copy of each piece of data to Enterspeed, so out of the box, you have 50% of a content migration. Of course, the other 50% is to insert the data into a new CMS instance. Working off the idea that we had 50% of the work done, we demoed a Sitecore to Umbraco migration at Codegarden 2022. The component that does the last 50% of the work is an Umbraco extension that loads the data from Enterspeed and creates it as Umbraco document types, nodes, etc.

The issue with migrations

Anyone who has ever worked with migrations knows that it is more involved in moving data from A to B. The trickiest part of a migration project is when the source data model doesn't match the target data model, so you often need to transform the data. When faced with moving data between different CMSs, or even different versions of the same CMS, you also want to leverage the new features from the target CMS, and this also adds to the need for transforming the data. For example, in Umbraco, you might want to migrate from Nested Content to Block List.

Speaking of Umbraco, we want to zoom in on this in the context of Umbraco 14. Third-party data types have been one of the pillars for the success of Umbraco as a CMS platform loved by developers and users. But the consequence is that Umbraco solutions differ in their structure and data types, and the breadth of data types any given migration tool needs to support is large. A migration tool, therefore, needs to be a developer framework that allows the developers to extend and customise the software for each individual migration project.

The status of the Enterspeed migrator

The Enterspeed migrator never took off as a developer framework and didn't reach the scale in regard to supporting all the different variants of Umbraco data types. The main reason was that better alternatives existed for doing an Umbraco to Umbraco migration. In this context, we want to highlight the uSync Migration project, which has worked on years of development on persisting and moving Umbraco data between different instances. Today the main focus of the Enterspeed migrator is doing migrations from other CMSs into Umbraco.

Transitioning to headless

If your Umbraco migration project involves a transition to headless, we see a couple of different paths.

• The first path is to tackle the frontend build before you take on the Umbraco migration project. This can make sense if you want to accelerate a new user experience but without actually doing an Umbraco upgrade. This postpones the actual Umbraco migration, as Enterspeed will be the headless API.
• The second path is to leave your legacy content in the existing Umbraco installation (e.g. if you have a large help section or article archive) and build a new Umbraco project for your new content (e.g. front page, category, or landing pages). Then you can ingest data from both Umbraco installations into Enterspeed and build your new headless website.
• The third path is doing the migration only for the Umbraco back office and the data, and not the frontend templating in Umbraco. The website build is then done headless with Enterspeed as the API layer. Doing the actual migration makes sense if you want to make use of the new features of the CMS, but of course, the project is going to be more substantial.

If you want to know more about transitioning with Enterspeed, you can view our Umbraco Tech Partner webinar on transitioning your legacy CMS.