Migrating to Medusa: How to Replatform Without Losing the Business

Replatforming is the most expensive thing an ecommerce team does that produces no new features. Done well it is invisible to customers. Done badly it takes out a quarter.

This is the platform-agnostic version: how to decide, how to sequence, and where the money actually goes. Platform-specific detail lives in the Shopify, WooCommerce and Magento guides.

First: should you migrate at all?

We turn down roughly a third of the migrations we are asked to quote, because the honest answer is no. The test we apply is whether the team can complete this sentence with something specific:

"We cannot do X, and it is costing us Y."

Good answers, all real:

• +"We cannot offer net-30 terms to trade customers, and we are losing wholesale deals to a competitor who can."
• +"Our payment processor is one policy review from dropping us, and we have no way to fail over."
• +"Platform and app fees are $18k a month and scale with revenue we already earn."
• +"Every checkout change is a workaround, and the last one took four months."

Bad answers: "the admin feels dated", "we want to be headless", "our developers prefer React". Those are preferences. They do not survive contact with a migration budget.

The readiness check

Before scoping, confirm four things:

1. You have or will have engineering capacity. Medusa is a framework you operate. A migration with no ongoing owner produces an unmaintained app within a year.
2. You know your integration surface. ERP, 3PL, tax engine, email, reviews, analytics, subscriptions. List every system that touches an order. This list, not the catalog, determines the timeline.
3. Your data is exportable. Verify it before you plan. Some platforms make historical order export genuinely painful.
4. You have a rollback story. Keep the old system read-only and operable for 30 days after cutover.

Sequencing: hard things first

The instinct is to start with the catalog because it is tractable and shows progress. Resist it. Catalog import is a solved problem you can do in week seven as easily as week one. Payments, subscriptions and integrations are where projects die, and they need discovery time.

Our default order:

Weeks 1–2 — Discovery and the hard integrations. Map every system. Start payment provider applications. Prototype the riskiest integration end to end, even crudely. If the ERP has no usable API, you need to know in week one.

Weeks 2–4 — Domain modelling. What is core commerce and what is custom? Model the custom parts as modules and workflows now, because they constrain everything downstream.

Weeks 3–6 — Storefront. In parallel. A Next.js storefront against a partially seeded backend is fine.

Weeks 5–7 — Data migration. Catalog, then customers, then orders. Write it as a repeatable importer, not a one-off script. You will run it many times.

Weeks 7–9 — Integration and hardening. Real payments, real shipping rates, real tax. Load test. Fix what breaks.

Week 9–10 — Cutover. Redirects, DNS, monitoring, and a fortnight of watching Search Console.

The data migration rules

Four rules that hold across every source platform:

Keep the identifiers. Product handles, SKUs and order numbers should survive the move. Handles drive your redirect map, SKUs drive your 3PL and ERP, order numbers drive support.

Import orders as records. Never replay historical orders through the live checkout workflow — you will reserve inventory, authorise payments and email customers about purchases from 2023.

Decide about metadata explicitly. Every platform has an escape hatch — Shopify metafields, WooCommerce post meta, Magento EAV attributes — and every store has abused it. Anything you query or validate becomes a real field on a module. Only genuinely inert display data belongs in metadata.

Make it idempotent. The importer will run a dozen times. Re-running should update, never duplicate.

Protecting search traffic

Organic traffic is the asset most easily destroyed by a replatform, and it is destroyed the same way every time: someone treats redirects as a launch-week task.

• +Pull ranking URLs from Search Console, not the sitemap. Sitemaps describe what you think exists; Search Console describes what Google indexed.
• +Map every one to a destination. Where there is no equivalent, redirect to the closest parent category — never to the homepage, and never leave a 404 on a URL with links pointing at it.
• +Implement redirects at the edge or in framework config, not in application middleware.
• +Preserve titles, meta descriptions and structured data. A rebuild is a good moment to improve them, and a terrible moment to lose them.

Details in Medusa storefront SEO.

Where the budget goes

The line people forget entirely is parallel running: for one to three months you pay for both platforms. Budget it.

Failure modes, ranked

1. No redirect map. Costs the most, easiest to avoid.
2. Subscriptions migrated last. They are the hardest thing and they need the most runway.
3. Big-bang cutover with no rollback. Keep the old system warm.
4. Modelling custom logic as metadata. Fast to build, expensive forever.
5. No owner after launch. The migration succeeds and the platform rots.

The two-week discovery

Before quoting anything, we run a fixed-scope discovery. It is the cheapest way to turn a guess into a number.

The prototype in days nine and ten is what separates this from a document. If the ERP has no usable API, you learn it for the cost of two days rather than in week seven of a fixed-price build.

Post-launch, weeks one to four

Migrations are not finished at cutover. What we watch, in order:

Week 1 — Search Console daily. Coverage errors, crawl anomalies, redirect chains. This is when a bad redirect map is still cheap to fix.

Week 1 — Order flow hourly. Compare orders per hour against the same weekday last month. A drop that is not traffic is a checkout problem.

Week 2 — Support ticket themes. Cluster them. Three tickets about the same confusing step is a UX bug, not three customers.

Weeks 2–4 — Conversion by step. Against the pre-launch baseline you captured. Any step worse than before gets investigated before anything new is built.

Week 4 — Decommission plan. Only once the above are clean does the old platform go read-only and then away.

The teams that struggle are the ones who treat launch day as the end of the project and reassign everyone the following Monday.

If you are weighing a migration, the cheapest useful thing is a two-week discovery: integration map, data audit, risk list and a real number. That is a conversation we are happy to have.