Shopify to Medusa Migration: The Honest Guide (2026)

I am Manoj, an open-source implementation consultant at Mith Tech in Bengaluru. I build Medusa.js storefronts for brands leaving hosted platforms,. This is a guide to work I do commercially — which is exactly why the first section is a list of reasons not to do it. Honest take: I turn down more of these projects than I take, because most stores asking for one have a problem a migration will not solve.

Should you actually migrate?

Probably not, and it is worth ten minutes to be sure. Replatforming is one of the few decisions in ecommerce that is genuinely hard to reverse,. The failure mode is not a broken site — it is six months of leadership attention spent on infrastructure instead of on selling.

Run these three tests before anything else.

Test one: name the blocker in one sentence. Something Shopify will not let you do, that no tier or app fixes. "We cannot run multi-level purchase approvals for dealer accounts" passes. "It's expensive and support is bad" does not — the second is a grievance, and grievances get worse after a migration. Because you go from limited support to none.

Test two: rule out tier, scope and agency. A great deal of what merchants describe as a platform limitation is a Plus feature they are not paying for, a request outside a commerce platform's job, or a development partner who is the actual bottleneck. All three are dramatically cheaper to fix than replatforming.

Test three: do the fee arithmetic. Total your annual plan fee, platform transaction fee, gateway MDR, apps and currency conversion, and compare it to a developer plus hosting. The full fee stack breakdown walks that calculation. If the gap is not decisive, the economics do not support owning. For a sense of what you are moving to before you commit, the open-source Shopify alternative guide covers Medusa against the other options.

Skimmable summary: Migrate only if you can name a blocked capability in one sentence, have ruled out tier and agency problems, and the fee arithmetic is decisive. Support quality and monthly price are not sufficient reasons.

What data can you actually get out of Shopify?

Less than you assume, and the gaps are worth discovering now rather than in week three of the project.

Shopify's export is CSV-only, capped at roughly 15MB per file, with incomplete metafield support, and the standard data export reaches back only to 1 January 2019. Anything older is not in the file. There is also no raw database access — no SQL, no arbitrary joins, everything through rate-limited APIs.

Filter the matrix below by what survives. Four of the twelve categories do not come out at all — and the ones that catch people are never the ones they worried about.

Three of these need active work before you cancel anything:

1. App-owned data is not Shopify's to give you. Reviews, loyalty points, subscription contracts and support history live with the app vendor. Export each one separately, from that vendor, on their terms — and check whether subscription payment tokens can transfer at all, because often they cannot and every subscriber must re-authorise.
2. Analytics history is gone the day you leave. If years of attribution and cohort data inform how you buy media, warehouse the reports you actually use into your own store before cutover. Nobody does this and everybody regrets it.
3. Pre-2019 orders need a separate extraction path — API pulls, or an archive you accept living outside the new system as read-only records.

Skimmable summary: Products, customers and post-2019 orders export cleanly. Metafields are partial, app-owned data must come from each vendor, and analytics history, attribution and passwords do not export at all.

What breaks when you switch, and how do you protect SEO?

The URL structure breaks, and that is the single largest recoverable risk in the project.

Shopify forces /products/, /collections/ and /blogs/ into every URL and does not let you change it. Your new platform has no reason to reproduce those paths — which means every product, collection, blog post and policy page gets a new address, and every old address needs a 301 redirect mapped in advance. Miss a chunk of them and you lose the rankings those pages carried.

The full list of what needs handling on cutover day:

• A complete 301 map, product by product and collection by collection. Generate it from your export, not by hand, and test it against a crawl of your live site.
• Canonical tags, because Shopify products resolve under multiple collection paths and your new site should not inherit that duplication.
• Structured data — product, offer, review and breadcrumb schema all need rebuilding.
• The sitemap, regenerated and resubmitted in Search Console the day you cut over.
• Every pixel and conversion event. Note that Shopify's own checkout extensibility migration broke thank-you-page tracking for many merchants in 2025 — do not assume your current tracking is a healthy baseline. Verify it before you copy it.
• Customer accounts. Passwords cannot migrate; every customer is force-reset.
• Email deliverability. Shopify sent your transactional email from its own reputable infrastructure. Yours starts at zero — warm the domain weeks in advance.
• Subscription payment tokens, if you run subscriptions. Check portability with your processor early; this can single-handedly determine your timeline.

Skimmable summary: Shopify's forced URL structure means every page moves and needs a mapped 301. Also rebuild canonicals, schema, sitemap and pixels — and treat the forced customer password reset as a marketing campaign.

What do you have to build that Shopify was doing for you?

This is the part that determines whether the project succeeds, and the part every optimistic quote leaves out. Medusa gives you excellent commerce primitives — products, carts, orders, payments, inventory, promotions, an admin — as modular building blocks. It does not give you the operational surround.

None of it is exotic and all of it is real. It is also where the "'Just' developers and programmers is a VERY strong 'just'" objection comes from, and that objection is correct. The honest way to scope a migration is to price this table first and the storefront second.

One architecture decision saves an enormous amount of this pain, and it is the one I recommend by default: keep Medusa as the commerce layer and resist rebuilding back-office logic inside it. Medusa is very good at storefront, cart, checkout, orders, payments and inventory. It is not an accounting system, a warehouse management system or a manufacturing planner, and every hour spent making it pretend to be one is an hour not spent on the thing you migrated for. Point it at whatever finance and inventory systems you already run — that boundary is what keeps a Medusa build maintainable at year three.

Skimmable summary: Medusa provides commerce primitives, not operational surround. PCI, fraud, tax, email deliverability, hosting, patching and peak capacity all become yours — price these before the storefront.

How do you run the migration without betting the business?

In phases, on a channel that is not your main revenue, with both systems live at once. The single biggest predictor of a bad migration is a big-bang cutover with a fixed date near a sales peak.

On timelines, be sceptical of anything shorter than what practitioners report. A developer with 25 years' experience described six months for a full build. An experienced commenter advised budgeting honestly for the first twelve months of dev and ops before hitting stability. For a standard catalogue with a competent team, three to six months to cutover and a year to genuine stability is the realistic frame.

Skimmable summary: Audit and archive, build the commerce core until one order round-trips, build the plumbing, pilot on wholesale, cut over away from peak with a tested rollback, then watch rankings and 404s for 90 days.

What does it cost?

A Shopify to Medusa migration lands somewhere between a competent contractor's three months and a six-figure agency engagement, and the range is genuine rather than evasive — it is driven by four variables.

Set those four to your own situation:

For reference points from merchants rather than vendors: one experienced developer put a genuinely reliable from-scratch ecommerce build at around $300,000 and a year with an agency, while acknowledging it can be done for far less with more risk. A solo developer who migrated their own store did it in six months alongside maintaining the old one, and estimated one to two months if they had focused on it exclusively.

Medusa specifically is cheaper than "from scratch" because the commerce primitives already exist — a standard catalogue migration is often quoted at around a week of engineering for the data alone. The cost is in everything around it, which is why the plumbing table above matters more than the SKU count.

Skimmable summary: Cost is driven by catalogue size, integration count, B2B complexity and content volume. Merchant reference points range from six months solo to ~$300k and a year via an agency; Medusa reduces the build but not the surrounding work.

Frequently asked questions

How long does a Shopify to Medusa migration take?

Three to six months to cutover for a standard catalogue with an experienced team, and about a year to genuine stability. The data migration itself is often a week of engineering. What takes the time is rebuilding the operational layer Shopify provided invisibly — fraud, tax, transactional email, monitoring, load capacity — and running a proper parallel pilot before cutover.

Will I lose my Google rankings?

You will see a dip unless the redirect map is complete, because Shopify's forced /products/ and /collections/ URL structure means every page moves. Generate the 301 map from a crawl of your live site rather than by hand, deploy it at cutover, resubmit your sitemap immediately, and monitor 404s daily for a month. A well-executed migration typically recovers within weeks; a sloppy one may not fully recover at all.

Can I move my customers' passwords to Medusa?

No. Shopify does not export password hashes, so every customer must reset on their first return visit. Treat this as a planned marketing campaign — email customers before cutover explaining the change, make the reset one click, and give them a reason to come back — rather than as a silent technical event that quietly costs you repeat purchases.

What Shopify data can't I export at all?

Analytics history, attribution data, abandoned-cart detail and customer journey behaviour do not export. Neither do customer passwords. Orders before 1 January 2019 are outside the standard export. App-owned data such as reviews, loyalty balances and subscription contracts belongs to each app vendor and must be exported separately from each one, on their terms.

Is Medusa production-ready for a real store?

Yes — it is MIT-licensed, used in production by serious brands, and its commerce primitives are mature. The honest caveats are that its plugin ecosystem is thin compared to Shopify's app store, so more capability is built rather than installed, and that you need at least one developer permanently. Merchants who have moved consistently report loving the control and warning about the maintenance.

Should I move to Medusa or WooCommerce?

Medusa if you have or will hire a developer and want a modern, API-first, TypeScript stack with real B2B primitives. WooCommerce if your business is content-led, you already live in WordPress, and you accept a heavier security and maintenance burden — merchants describe it as capable but vulnerable to hacks and bugs. Both remove Shopify's per-sale platform fee; neither removes your gateway's MDR.

Does Medusa handle accounting and inventory, or do I need another system?

Medusa handles inventory as a commerce concern — stock levels, reservations, multi-location availability — which is enough for most D2C brands. It is not an accounting system and does not do bill of materials, landed costing or production planning. If you make or assemble goods, or you need statutory books, keep those in whatever finance system you already run and let Medusa own the commerce layer. That boundary is what keeps the build maintainable.

Closing

Every failed replatform I have seen failed for the same reason: somebody scoped the storefront and forgot the plumbing. The products import in an afternoon. The fraud tooling, the warmed sending domain, the tax rules, the load test before Diwali, the 301 map generated from a real crawl — that is the project, and it is where the months go.

So scope it in the right order. Price the plumbing table first, the storefront second, and pilot on wholesale before you touch your main channel. Do that and a Shopify to Medusa migration is a manageable engineering project with a known shape. Skip it and you will spend a year rebuilding, badly, what Shopify was quietly doing for $105 a month.