The re-platform behind the “cloud move”

Sitecore has been an enterprise platform of choice for large, content-rich organisations for years, and many businesses spent six and seven figures implementing it. If yours runs on Sitecore XP, you have likely heard about the move to XM Cloud, and you may have been told it is the natural next step. It is — but it is not an upgrade. It is a re-platform onto a fundamentally different architecture, and treating it as a version bump is how these projects go wrong.

Why XM Cloud is a different kind of platform

A traditional Sitecore XP site and XM Cloud are built on different principles. XM Cloud is a cloud-hosted, headless platform: the content management and the website front end are decoupled, and the front end is built with a modern framework such as Next.js. That is a genuinely different way of building and running a site from the integrated approach most Sitecore XP implementations use.

In practice, that means the move requires real change, not configuration. The front end has to be rebuilt for the headless approach. The existing site’s templates and styling can be reused to a degree, but the code is ported to the new framework and the content is re-shaped to fit the headless architecture. Sitecore’s own migration guidance frames the work as assessing the current implementation and rewriting code — which is exactly the right expectation to set internally.

Free · 4 minutes

Do you actually know what you are running — and what it is about to cost you?

Fourteen questions on the systems you depend on, the ones nobody owns, and the support dates that turn a routine upgrade into a forced re-platform. Banded finding on screen, full sheet by email.

Why the investment does not simply carry over

This is the hard part for organisations that invested heavily in their Sitecore build. The customisations, the bespoke components, the integrations and the personalisation logic that justified the original cost were built for the old architecture. They do not transfer untouched to XM Cloud. The content can be migrated with tooling, but the implementation around it is rebuilt for the new model. The platform name continues; much of the engineering investment does not.

That is not a reason to avoid the move — the headless, cloud model has real advantages, and older Sitecore versions move toward end of support over time, which removes “do nothing” as a long-term option. It is a reason to go in with a clear, honest understanding of the scope rather than the assumption that you are simply turning on a newer version of what you already own.

The decision the re-platform forces

Because the move is a re-platform regardless, it forces a strategic question worth taking seriously: is XM Cloud the right destination, or is this the moment to evaluate the wider market of composable and headless platforms now available? For organisations deeply invested in the Sitecore ecosystem, staying within it is often the sensible answer. For others, the forced re-platform is the one practical opportunity to reconsider a decision made years ago under different conditions.

Either way, the re-platform is also the moment to leave behind the components nobody uses and the personalisation that was configured and forgotten. Rebuilding the old site faithfully on a new architecture spends a large budget reproducing complexity you could have shed.

What to do now

Start with discovery: what your current implementation actually does, which customisations and integrations are load-bearing, what content must migrate, and where the organisation is heading. That assessment sizes the work, tests whether XM Cloud is the right target, and gives you the independent view that keeps an implementation partner’s scope honest. On a project of this size, that independent perspective is one of the highest-value decisions you can make.

If you are running Sitecore XP and the XM Cloud conversation has started, make sure it is framed as the re-platform it is before any budget is committed. We will establish what the move genuinely requires for your implementation.

Start a Conversation

Build and rescue work

Hands-on delivery of this kind is handled by Sixteen Pillars Studio.

Looking at an acquisition, supplier, or major project?

The greatest risks are rarely visible in the executive summary. The Sixteen Pillars framework surfaces the technology risks that diligence usually misses.