Shopify Migration vs. Replatforming: Which One Are You Actually Doing?

Two projects arrive with the same opening sentence. "We're on Magento and we want to be on Shopify." One of them is a twelve-week job. The other reorganizes how four teams work and runs most of a year.

The words we use for them barely distinguish them. Migration and replatforming get swapped freely in sales calls, RFPs, and internal decks, usually meaning nothing more precise than "we are changing platform." That vagueness is harmless right up until someone attaches a budget to it.

The distinction that actually matters

This is not a vocabulary argument. The two words describe projects with different scopes, different risk surfaces, and different people who have to say yes.

A migration is bounded by the store. You audit what is in the source system, decide what maps to what, move it, redirect the URLs, and verify the result. It is detailed work with real ways to go wrong — but the boundary is legible. When it is finished, the same business runs the same way on better software.

A replatform is bounded by the business. The store is one component. Around it sit the systems that feed it and consume from it, the processes people run against it, and the decisions about which of those survive the move unchanged. When it is finished, the business does not run quite the way it did — which is usually the point, and is also the part nobody scoped.

Read that last row twice. It is the row that separates a project that finishes from one that quietly does not.

Four questions that tell you which one you are in

You do not need a discovery phase to get a rough answer. Four questions get you close.

How many systems write to or read from your store? Not apps — systems. An ERP holding master product data. A WMS that owns stock levels. A 3PL that receives orders and returns tracking. A finance export. A CRM. If the honest answer is zero or one, you are migrating. If it is four, you are replatforming, whatever anyone is calling it.

How many teams change how they work? If the answer is "the marketing team learns a new admin," that is a migration. If the warehouse changes how it picks, support changes how it processes returns, and finance changes how it reconciles, the storefront is the smallest thing you are shipping.

Are you consolidating anything? Two storefronts becoming one. Three regional sites becoming one store with markets. A B2B site folding into the D2C platform. Consolidation is never a migration — it is a set of business decisions with a data move attached.

Could you describe the end state without mentioning the website? If yes — "orders reach the warehouse without the nightly CSV," "we can open a new market without a new build" — the project is about the platform's role in the business, not the platform.

What a replatform adds that a migration does not

Three things, and each one adds time in a place migration estimates do not account for.

The integration layer sets the schedule

On a migration, the data audit is the critical path — you cannot scope until you know what you have. On a replatform, the data audit still happens, but it is no longer the thing everyone is waiting on. The integration inventory is.

Every connected system needs a decision: re-point it at Shopify's APIs, replace it with an app that genuinely covers the case, put a middleware layer in between, or accept a documented manual process for a while. Those decisions have lead times you do not control. A vendor has to confirm their connector supports what you need. An internal team has to free up someone who understands the nightly job. A contract has to be renegotiated because the current integration is bundled with the platform you are leaving.

This is the part that turns a twelve-week estimate into a nine-month program, and it does it long before anyone writes theme code.

Operations change, not just the store

Shopify models things a certain way. Orders, fulfillments, locations, inventory, customers, and B2B relationships all have a shape, and that shape will not match your current one exactly. Somewhere in the project, a person whose job depends on the current shape has to agree to a new one.

That agreement is not a technical task and it does not fit in a sprint. It needs the person to understand what is changing, to say what would break, and to have time to adjust before the platform switches under them. Migrations that ignore this launch successfully and then generate three months of support tickets from inside the company.

Someone has to own the decision record

A migration has few decisions worth writing down and a short enough timeline that everyone remembers them. A replatform accumulates hundreds of decisions over months — which fields survive, what the interim process is for returns, why the B2B store goes in phase two — and the people who made them rotate.

Without one written record, month five re-litigates month one. With one, the project can change its mind on evidence instead of on whoever spoke last.

Phasing: the question migrations never have to answer

A migration cuts over once. There is one store, one data set, one date.

A replatform has to decide, and the decision is genuinely hard. A single cutover is simpler to reason about, keeps one source of truth, and shortens the window where you are maintaining two systems. Phasing lets you de-risk by moving one region, brand, or channel first, and it buys time for an integration that cannot be ready.

The thing that makes phasing work or fail is whether the split is clean. Separate regions with separate inventory, separate fulfillment, and separate catalogs phase well. A split that runs through shared stock, a shared order flow, or a shared customer record does not — you spend the phase period reconciling two systems that both believe they are authoritative, and the reconciliation costs more than the risk you were avoiding.

That answer comes out of the systems inventory. It does not come out of a preference for moving fast or moving carefully.

When it is genuinely just a migration

None of this argues that every platform move is a program. Plenty are not, and treating a straightforward move as an enterprise transformation wastes money just as effectively as the reverse.

If your store is the system of record, your integrations are a handful of installed apps, one team runs the whole thing, and you are not consolidating anything, it is a migration. Audit the data properly, map every URL, decide what you are not bringing across, make the imports repeatable, write the cutover runbook, and go. The discipline that makes it succeed is thoroughness, not governance.

The platform you are leaving is a decent hint. Wix and BigCommerce moves are usually migrations — the store was the system, and there is not much attached to it. Magento, Salesforce Commerce, and custom builds usually are not, because platforms that flexible tend to have accumulated business logic and integrations that were never documented anywhere else.

The real cost of the wrong label

Getting the word wrong does not just misprice the work. It puts the wrong people in the room.

Scoped as a migration, the project gets budgeted by whoever owns the website, estimated against the storefront, and staffed accordingly. The integration work has no line item and no owner. It surfaces in month three, at which point the options are all bad: absorb it and blow the budget, defer it and launch with manual processes nobody agreed to, or stop and rescope with the storefront half-built.

Scoped as a replatform, the same work is visible before anyone commits. The assessment costs a fraction of the build, it produces a number you can defend to a finance team, and its most valuable possible output is the finding that you should not do the project at all — that the constraint you are trying to escape is cheaper to fix where you are.

That is not a comfortable thing for an agency to recommend. It is considerably more comfortable than the month-three conversation.

Where this lands

Ask what the project is bounded by. If the answer is the store, you are migrating: be thorough about the data and the URLs, and treat it as the detailed, finishable job it is. If the answer is the business, you are replatforming, and the storefront is the least of it.

The projects that go badly are rarely the ones that were hard. They are the ones that were scoped as the smaller of the two.

If you are weighing a move and are not sure which one you are looking at, tell us what is connected to your store — the systems inventory is usually enough to settle it, and it is worth knowing before the budget conversation rather than after. More on how we approach the larger version is on our Shopify replatforming page.