There’s a lot of conversation in the Sitecore ecosystem right now about composable, SaaS, and what comes next.

But there’s a quieter conversation that needs to happen too.

What do you do if you’re running Sitecore Experience Commerce and the platform you’re on has been officially left behind?

The situation is clear

Sitecore confirmed a few years ago there will be no new version of XC released with Sitecore XP 10.4. That also means customers on XC cannot upgrade their XP platform.

XC 10.3 is the last version. There is no upgrade path. There is no next release.

Sitecore will continue to support XC 10.3 under their product lifecycle, which includes corrective support and may include updates for third-party compatibility. Sitecore So nothing switches off overnight.

But the direction of travel is one way.

No new features. A narrowing support window. An integration surface that will slowly drift out of compatibility. And a platform the vendor has moved on from.

The question isn’t whether to move. The question is how, and when, and in what order.

Where are you actually starting from?

Before I talk about options, it’s worth being honest about one thing.

Not every XC customer is on 10.3.

If you’re running an earlier version – 9.x, 10.1, or 10.2 – upgrading to 10.3 is a legitimate first move. It brings you to the most current supported version. It gets you back onto extended support coverage. And it gives you a stable base to plan from, rather than operating under pressure from an even older codebase.

It’s not a long-term strategy. But it is a sensible short-term one.

Your options

There are three realistic paths in front of you. None of them are free. But they have very different risk profiles.

Option 1 – Stay put and buy time

If your site is stable, your integrations are holding, and you’re not in a position to start a migration programme right now – running XC while you plan properly is defensible.

What makes this work short-term:

• You’re mid-budget-cycle and can’t start until next year
• You need time to properly evaluate your architecture options without pressure
• A rushed migration would create more risk than a deliberate one

What makes it dangerous long-term:

• Every integration dependency – payments, tax, ERP – will eventually force your hand
• Technical debt accumulates and the migration gets heavier, not lighter
• You lose the ability to make the decision on your own terms

Don’t treat staying put as a strategy. Treat it as runway.

Option 2 – Full re-platform

A clean break.

You migrate everything off XC, stand up a new commerce platform, build a headless storefront, retire the old stack.

The appeal is obvious. You carry nothing forward. You land on a clean composable architecture.

The reality is this is the highest-risk path for most organisations. The bigger your catalogue, the more complex your promotions and pricing rules, the more customisation you’ve built on top of XC – the more a big-bang migration exposes you.

A full re-platform makes sense when:

• Your XC implementation is genuinely simple and the scope is manageable
• There’s a strategic moment – a rebrand, a market expansion – that makes a clean break logical
• The business has the appetite and budget for a contained programme of work

For most mid-to-large organisations though, there’s a better way.

Option 3 – The Strangler Fig pattern

This is the recommended path for most teams. And it’s the one I’d start with unless you have a strong reason not to.

The strangler fig is a well-established migration pattern. You build the new capability alongside the existing platform. You route traffic incrementally to the new stack. You retire pieces of the old system progressively until nothing is left.

The old platform keeps running and serving real users throughout. There’s no big cutover moment. There’s no bet-the-business risk.

How this plays out for XC:

XC is a tightly coupled system. The storefront, the engine, and XP all talked to each other directly. The first thing you need to do is break that coupling.

You introduce an API abstraction layer between your front-end and the commerce backend. From that point, the front-end doesn’t care what’s behind it.

Why this is the right default:

• You’re never down while the migration is in-flight
• You validate the new platform on real traffic before fully committing
• You can migrate in logical segments – by category, by geography, by customer type
• If something breaks on the new platform, you route back to XC while you fix it

Choosing your commerce layer

The abstraction pattern works with any composable commerce platform.

If you’re staying in the Sitecore ecosystem, Sitecore OrderCloud is the natural fit. OrderCloud is a headless, API-first SaaS platform built for B2C, B2B, B2B2C, and marketplace scenarios. Because it has no opinions about your front-end or your CMS, it slots cleanly behind the API gateway. Your storefront calls the gateway. The gateway calls OrderCloud. XC doesn’t need to know it’s being replaced until it’s gone.

If your preference is a composable commerce platform outside the Sitecore ecosystem, the abstraction layer works exactly the same way. The point of designing it platform-agnostic is that you’re not locking yourself to a vendor at the architecture level.

Your hosting costs start falling as you decompose

This is one of the most underappreciated benefits of this approach and it’s worth being explicit about.

XC carries a significant infrastructure footprint. Commerce Engine services. SQL Server. Solr. Redis. Multiple XP roles – CM, CD, xConnect, Processing, Reporting. You’re paying for all of it whether you’re using 100% of it or 10%.

As you migrate capabilities off XC and onto your new commerce platform, each component you can turn off reduces that footprint directly.

Move your catalogue – scale down the Commerce Engine catalog services. Move your order management – the order services go with it. Move your storefront traffic – decommission the CD servers serving XC pages.

With a SaaS commerce target, you shift from a large fixed infrastructure cost to a consumption-based model. That’s a meaningful change in both cost profile and operational overhead.

At EPAM we have a migration accelerator ready for this exact job. Reach to find out more.

https://www.epam.com/services/partners/sitecore/ordercloud-migration-accelerator

So commerce is covered what about content?

You will need to move your CMS also fully get off XC.

The natural composable destination alongside OrderCloud is SitecoreAI- Sitecore’s SaaS CMS and the successor to XP (formerly XM Cloud).

The strangler fig approach works here too. You don’t have to migrate commerce and CMS simultaneously. Many teams will move commerce first, keep XP running for content management in the interim, then cut over the CMS layer in a second phase.

Or if the business has appetite for it, both migrations can run in parallel tracks with a shared headless front-end as the convergence point.

Neither is wrong. The right answer depends on your team’s capacity and how much change the business can absorb at once.

A note for customers already on Content Hub

If your organisation is already on Sitecore Content Hub, you’re in a better position than most – and it’s worth understanding why.

Content Hub includes PCM (Product Content Management). If you’ve invested in structuring your product data there, that data is already in a clean, API-accessible form that maps well to what a composable commerce platform needs for its catalogue.

That matters because catalogue migration is typically the most complex and time-consuming part of moving off XC. XC stored product data in a SQL-based entity model with a plugin architecture. Getting clean, well-structured data out of it takes real effort.

If your product content already lives in Content Hub PCM, you skip a big chunk of that problem. You can treat PCM as your product data master and build the catalogue population for your new commerce platform directly from there.

Content Hub PCM handles product enrichment and asset management. The commerce platform handles the transactional layer. The storefront calls both. Each system doing what it does best, connected by APIs.

If you’re on Content Hub today and still running XC for the transactional side, this is worth getting in front of the right people. The investment you’ve already made in structuring product data is directly reusable in the architecture you’re moving toward.

Where to start

Regardless of which path fits your situation, the first steps are the same.

Audit your XC dependency surface. Before you evaluate platforms or plan anything, understand what XC is actually doing in your environment. Custom pipelines, extended entities, tight integrations with XP personalisation and xDB, custom pricing logic – this is where the migration complexity actually lives. The standard catalogue and order data is the easy part.

Map your data and run your counts. How many SKUs? How many variants? How many price books? How many promotions with custom logic? Real numbers change planning significantly. You can’t scope this work honestly without them.

Design the API abstraction layer first. Whether you’re going strangler fig or full re-platform, the most important architectural decision you’ll make is the contract between your front-end and your commerce backend. Design it platform-agnostic from day one. That’s the decision that buys you flexibility for everything that follows.

Decide on your CMS path at the same time. This is the one teams defer and then regret. Your commerce migration and your CMS strategy are linked decisions. If you’re staying on XP for now, that’s fine – but know what step two looks like. Making these decisions sequentially costs more than making them together.

The real point

The XC end of life isn’t a crisis. Your platform keeps running.

But the organisations that come out of this well are the ones who use it as a forcing function – who make architectural decisions deliberately, while they still have runway, rather than scrambling when support pressure arrives.

The strangler fig gives you the safest path. Decouple now. Migrate incrementally. Retire XC progressively. You don’t have to bet the business on a single cutover.

Start the conversation while you still have options.