The commerce foundation we build for Shopify migrations

Most "Shopify to Medusa" writing stops at the data. Move the products, move the orders, point the domain, done. That is the easy 60%. The part that decides whether the business still works on Monday is everything Shopify was doing for you through apps and native integrations, and that layer has to be rebuilt deliberately, in the right order, on a stack you control.

We build that on Medusa.js: an MIT-licensed commerce engine written in TypeScript that you host wherever you like. No revenue share, no per-transaction platform fee, no category policy that can switch you off. If you want the case for the platform itself, the migration guide makes it. This article is about what we actually build on top of it.

"Custom build" means owned code, not a product you rent

We don't hand clients a template and wish them luck. Each migration produces a Medusa.js backend and storefront configured for that business: the modules it needs, the integrations it depends on, and nothing it doesn't. It is the opposite of the Shopify model, where you assemble your store out of monthly subscriptions and hope the app you rely on is still maintained next year.

The practical difference: on Shopify, the things that make your store yours live in other companies' code. After a migration, they live in yours. You can read them, change them, and — the part nobody quotes on — nobody can take them away or price you out of them.

There are two halves to the foundation: the owned modules that replace Shopify's native features and apps, and the integrations that connect Medusa.js to the outside services a real store can't live without. The integrations are where most of the risk, and most of our work, actually sits.

The owned modules

When you leave Shopify you lose the apps you were renting, and their data with them. We rebuild those capabilities as modules inside the codebase: redirects at migration scale, storefront navigation, a media library, promotions and merchandising, product relations and product families (for variant and cross-listing logic), content and blog, customer accounts, imported legacy order history, and GDPR tooling. Staff roles and an organised admin come as standard, so the team can actually run the store day to day.

We wrote the module-by-module version of this, what each one replaces and what we learned building it, as its own article: the Shopify features we rebuilt in Medusa. Rather than repeat it, the rest of this piece covers the layer that guide doesn't: the integrations.

The integration layer

Owned modules replace what Shopify did natively. Integrations replace what Shopify did through other companies. This is the harder half, and the four below are where a regulated migration actually lives or dies.

Payments: the part that ends businesses

This is the reason regulated and high-risk retailers can't just pick a hosted platform and move on. Mainstream processors and platform-native payments quietly decline whole categories: vape, CBD, adult, nutraceuticals, and anything a regulator is currently watching. You can have a perfect store and still not be able to take money.

So we build the payment providers a restricted-vertical business actually needs, as first-class Medusa.js modules:

• CyberSource — a full acquirer integration, including Apple Pay and Google Pay through Unified Checkout, with Strong Customer Authentication satisfied by the wallet flow rather than a brittle 3-D Secure redirect.
• Klarna — hosted payment page integration for buy-now-pay-later, where the underwriting allows it.
• OPPWA / COPYandPAY — for acquirers on that gateway, the common path for merchants who've been turned down elsewhere.
• Stripe — the official Medusa package, for the businesses that don't need a specialist acquirer.

Because these are your modules registered in your backend, you're not tied to one processor's risk appetite. If an acquirer changes its stance, you switch the provider — you don't re-platform. That is the difference between a payments wobble and a company-ending event, and it maps directly onto why high-risk retailers need to own their checkout.

Age verification

For age-restricted categories, checkout has to prove the buyer's age or the store is non-compliant. We integrate 1account so verification happens inside the buying flow, with the checkout gated on the result rather than bolted on as an afterthought. It's a legal requirement dressed up as a feature, and it has to be right.

Fulfilment and operations

Orders have to reach the warehouse and the courier without anyone re-keying them. We connect Medusa.js to the systems that already run the back office:

• ShipStation — as a custom store integration, so orders, tracking and barcode/bin workflows flow through the tools warehouse staff already use.
• Linnworks — channel integration for merchants running inventory, purchase orders and multi-channel stock there.

Search, marketing and email

Three integrations that keep revenue from resetting to zero on cutover:

• Meilisearch — fast, typo-tolerant search with the facets a large catalogue needs, so browsing survives the move.
• Klaviyo — flows and segments carry over, so the email and SMS revenue you'd built up doesn't start again from scratch.
• Resend — transactional email (order confirmations, shipping, password resets) handled reliably from your own backend.

The Shopify-to-Medusa import machinery

The migration itself runs on tooling we've built specifically for Shopify exports. It maps every live URL to its new home, generates and verifies the redirects so search equity has somewhere to land, and imports orders, customers and line items with integrity checks that flag anything orphaned before it becomes a support ticket. On the flagship, that meant 2,938 URLs mapped, 9,418 redirects verified, and a verification pass covering 511,740 orders, 260k customer records and 1.6m line items with zero orphan records observed. SEO parity isn't a step at the end, it's designed into the import from the start.

What you're actually trading

Be clear-eyed about both sides. You give up Shopify's convenience: it patches itself, backs itself up, and keeps the lights on, and after a migration those become your responsibility (in practice, ours to set up and often to run for you). That's real, and it's why hosting and support are part of the conversation, not an afterthought — it's what our RUN engagements exist for.

What you get back is a commerce foundation with no landlord. No revenue share. No app you depend on going dark. And no acceptable-use policy that can end your business by email — the risk that pushed a lot of retailers into this decision in the first place. For a business in a category someone else gets to have opinions about, that's not a feature. It's the whole point.

FAQ