Commercetools to Shopify Plus Migration Guide

Commercetools was chosen, in most cases, for a real reason: unlimited flexibility, an API-first architecture, and the freedom to build exactly the commerce experience a team envisioned. For a growing number of brands, that same flexibility has become the reason to leave. What started as composable architecture becomes a permanent, growing engineering commitment: a custom storefront, a checkout built from scratch, search, cart, and content each stitched together as separate services, all requiring a dedicated team just to keep running, let alone improve. This guide covers what a commercetools to Shopify Plus migration actually involves for a B2B operation making that move.

Why Brands Migrate Off Commercetools

Commercetools is a genuine MACH (microservices, API-first, cloud-native, headless) commerce platform, and for some businesses, particularly large enterprises with dedicated engineering organizations building highly differentiated commerce experiences, that architecture remains the right call. Uncap's commercetools vs. Shopify Plus comparison covers exactly when that flexibility is a real advantage worth keeping.

For most mid-market B2B operations, the calculation shifts over time. Commercetools ships no native storefront, no built-in checkout, and no out-of-the-box B2B feature set; every one of those has to be built and maintained as a custom service. That's a reasonable tradeoff when a business has the engineering capacity to justify it. It becomes an expensive, slow-moving liability when the team doing that maintenance is smaller than the platform assumes, or when every new feature requires developer time a growing B2B operation would rather spend elsewhere.

What's Actually Different About a Commercetools Migration

Migrating off a platform like Magento or OroCommerce means exporting data out of a monolithic application with a built-in storefront. Migrating off commercetools means something structurally different: there is no storefront to export, because commercetools never had one. What exists is a commerce API, a custom-built frontend (often React, Next.js, or a similar framework calling commercetools' APIs directly), and a set of composed services handling search, cart, checkout customization, and possibly a separate PIM.

A commercetools migration is really several migrations happening at once: the commerce data itself (products, customers, orders), and the retirement of every custom service that Shopify replaces natively. Scoping the project as "move the data" alone misses the larger part of the actual work, which is deciding what to retire, what to rebuild, and what (if anything) still needs to run headless on top of Shopify.

The Right Migration Order for a Commercetools Replatform

1. Inventory every custom service in the stack. Document the custom storefront, checkout logic, search implementation, and any additional microservices connected to commercetools before scoping anything in Shopify.

2. Decide between native Shopify B2B and a headless Shopify build. Most B2B operations moving off commercetools gain the most by adopting Shopify's native storefront and checkout rather than rebuilding a custom frontend on Hydrogen; a smaller number have a genuine reason to stay headless. This decision shapes every step after it.

3. Migrate product and catalog data. Commercetools' product model needs to map onto Shopify's product and variant structure, which is a real translation, not a direct field match.

4. Map customer accounts and B2B pricing. Whatever custom pricing and account logic was built on top of commercetools needs to be rebuilt using Shopify B2B's native company accounts and price lists.

5. Rebuild or retire custom checkout logic. Custom checkout flows built for commercetools typically get replaced by Shopify's native B2B checkout, extended with Shopify Functions only where genuinely necessary.

6. Scope and rebuild the ERP integration. Confirm how the ERP was connected to commercetools and whether that connection transfers or needs to be rebuilt for Shopify.

7. Build the redirect plan and run B2B-specific QA together, then migrate in a staged rollout, starting with lower-risk accounts before your highest-volume ones.

Retiring Your Custom Storefront and Microservices

This is the step with no equivalent in a monolithic-platform migration, and it's where the real time investment lives. Every custom service built on top of commercetools needs an honest evaluation: does Shopify already do this natively, does it require a Shopify app, or is there a genuine reason to keep it running headless.

In most cases, a custom checkout built for commercetools gets replaced by Shopify B2B's native checkout, extended only where a real business requirement demands it. A custom search implementation is frequently replaced by Shopify's native search and filtering, extended with an app only if genuinely necessary. The instinct to preserve every custom capability "because it took real engineering effort to build" is understandable and usually the wrong call. Most of what got custom-built on commercetools exists because the platform required it, not because the business needed something Shopify can't already do.

Migrating Customer Accounts, Pricing, and Catalog Data

Whatever B2B logic (customer-specific pricing, account structures, negotiated terms) was custom-built on top of commercetools needs to translate into Shopify B2B's native model: company accounts, price lists, and net payment terms. Because commercetools has no built-in B2B feature set, this logic was likely built entirely custom, which means there's no standard export path; the underlying business rules need to be identified and rebuilt against Shopify's structure directly, not assumed to transfer through a generic data migration tool.

Catalog data faces a similar translation. Commercetools' flexible product model, often extended with custom attributes and types specific to how a particular team structured it, needs deliberate mapping onto Shopify's product and variant model rather than an automated import that assumes the two systems think about products the same way.

ERP Re-Integration During the Migration

A B2B operation running commercetools at real scale almost always has a custom-built ERP integration, since commercetools ships no native ERP connectors. That integration work needs to be scoped as its own workstream, evaluating whether the existing integration logic can be adapted for Shopify's architecture or needs to be rebuilt from the API layer up. Given that the original integration was already custom, this is rarely a small task, and it should be scoped early rather than assumed to be a late-stage detail.

The Redirect Plan and B2B-Specific QA

URL structure on a custom commercetools-powered frontend rarely resembles Shopify's URL patterns at all, which means the redirect map needs to be built from scratch rather than adapted from a similar platform's conventions. Every public and account-gated URL needs a mapped redirect, tested before launch.

QA needs to verify more than page loads. Confirm that every piece of custom B2B logic that got rebuilt (account access, pricing, checkout rules) works correctly for real account types, that ERP sync reflects accurate data, and that anything intentionally retired (a custom search feature, a bespoke checkout step) was retired because it was confirmed unnecessary, not because it was simply forgotten during the rebuild.

How Uncap Runs a Commercetools Migration

Uncap Commerce implements the migration to fixed scope, starting with an honest inventory of what actually needs to be rebuilt versus what Shopify B2B already covers natively, so a business isn't paying to recreate custom engineering work Shopify made unnecessary. Uncap's commercetools migration page covers what that engagement includes; this guide is the execution detail underneath it.

Uncap is a Shopify Platinum Partner and Shopify Expert since 2013, with over 380 B2B commerce projects delivered for manufacturers, distributors, and wholesalers, including operations moving off composable and headless platforms where the engineering overhead had outgrown what the business needed. See how that work comes together in Uncap's case studies.

A Real-World Scenario: What Retiring the Stack Actually Looked Like

Picture a mid-market distributor running commercetools with a custom Next.js storefront, a separate search service, and B2B pricing logic built entirely custom by a small internal engineering team. The team assumed most of that custom work needed to be rebuilt in Shopify to avoid "losing functionality."

A full audit found that roughly two-thirds of the custom stack (search, basic checkout customization, standard account pricing tiers) was already covered natively by Shopify B2B, and only the business's genuinely unusual pricing logic (rebates tied to seasonal volume commitments) needed real custom development. The team that had been maintaining five separate services shrank its ongoing platform maintenance to nearly nothing, and the engineers who had been keeping the commercetools stack running spent their time on the business logic that actually differentiated the company, not on keeping a checkout flow online.

Where to Start

A commercetools to Shopify Plus migration is not primarily a data migration. It's an honest audit of everything a team built custom because the platform required it, followed by a deliberate decision about what Shopify already handles natively, what still needs a Shopify app, and what genuinely deserves to be rebuilt. Most of what gets preserved out of instinct turns out to be unnecessary once that audit is done.

Talk to our experts about migrating your commercetools operation to Shopify Plus.