When to replatform your store, and when not to

Replatforming a store is one of the most expensive things a commerce team can choose to do, and a good share of the replatforms we get asked about should not happen. The platform is rarely the actual problem. Here is how to tell when it is.

Four signals that justify a replatform

1. You cannot build commerce logic the business needs. The platform's model can't express your pricing, bundling, subscription, or B2B quote-and-approve requirements, and you have hit a wall that apps and workarounds don't solve. This is the strongest signal: it is a hard block, not a friction.

2. Fees scale with revenue in a way that now hurts. Revenue-share percentages, per-order fees, or forced tier jumps have become a large, growing line item, and the money would be better spent running infrastructure you own.

3. You are locked out of your own data or roadmap. You can't get at the underlying data the way the business needs, or a vendor can change pricing, deprecate a feature you depend on, or gate something behind an enterprise tier with no recourse.

4. The platform is a genuine performance ceiling. You have optimised what you can and the platform's rendering, or its checkout, is measurably costing conversion, and you have the analytics to show it.

Three signals that do not

"We want a redesign." A redesign is a storefront project. On most platforms, including headless setups, you can rebuild the entire front end without touching the commerce backend. Replatforming to get a new look is paying for an engine swap to buy a paint job.

"The codebase is a mess." A messy theme or a pile of half-abandoned apps is a refactor, a cleanup, and some discipline, usually months cheaper than a migration, and you keep all the institutional knowledge baked into the current system.

"A competitor moved to X." Their constraints are not your constraints. The question is whether your platform blocks your business, not what someone else did.

If it is justified, de-risk it

A replatform that is genuinely needed still fails when it is done carelessly. Three rules:

• Protect SEO from day one. Map every indexed URL, redirect anything that changes with clean 301s, and reproduce metadata and structured data exactly. This is a workstream, not a checklist item; see replatforming without losing SEO.
• Migrate in phases. Move the catalogue, then customers, then order history, each in tested batches against a copy of production. Don't attempt a single big-bang data migration on cutover night.
• Run both systems in parallel. Before cutover, have the new system process real data (real carts, real charges, real orders) alongside the old one for at least one full business cycle, and diff the results.

The decision in one line

Replatform when the platform is a hard block on the business: logic you can't build, fees you can't escape, data you can't reach. For everything else, fix what you have. When you do move, treat SEO, data migration, and parallel running as first-class parts of the project, not things you get to at the end.

If you are weighing a specific move, our process starts with exactly this question before any code is written.