Migrating away from SAP Commerce Cloud to a custom Solidus store

What SAP Commerce Cloud is, and who outgrows it

SAP Commerce Cloud is serious enterprise software, and I want to say that plainly before I spend the rest of this article explaining why a mid sized business might leave it. It began life as Hybris, became SAP Hybris after the 2013 acquisition, and is now SAP's enterprise commerce platform: a large Java application that can run business to business and business to consumer catalogues from one installation, handle very large product sets with complex rules, and tie a shop directly into SAP's own back office. If your business genuinely runs on SAP, sells at real enterprise scale, and uses what this platform is built for, it earns its place and you should probably stay. This article is not an argument that SAP Commerce Cloud is bad software. It is the opposite.

The business I am writing for is the other one. It is the mid sized manufacturer, brand or distributor that landed on SAP Commerce Cloud years ago, often because the rest of the company already ran SAP and an implementation partner recommended it, and now carries the licence, the partner day rates and the Java complexity of an enterprise platform for a shop that is not, in truth, enterprise sized. The checkout works. The catalogue works. But every change is a partner project, every upgrade is a partner project, and the person who signs the invoice has started asking what all of it is for.

This is the honest guide to moving off SAP Commerce Cloud onto a custom store built on Solidus, the open source ecommerce framework for Ruby on Rails. I build the new store and run the move. You own the result. I will be specific about how SAP's export and its API really work, what it hands over and what it holds onto, and where the hard parts are. For the deep detail on how each kind of data actually moves, I link out to the pieces that cover it properly rather than repeat them here. If you have not read it yet, the place to start is the overview: what moves and what does not.

How it is sold, and why the bill is hard to read

The first thing to understand about SAP Commerce Cloud is that there is no price you can look up. SAP does not publish a list price. Its own pricing page says the platform is priced on your annual orders or gross merchandise value, and that the pricing structure and contract details are available on request.¹ In practice that means a subscription quoted through SAP sales or an implementation partner, scaled to the size of your business, usually on a multi year commitment. Two companies of similar size can pay very different sums depending on what they negotiated and when.

That opacity is exactly why the cost is so hard to challenge. You cannot compare your quote to a public number, the licence is bundled with hosting and support, and the implementation and ongoing change work sit with a partner on a day rate. For many businesses the SAP Commerce Cloud subscription plus the partner retainer is the single largest reason the January numbers stop making sense, and it is the one line nobody can explain in plain terms.

If you are paying for SAP Commerce Cloud and you cannot say, in a sentence, what the platform gives you that a Rails application plus your own developer could not, that gap is the thing to examine first. For some businesses the answer is real and specific, and I will come to it. For a great many, the honest answer is that the shop does far less than the platform is built to do.

What you really own, and what holds you

Here is the good news, and it is genuinely good: your commerce data is yours, and it is extractable. SAP Commerce Cloud stores its data in a database defined by its own type system, and it ships two first party ways to get data in and out, the ImpEx framework and the Omni Commerce Connect API. Nobody can switch your shop off and refuse to hand back your catalogue. That is a real advantage, and it means the move I describe below is a question of effort rather than permission.

What holds you is not the data. It is the weight of the thing around the data.

A SAP Commerce Cloud installation is a large Java application with a type system, an extension model, a build and deploy pipeline, and in most cases an integration into SAP's back office. It is operated by people who specialise in exactly this platform, and that pool is small and expensive. The platform is not costly because SAP is greedy. It is costly because it is big, and big software needs big care, delivered by scarce specialists. The question is not whether the platform is capable. It plainly is. The question is whether your shop is heavy enough to justify carrying it.

The second thing that holds you is the partner. Because the platform is complex, most SAP Commerce Cloud shops depend on one implementation partner for anything beyond editing products, and the knowledge of how the shop was built, which custom types were defined and why, lives with that partner rather than with you. That is fine while the relationship is good. It becomes the problem the day the relationship, or the day rate, stops working.

Getting your data out: ImpEx and the API

Because the data is yours, getting it out is a real possibility rather than a negotiation. SAP gives you two routes, and a serious migration uses both.

The first is ImpEx. SAP describes it as a powerful import and export tool tailored to the SAP Commerce type system, and developers use it to create, update and delete type system items using a text file in comma separated value format.² In other words it is SAP's own bulk data tool, it speaks a CSV like format, and it can read the catalogue, the customer records and much else out of the system. It is the tool for the bulk of the move, and because it is built around the type system it hands you the data in the shape the type system defines.

The second route is the Omni Commerce Connect API, usually shortened to OCC. SAP describes the module as one that facilitates data communication across various channels, and its standard functions cover product search with details, stock and pricing, promotions and vouchers, order management including order status, history and placing or cancelling orders, payment and delivery options, and user management covering profiles, addresses and password changes.³ Version two of the API is the default, it is stateless, and SAP treats it as the preferred version, with an older stateful version kept only for backward compatibility. Security is handled through OAuth, and SAP publishes the full list of endpoints through an integrated Swagger interface.³ For a migration the API is how I pull the records ImpEx handles awkwardly, such as orders with their full status history, and how I verify counts between the old shop and the new one.

Two things are worth knowing before you plan around either route. ImpEx and the type system are tightly coupled, so an export is only as clear as the type model behind it, which is the subject of the next section. And the OCC API, like any production API, is rate limited and paged, so bulk reads are done in batches rather than in one pass. Neither is a blocker for a one off migration. Both are reasons to treat the export as an engineering task rather than a button.

The type system, and why mapping takes work

The reason a SAP Commerce Cloud export is more involved than it looks is the type system. SAP's type system acts as an intermediary between the Java business logic and the database.⁴ Types are defined in XML, in a file called items.xml, and from those definitions SAP generates the Java classes during the next build and the database tables during the next system update.⁴ Your catalogue, your customers, your orders and every custom concept your partner modelled all live as types in that system.

That design is powerful, and it is why SAP Commerce Cloud can model almost any business. The price of that power is that your data is not a tidy spreadsheet sitting in one place. It is spread across a type model that was shaped, over years, by whoever implemented the shop. Which attributes are still used, which custom types were added for a project that is long finished, which fields mean something subtly different from what their name suggests: all of that lives partly in the data and partly in the heads of the partner who built it.

For a migration this matters in one concrete way. ImpEx and the API give you the values, but you still have to map them onto the new shop's model, decide which types and attributes survive the move and which were never really used, and reconcile the ones that turn out to mean something other than they appear to. That is not a blocker. It is honest work, usually several days of careful reconciliation on a real catalogue, and it is the same shape of work the products and catalogue spoke walks through in detail. Set the expectation now: the data comes out, and mapping it is the part that takes the time.

What moves, what is locked, and what has to be rebuilt

So what actually moves cleanly, what moves with effort, and what has to be rebuilt? This is the table I wish more platforms published.

What	How it moves off SAP Commerce Cloud	How hard
Products, variants, prices, images, categories, stock	ImpEx export to comma separated files, mapped onto the new model	Moves with mapping work
Customers and addresses	ImpEx export, or read through the OCC API	Moves with mapping work
Order and purchase history	Read through the OCC API as records, imported as read only history	Moves partially
Passwords	Hashes only, upgraded at first login, never the plain text	Special handling
Saved cards and vaulted tokens	Only between certified providers, often needs the gateway	Hardest, plan first
Subscriptions and recurring mandates	Depend on the billing integration, may need its cooperation	Hardest, plan first
ERP integration to SAP	Rebuilt against SAP's integration interfaces	Rebuilt, scope first
URLs and redirects	Mapped by hand from the old structure to the new	Moves with effort
Storefront, extensions, custom logic	Do not move, rebuilt as application code	Rebuilt

The rows in the hardest band are the ones to raise on day one, not in the last week. I come back to each below.

The traps that are specific to SAP Commerce Cloud

Every platform has its own places where a migration gets stuck. For SAP Commerce Cloud these are mine to flag honestly.

The storefront has already changed once, and will again. For years the standard storefront was the JSP based Accelerator. SAP has deprecated that Accelerator and now directs new builds to the composable storefront, an Angular based storefront, formerly the open source Spartacus project, that talks to SAP Commerce Cloud exclusively through the Commerce REST API.⁵⁶ SAP includes the composable storefront in the SAP Commerce Cloud licence at no extra cost and ships it on a roll forward update policy, while on premise customers may still use the open source Spartacus code.⁷ The practical point for a mover is this: if your shop is on the old Accelerator, you are already facing a storefront rebuild inside SAP. A rebuild is coming either way, which is a reasonable moment to ask whether the rebuild should stay on SAP at all.

Payments and vaulted cards are the hardest single thing. SAP Commerce Cloud does not hold your customers' card numbers. Payment runs through a gateway integration, and the saved cards and tokens belong to that payment provider, not to the platform. So whether your customers keep their saved cards depends on your gateway and not on either shop. The best case is that your SAP shop already charges through a provider you own, such as your own Stripe account, in which case the new Solidus store connects to the same account and the tokens never move at all. The worst case is a provider that will only release tokens to another holder certified to the top level of the card security standard, if it releases them at all. This is the question to settle before anything else, and the payment tokens spoke is the detail. Read the hidden dangers of switching payment gateways before you add a gateway change on top of a platform change.

Subscriptions and recurring mandates live in a billing integration. If your shop bills on a recurring basis, that logic and those mandates sit in a subscription billing component or a payment provider's own recurring feature, not in a tidy exportable table. An active mandate often cannot simply be exported and reinserted, and may need the billing provider's cooperation to move without interrupting a customer's billing. Flag every live subscription early, and plan the cutover around the billing dates. The subscriptions spoke is the one to read in full if this is you.

The deep SAP integration is the real question, not the data. This is the trap that is genuinely specific to SAP, and I want to be fair about it. SAP Commerce Cloud is built to connect to SAP's back office. Businesses run real time flows for product, pricing, stock and order fulfilment between the shop and an SAP ERP system such as S/4HANA, built on SAP's own integration tooling and prebuilt integration packages.⁸ If that integration is doing real work, replacing the shop means rebuilding those flows against SAP's interfaces, and that is proper engineering, not an afternoon. For a business that lives and breathes S/4HANA, the native integration is a real advantage and a real reason to stay. For a great many mid sized shops, though, the ERP connection turns out to be a nightly export and a handful of fields, which a Rails application can talk to perfectly well, often for far less than the SAP licence it replaces. Scope this honestly before you decide anything: it is the hinge the whole decision turns on.

The URL structure is yours to preserve. Your SAP storefront has a URL structure, and years of links and search rankings hang off it. Every one of those addresses has to be mapped to its new home with a permanent redirect, or the traffic that found you yesterday meets a dead page tomorrow. On the shops I build the redirects live in the application itself, in a table the shop's own staff can edit, so they survive every future deploy. The mechanics are in the products and catalogue spoke, because the redirect map and the product move are the same exercise.

A worked example in Leeds

Let me make this concrete with an invented business, because real client stories are not mine to tell.

Aireside Lighting (airesidelighting.example) is a Leeds manufacturer of commercial and architectural lighting, selling to electrical wholesalers and specifiers on trade accounts and to the public through a smaller consumer range. It turns over about nine million pounds a year online, runs a catalogue of roughly eighteen thousand products with heavy use of custom attributes for lumens, fittings, dimming and compliance, and has been on SAP Commerce Cloud for seven years, chosen when the group moved its finance and manufacturing onto SAP. Its trade customers have negotiated price lists and pay on monthly invoices. The shop works. What stopped working was the arithmetic: the SAP Commerce Cloud subscription, the implementation partner's retainer for changes and upgrades, and the scarce specialist time together cost more each year than several full time staff, and the managing director could not say what the platform bought that the business actually used.

When I scope a move like this, the first week is not about products. It is about the hard rows in the table. Aireside charges through its own payment provider account, so the saved cards stay where they are: the new Solidus store connects to the same account and no token moves. It has no consumer subscriptions, which removes that hard case. The real question is the SAP integration, so week one is spent reading exactly what crosses between the shop and the SAP back office. It turns out to be product and price data flowing out of SAP on a schedule, stock levels, and finished orders flowing back for fulfilment and invoicing. That is a defined set of interfaces, not a tangle, and it can be rebuilt as a tested integration from the Rails application against SAP's own endpoints. Settling that in week one is what makes the rest of the project calm.

The catalogue is the real labour. The ImpEx export comes out as comma separated files shaped by the type system, and the mapping work is deciding which of the many custom attributes are still used, collapsing years of near duplicates, and reconciling the trade price lists onto the new model. The customer records come across with the same mapping care, and their password hashes carry over to be upgraded at first login so nobody is forced to reset, the path the customer accounts spoke sets out. The order history comes through the OCC API as read only records so customer service and customers can still look up the past, while refunds and returns on genuinely old orders stay with the old system for a short handover window, which is the shape the order history spoke describes. The eighteen thousand old URLs become a redirect map that someone from Aireside checks, because only they know which pages still earn their traffic. On the far side, the trade price lists, the monthly invoicing and the SAP integration that were an enterprise platform's job become ordinary tested features of a Rails application, and the subscription and the partner retainer disappear from the budget for good.

The move is not free and it is not instant. But a year on, Aireside pays for hosting, its own developer and a defined SAP integration, and nothing else, and it owns the shop outright.

The honest move onto Solidus

The shape of a SAP Commerce Cloud move is the same every time, and the order matters.

I start with the questions that can sink a project: where do the saved cards and tokens live and will they move, are there active subscriptions and what do they depend on, what does the SAP integration actually carry and can it be rebuilt proportionately, and who on your side owns the data and can answer what a custom type means. Settle those first, because they are expensive to discover late. Then the catalogue and customers come across through ImpEx and the API, mapped onto the Solidus model with the reconciliation the type system demands. Order history follows as read only records. The URL map is built and checked by someone who knows the shop. The storefront, the checkout and every integration, the SAP connection included, are rebuilt as tested Rails code. Old and new run in parallel for a few weeks with the catalogue frozen, the final import is rehearsed until it is boring, and cutover happens on a quiet weekday morning with the old shop kept untouched for thirty days as the fallback.

The result is a right sized shop. Where SAP Commerce Cloud gave you an enterprise platform and a subscription scaled to your turnover, Solidus gives you a Rails application with no licence fee, no vendor imposed upgrade cadence, and a hosting bill that fits one shop rather than a platform built for the largest companies in the world. The customisation that was a partner project becomes application code you own, and the bespoke code I write becomes yours once it is paid for in full. For where the platforms sit against each other and the full money picture over five years, read the platform comparison and the five year total cost of ownership. SAP Commerce Cloud is the other enterprise platform alongside Salesforce Commerce Cloud, and much of what is true for one is true for the other.

When you should stay where you are

I would rather lose the work than move a shop that should stay, so here is when to stay on SAP Commerce Cloud.

Stay if your business genuinely runs on SAP and the native integration into S/4HANA or another SAP back office is doing real, heavy, real time work that would be costly to rebuild and risky to lose. Stay if you sell at true enterprise scale, across many markets and brands from one platform, with an internal team or a partner you trust to run it. Stay if the subscription and the partner cost are proportionate to what the platform does for you and you can say clearly what that is. In those cases SAP Commerce Cloud is doing its job, and a migration would trade a working enterprise system for a smaller one you then have to build and run.

The shop that should move is the one paying an enterprise subscription and enterprise partner rates for a shop that is not enterprise sized, where the licence, the specialists and the complexity cost more than the business the platform supports, and where the ERP integration, looked at honestly, is a handful of fields rather than the beating heart of the operation. If that is you, the money usually says move, and the total cost of ownership article will show you by how much.

What this means for you

Leaving SAP Commerce Cloud is not an escape from a platform that trapped you. Your data is yours, it comes out through ImpEx and the OCC API, and the door is open. It is a decision to stop paying for an enterprise platform you have outgrown, or never grew into, and to run a shop that fits. The catalogue takes real mapping work because of the type system. The payments, any subscriptions and the SAP integration are the hard parts, and they get settled first. Everything else is a well understood project with a clear order.

If you use what SAP Commerce Cloud is built for, keep it. If you are paying for far more platform than you need, and your own data belongs to you anyway, a custom Solidus store is usually the right size. Who holds the keys to that data in the first place is worth being clear about on any platform, which is the subject of who actually owns your business data.

If you want a straight answer on your own numbers, bring them to a free workshop and the first two weeks of work are on me. I will put your subscription, your partner and your integration figures against a Solidus build, flag the payment, subscription and SAP integration questions before anything else, and tell you honestly whether moving pays off for you. Sometimes it does not, and I will say so.

Footnotes

1. SAP, SAP Commerce Cloud pricing (priced on annual orders or gross merchandise value, with the pricing structure and contract details available on request, no published list price), accessed 14 November 2026, https://www.sap.com/products/crm/commerce-cloud/pricing.html ↩

2. SAP Learning, Getting an Overview of ImpEx (a powerful import and export tool tailored to the SAP Commerce type system, used to create, update and delete type system items from a text file in comma separated value format), accessed 14 November 2026, https://learning.sap.com/courses/exploring-the-technical-essentials-of-sap-commerce-cloud/impex-overview_aaae24a6-83e4-4ec5-8ff8-9149e361f9a5 ↩

3. SAP Learning, Introducing the Omni Commerce Connect Module (OCC facilitates data communication across channels, with product search, promotions and vouchers, order management, payment and delivery options and user management; version two is the default stateless preferred API, secured with OAuth and documented through Swagger), accessed 14 November 2026, https://learning.sap.com/courses/mastering-the-technical-essentials-of-sap-commerce-cloud/omni-commerce-connect-restful-web-services_a60bebeb-75bc-4a6d-972b-96c17363b909 ↩ ↩²

4. SAP Learning, Introducing the Type System (the type system acts as an intermediary between Java business logic and the database; items.xml XML definitions generate the Java classes during the next build and the database tables during the next system update), accessed 14 November 2026, https://learning.sap.com/courses/exploring-the-technical-essentials-of-sap-commerce-cloud/introducing-the-type-system_ab582bd7-f30e-4351-850f-70d341d569fa ↩ ↩²

5. SAP, Spartacus repository (a lean, Angular based JavaScript storefront for SAP Commerce Cloud that talks to SAP Commerce Cloud exclusively through the Commerce REST API), GitHub, accessed 14 November 2026, https://github.com/SAP/spartacus ↩

6. SAP Knowledge Base Article 3263872, Accelerator Storefront Deprecation FAQ (the JSP based Accelerator storefront is deprecated, with the composable storefront as the recommended path), accessed 14 November 2026, https://userapps.support.sap.com/sap/support/knowledge/en/3263872 ↩

7. SAP, Composable storefront documentation (based on the Spartacus open source code, included in the SAP Commerce Cloud licence at no extra cost, with a roll forward update policy; on premise customers may still use Spartacus open source), accessed 14 November 2026, https://sap.github.io/spartacus-docs/ ↩

8. SAP Learning, Implement an Integration of SAP S/4HANA Cloud with SAP Commerce Cloud (SAP Integration Suite connects Commerce Cloud to the S/4HANA back office using prebuilt integration packages for flows such as order fulfilment), accessed 14 November 2026, https://learning.sap.com/learning-journeys/implement-an-integration-of-sap-s-4hana-cloud-with-sap-commerce-cloud ↩