The Great Migration: Why Scale-Ups Are Moving from Shopify Plus to MedusaJS

There is a specific moment in the life of a growing ecommerce business when the platform stops being an accelerator and starts being a tax. Nobody schedules it. It arrives quietly, usually in a sentence from your development partner that begins with "we can't do that natively, but there's a workaround."

The first workaround is fine. The fifth becomes a Rube Goldberg machine of apps, metafields, webhook relays, and a middleware service nobody wants to touch. By the twentieth, your ecommerce platform development roadmap is no longer defined by what your business needs. It is defined by what your platform permits.

This is the point at which scale-ups start seriously evaluating custom MedusaJS ecommerce development as an alternative to Shopify Plus. Not because Shopify is bad software — it is genuinely excellent software — but because the fit between a hosted, opinionated commerce platform and a business with non-standard commercial mechanics eventually breaks down.

This article is about that break point: where it actually occurs, what an open headless commerce architecture changes, what migration honestly costs, and when you should stay exactly where you are.

First, Credit Where It Is Due

Shopify Plus is the correct answer for a very large number of businesses, and any consultancy that tells you otherwise is selling something.

It removes an enormous class of problems from your life. PCI scope is largely handled. Checkout converts well because it has been optimized against more transaction data than your company will ever see. Uptime during a Black Friday traffic spike is somebody else's pager. The app ecosystem means a merchandiser can add subscriptions, reviews, or loyalty without opening a ticket with engineering. For a direct-to-consumer brand selling a well-defined catalogue into one or two markets, the platform fee is cheap relative to what it replaces.

If that describes your business, migrating to a custom ecommerce platform is a bad trade. You would be buying flexibility you do not need with engineering budget you could spend on acquisition.

The businesses that migrate are the ones whose commercial model has drifted away from the template — and that drift is usually a sign of success, not a mistake.

The Four Ceilings

Replatforming decisions are rarely triggered by a single dramatic failure. They are triggered by the accumulated weight of four structural ceilings, all hit at roughly the same stage of growth.

1. The Checkout Ceiling

The checkout is the most valuable page you own and the one you control least.

On a hosted platform, checkout customization happens inside sanctioned extension points. That boundary is not arbitrary — it is what keeps the platform's PCI posture and conversion guarantees intact — but it is a hard boundary. Anything the vendor has not exposed is simply unavailable, and the sanctioned surface itself moves. Brands that had built deeply into checkout.liquid learned this when checkout extensibility replaced it and years of custom logic had to be rewritten against a new, narrower model on the vendor's timetable, not their own.

For most stores this is irrelevant. For a business that needs quote-approved pricing at checkout, installation scheduling as a line item, split payment across a deposit and a balance, region-specific compliance fields, or cash-on-delivery with real courier reconciliation, it is the whole ballgame. You end up rebuilding the last mile of your commercial process outside the checkout and stitching it back in — which is exactly the fragile arrangement you were trying to avoid.

2. The Data Model Ceiling

Hosted platforms give you one product model, and it is a good product model — for products.

The strain shows when what you sell is not a product in that sense. Configurable goods with dependent options. Kits whose price is computed from contents rather than stored. B2B customers on negotiated price lists with volume tiers. Services attached to physical items. Rental periods. Made-to-order items with lead times that vary by component availability.

The escape hatch is metafields and apps, and it works — up to a point. Past that point you are maintaining a shadow data model that lives half in the platform, half in a middleware service, and entirely in the heads of two people. Every new requirement asks the same question: where does this actually live? Nobody has a confident answer, and that uncertainty is the real cost. It shows up as slower releases, more regressions, and a growing reluctance to change anything near the cart.

3. The Economic Ceiling

Platform economics are structured to be invisible when you are small and material when you are not.

The shape matters more than the numbers, which change: you pay a platform fee that scales with gross merchandise value, an additional margin if you process payments outside the vendor's own gateway, and a monthly stack of per-app subscriptions that quietly compounds — search, subscriptions, reviews, bundling, loyalty, feed management, B2B pricing, tax. Each is individually reasonable. Together they become a recurring line item that grows with revenue while delivering no additional capability.

The honest framing is not "self-hosted commerce is free." It is not. You are choosing between two cost curves:

• Hosted: low fixed cost, cost scales with revenue, capability is capped by the vendor.
• Owned: higher upfront engineering cost, cost scales with complexity rather than revenue, capability is capped by your budget.

Below a certain GMV, hosted wins on pure arithmetic. Above it, the curves cross — and they cross sooner when a meaningful share of your app stack exists purely to work around the platform.

4. The Roadmap Ceiling

This is the one that actually pushes teams over the edge, and it rarely appears in the business case.

When your commercial differentiation depends on features the platform does not have, your roadmap becomes a function of someone else's. You wait for a feature request to be prioritized. You wait for an app vendor to support a new API version. You discover that two apps modify the same order object and the outcome depends on installation order. An app you depend on gets acquired and sunset with ninety days' notice.

None of these are catastrophic in isolation. Collectively they mean your ability to ship the thing that differentiates you commercially is throttled by parties with no stake in your business. For a scale-up whose entire strategy rests on doing commerce differently, that is not a tooling problem. It is a strategic problem.

What MedusaJS Actually Is

MedusaJS is an open-source, MIT-licensed, TypeScript-native commerce engine that you self-host. It is not a storefront theme and it is not a SaaS product — it is a headless commerce backend that exposes a Store API for your storefront and an Admin API for your operators, and expects you to build the front end separately.

That last part is a feature, not an omission. It is what makes the architecture composable: your Next.js storefront, your admin dashboard, your search index, your payment providers, and your ERP integration are all independent participants talking over APIs, rather than layers of one monolith you are forbidden from modifying.

Three architectural properties matter for the migration decision.

Commerce features are modules, and your custom logic is a peer. Product, pricing, inventory, cart, order, payment, and fulfillment are each separate modules with their own data models and services. When you build a quote-request module or a bundle-pricing module, it sits beside the core modules rather than patching them. Module links join your entities to core entities without foreign keys reaching across module boundaries — so a platform upgrade does not silently break your schema. This is the technical difference between "we customized the platform" and "we forked the platform," and it is the difference that determines whether you can still upgrade in three years.

Business processes are explicit workflows with compensation. Multi-step operations — placing an order, capturing payment, reserving stock, notifying a courier — are defined as workflows built from discrete steps, each with a rollback function. If step four fails, Medusa unwinds steps three, two, and one in reverse. You get saga semantics for the operations where partial failure costs real money, without hand-rolling distributed transaction logic or accepting an order that is half-processed.

You own the source. MIT licence, your repository, your infrastructure. No per-transaction fee, no app-store rent, no vendor deciding which features you are permitted to build.

Here is what "custom logic as first-class code" concretely looks like — a B2B quote entity defined as a proper data model and linked to the core product module:

// src/modules/quote/models/quote.ts
import { model } from "@medusajs/framework/utils"

export const Quote = model.define("quote", {
  id: model.id().primaryKey(),
  status: model
    .enum(["draft", "submitted", "approved", "rejected", "expired"])
    .default("draft"),
  customer_id: model.text(),
  requested_quantity: model.number(),
  agreed_unit_price: model.bigNumber().nullable(),
  valid_until: model.dateTime().nullable(),
})

// src/links/quote-product.ts
import { defineLink } from "@medusajs/framework/utils"
import ProductModule from "@medusajs/medusa/product"
import QuoteModule from "../modules/quote"

// Joins quotes to core products without either module
// owning a foreign key into the other's schema.
export default defineLink(
  QuoteModule.linkable.quote,
  ProductModule.linkable.product
)

That is roughly twenty lines to introduce a first-class commercial concept that a hosted platform would have you model as a metafield blob, a third-party form app, and a spreadsheet. It has its own tables, its own migrations, its own API routes, its own admin screens, and it upgrades independently. Our Medusa commerce engineering practice covers how these modules are structured, tested, and documented so they remain maintainable years after the initial build.

The Architectural Difference, Concretely

The visual tell is where the arrows converge. In the hosted model, your differentiating logic lives in a middleware box hanging off webhooks, reaching back into the platform through a rate-limited API it does not control. In the owned model, that same logic is a module inside the commerce engine, participating in transactions and workflows as a first-class citizen.

Side by Side

The last two rows are the whole decision. Hosted platforms trade capability for speed and operational simplicity. Open headless commerce trades speed and simplicity for capability. Neither is a moral position.

The Honest Cost Accounting

The pitch you will hear from agencies is "eliminate transaction fees and own your platform." That is true and incomplete. Here is the full ledger.

What you stop paying: the GMV-based platform fee, the gateway margin on payments processed outside the vendor's own processor, and the app subscriptions whose only job was working around platform constraints.

What you start paying: infrastructure — application servers, a managed or self-run PostgreSQL with replication and tested backups, Redis for events and job queues, object storage and a CDN for media, a search index, and observability. Plus the build itself, and either an internal team or a retained partner to operate it.

What you must not underestimate: operational ownership. A store that is fast on launch day and unmonitored by month three is not a successful migration — it is deferred failure. Database tuning, backup verification, dependency and security patching, incident response, and capacity planning before peak season are now genuinely your responsibility. This is precisely why we treat managed commerce infrastructure as part of the engagement rather than something handed back to the client at go-live.

The financial case for migrating is rarely won on transaction fees alone. It is won when fees, workaround-app subscriptions, and the engineering cost of maintaining the workarounds themselves are added together — and compared against the revenue that is currently unreachable because the platform cannot express your commercial model. That last figure is the one most business cases omit, and it is usually the largest.

How the Migration Actually Runs

A big-bang cutover of a revenue-generating store is an unforced error. Every migration we run is phased, with a working rollback at each stage.

Phase 1 — Commerce Discovery and Data Modeling

Before any code, map the real catalogue, the real pricing rules, the real fulfillment process, and every back-office system that touches an order, onto Medusa's module boundaries. The deliverable is a data model and a module map — including the explicit decision of what becomes a reusable plugin versus a store-specific module. Getting this boundary right is most of what determines whether the store is still maintainable three years later.

This phase also surfaces the things nobody documented: the manual step in fulfillment, the spreadsheet that reconciles cash-on-delivery, the discount someone applies by hand for wholesale accounts. Those are requirements, and they are invisible in the old platform's export.

Phase 2 — Backend Build and Custom Modules

Stand up the Medusa server, model the catalogue, and build the custom modules that carry your differentiating logic. Integrate payment providers, shipping and courier APIs, tax rules per region, and the ERP or accounting system. Ship the admin extensions your operators will actually use — a module without an admin screen is a feature only developers can operate.

Phase 3 — Storefront Development

Build the Next.js storefront against the Store API. Catalogue and category pages render statically and serve from the edge with cache tags keyed to the entities they contain; cart, checkout, and account routes stay dynamic and are excluded from any shared cache. When a price or stock level changes, a subscriber fires targeted revalidation for exactly the affected tags — no full rebuild, no waiting for a TTL. Structured product data, hreflang alternates for multi-language storefronts, and Core Web Vitals budgets are part of the build, not a post-launch optimization pass.

Phase 4 — Data Migration and Reconciliation

Products, variants, media, customers, price lists, and historical orders move into a staging environment first. The output is a reconciliation report comparing source and destination record by record — counts, totals, and spot-checked entities. You do not schedule a cutover until that report is clean.

Phase 5 — SEO Continuity

This is where migrations quietly destroy value, and it deserves its own phase.

Build a complete URL map from the old structure to the new one and implement permanent redirects for every product, collection, blog post, and paginated listing — including the platform-specific paths (/products/, /collections/) that will otherwise 404 at scale. Preserve canonical tags, structured data, and metadata. Submit updated sitemaps and keep the old ones resolvable through the transition. Then monitor crawl stats, index coverage, and rankings for the following weeks rather than assuming success.

A technically flawless replatform that loses organic traffic is a failed replatform. Search rankings are an asset on the balance sheet; treat the redirect map with the same seriousness as the order data.

Phase 6 — Cutover and Hypercare

Cut over during a genuine traffic trough, with the old store warm and a rollback path tested rather than theorized. Then run intensive monitoring — order flow, payment capture, fulfillment webhooks, error rates, Core Web Vitals — for the first weeks. Most migration defects appear in the long tail of real orders, not in QA.

A focused store with a standard catalogue, one payment provider, and a single locale typically reaches production in six to ten weeks. Builds involving custom pricing engines, B2B quote workflows, ERP integration, or multi-locale catalogues generally run three to five months. Phase the scope so a revenue-generating version ships before the full roadmap is complete.

When You Should Not Migrate

A consultancy that recommends its own service in every scenario is not giving advice. Stay on your hosted platform if:

• Your catalogue and commercial model fit the template. If your workarounds are cosmetic rather than structural, migrating buys you nothing you can measure.
• You have no engineering capacity and no intention of acquiring any. Open headless commerce assumes someone owns the code and the infrastructure. If that someone does not exist internally and you are not retaining a partner, do not start.
• Your app stack is genuinely additive. If your apps deliver capability rather than compensate for constraints, you are getting fair value for the subscriptions.
• You are in a growth sprint with a hard deadline. Replatforming consumes senior attention for months. Doing it during a funding round, a major launch, or peak season is how migrations get abandoned half-finished — the worst of both architectures.
• Peak-season uptime is your single greatest risk and you have no ops maturity. The vendor's pager is worth real money. Do not give it up until you can carry it.

The right time to migrate is when the platform is demonstrably blocking revenue, you have or can retain the engineering capacity to own the replacement, and you are far enough from peak season to absorb a transition.

Frequently Asked Questions

Is MedusaJS production-ready for high-volume stores? Yes, with the caveat that "production-ready" is a property of your deployment, not just the software. Medusa is a Node.js application backed by PostgreSQL and Redis — it scales the way any well-built stateless service scales, horizontally behind a load balancer with read replicas and a properly sized cache. What determines whether it survives Black Friday is the infrastructure engineering around it: connection pooling, index strategy, queue depth monitoring, CDN configuration, and capacity tested before you need it rather than during.

How long does a Shopify to Medusa migration take? Six to ten weeks for a focused store with a standard catalogue, one payment provider, and a single locale. Three to five months when custom pricing engines, B2B quote workflows, ERP integration, or multi-locale catalogues are in scope. Phase it so revenue starts flowing through the new platform before every feature is complete.

Will we lose our search rankings? Not if URL continuity is treated as a first-class requirement rather than a launch-week checklist item. A complete redirect map, preserved canonicals and structured data, updated sitemaps, and active monitoring of crawl and index coverage through the transition are what protect rankings. Migrations lose traffic when redirects are partial — typically on paginated listings, filtered collection URLs, and blog content nobody remembered to map.

Can we keep using Shopify for part of the business? Yes, and it is often the lowest-risk path. A strangler-pattern migration runs both systems concurrently — new market, new B2B channel, or new product line launches on Medusa while the existing storefront keeps trading. You validate the new platform against real orders before betting the core business on it.

What about PCI compliance without a hosted platform? Card data still never touches your servers when you use a payment provider's hosted fields or elements — the processor holds it. What changes is that the self-assessment questionnaire, the TLS and dependency posture of the payment page, and the infrastructure around it become your responsibility rather than the vendor's. It is manageable and routine, but it is real work that belongs in the plan.

Do we need to hire an in-house team? You need someone accountable for the code and the infrastructure — internal, retained partner, or both. The failure mode we see most often is a store built by an agency, handed over with no operational agreement, and left unpatched and unmonitored until an incident forces the issue.

What happens if we want to leave you later? Nothing dramatic. The stack is open source and self-hosted, the code lives in your repository, the environments are reproducible from infrastructure-as-code, and the modules are documented with their data models and API contracts. That is the point of avoiding lock-in — it has to apply to your vendors too, not only the platform.

The Strategic Read

The migration from Shopify Plus to MedusaJS is not fundamentally a technology decision. It is a decision about where your commercial logic lives.

On a hosted platform, the parts of your business that make you different sit in apps, metafields, and middleware — outside the system of record, dependent on interfaces you do not control. On an open headless commerce platform, those same parts are first-class code inside the commerce engine, versioned in your repository, testable, and upgradeable on your schedule.

For a business whose model fits the template, the first arrangement is a bargain. For a scale-up whose growth depends on selling in a way the template cannot express, it is a ceiling that gets lower every quarter.

Ecommerce is not a template problem. It is a systems problem wearing a storefront.

IQAAI Technologies designs, builds, and operates custom ecommerce platforms on MedusaJS — bespoke commerce modules and plugins, headless Next.js storefronts, Shopify and WooCommerce migrations with SEO continuity, and SLA-backed managed infrastructure underneath all of it.

• Explore our MedusaJS ecommerce development services
• Read the technical detail on custom Medusa module and storefront engineering
• Or talk to our engineering team about whether replatforming is the right call for your business — including when it is not.