Replatforming eCommerce Without Breaking the Business: A Migration Path Comparison

A replatform is not a catalog transfer. Products and customers move with tooling; the parts that break are the ones nobody listed. What carries across cleanly, what has to be rebuilt, and what quietly loses its search rankings differ by migration path, and comparing those paths is worth doing before a timeline gets committed to a board.

The constraint that decides the path is not budget and it is not risk appetite. It is whether your team can operate two systems at once for a period of months. That capacity, more than anything on a vendor’s comparison sheet, eliminates most of the options that look attractive in a proposal.

The binding constraint: can you run two systems simultaneously

Every migration path other than a single cutover requires a period where both the old and new systems are live and both are real. That period places demands that do not appear in a project budget.

Inventory has to be accurate in two places, or authoritative in one with the other reading from it. Orders arrive on both sides and have to reach one fulfilment process. Customer service needs to know which system a given customer is on before answering anything. Finance reconciles two sources for the duration. Marketing runs campaigns that must work on whichever system the traffic lands on. And someone has to hold the whole picture in their head while the normal operating year continues around them.

That is dual-running capacity, and it is a function of team size, process maturity, and how much slack exists in the calendar. A brand with four people covering eCommerce operations does not have it, regardless of how much budget is available, because the constraint is attention rather than money.

Ask the question directly before evaluating any path: for three to six months, can we operate two live commerce systems without degrading the one that is currently paying for everything. The answer eliminates more options than any feature comparison will.

What that rules out

If dual-running capacity is absent, phased and parallel approaches are not safer alternatives. They are higher-load alternatives that happen to spread risk over more time, and the load lands on the same team that is already running the business.

This inverts the way these paths are usually presented. Phased migration is marketed as the lower-risk option because no single moment carries everything. Operationally it is the higher-burden option, because it extends the period of maximum complexity from one weekend to two quarters. For a team without slack, the risk simply relocates: instead of a difficult cutover weekend, you get four months of accumulating small failures that nobody has time to fix properly.

Two further eliminations follow from the same constraint.

A migration cannot run through your peak trading period. Whatever the path, the dual-running or cutover window has to sit outside the season your business depends on, which for most European brands means the window is narrower than the project plan assumes.

And a migration cannot be scoped around rebuilding everything. Teams without dual-running capacity need the rebuild list to be short, which makes the asset audit below the first piece of real work rather than a documentation exercise.

The three-bucket audit: carries, rebuilds, retires

Before comparing paths, sort what you have into three buckets. This is the audit that determines project size, and it is routinely skipped in favour of a data migration plan.

The distinction that matters inside the second bucket is whether a customisation encodes genuine business logic or works around a platform limitation. Our analyses of migrating from Sylius and from Lightspeed both land on the same finding: brands consistently underestimate how much of their custom build exists to compensate for the platform they are leaving. Those items belong in the retire bucket, not the rebuild bucket, and moving them across is how a six-month project becomes a twelve-month one.

There is a fourth category worth naming separately, because it does not behave like the other three.

Search visibility is a separate risk class

Rankings do not migrate. They are re-earned, on the new URLs, after the new site is crawled, and the mechanism by which they are preserved is entirely under your control and entirely easy to get wrong.

Four things carry most of the risk. URL structure changes, which is normal in a replatform and requires a complete redirect map from every old URL to its closest new equivalent, not to the homepage. Internal linking, which is frequently rebuilt from scratch by a new theme and silently drops the structure that distributed authority. Structured data, which theme and app changes routinely alter. And page content itself, where a migration is often used as an opportunity to shorten copy, removing the text that was ranking.

The failure mode is specific and common: the site launches, everything works, and traffic declines over the following six weeks in a way that looks like seasonality until it does not recover. By then the redirect gaps are months old.

The mitigations are unremarkable and effective. Crawl the current site completely before anything changes, so you have a full URL inventory rather than a sitemap. Build the redirect map against that inventory, one to one wherever a match exists. Preserve internal linking structure, or rebuild it deliberately rather than accepting what a theme produces. Validate structured data on the new templates before launch, not after. And resist the temptation to rewrite content during the migration, since it makes any traffic change impossible to diagnose.

This is also where the phased and parallel paths carry a hidden cost: for the duration, two versions of your content can be live and crawlable, which is a canonicalisation problem you now have to manage on top of everything else.

The three paths that genuinely work

The path most mid-market brands should choose is the one their capacity permits rather than the one that sounds safest. For a lean team with contained scope, a single cutover into a quiet trading window is usually both cheaper and less risky than a phased approach nobody has the attention to run properly.

Phased earns its keep when the business is genuinely separable. Moving wholesale before retail, or one market before the rest, works when those segments have distinct catalogs, customers, and operational processes. It works poorly when the split is artificial, because the two halves keep needing to talk to each other.

Selection rules

1. Answer the dual-running question first. No capacity means single cutover, and the project plan should be built around making that cutover small enough to succeed.
2. Complete the three-bucket audit before setting a timeline. The rebuild bucket determines duration. A timeline set before that audit is a guess presented as a commitment.
3. Fight for the retire bucket. Every workaround carried across is permanent cost. This is the highest-leverage conversation in the whole project and it is organisational rather than technical.
4. Choose phased only if the segments are genuinely independent. Distinct catalog, distinct customers, distinct processes. If two of the three overlap, phasing creates integration work that would not otherwise exist.
5. Treat search continuity as a workstream with an owner, not as a launch checklist item. Full crawl before changes, redirect map one to one, internal linking preserved, structured data validated pre-launch.
6. Do not rewrite content during the migration. Change one variable at a time, or you will not be able to diagnose what happened.
7. Book the window against your trading calendar first, then plan backwards. The window is the least flexible input in the project and the one most often treated as adjustable.

If you already know which platform you are moving to, the path detail is in the source-specific guides: migrating from PrestaShop, from WooCommerce, or from Lightspeed. If the platform decision itself is still open, that is a different question and it comes first, covered in our piece on choosing an eCommerce platform when you outgrow the first.

A replatform readiness review surfaces what will and will not carry across before a timeline is committed. Flatline maps the three buckets and the search continuity plan against your trading calendar, which is the work that determines whether the date you announce is one you can hold.

When the constraint can be relaxed

Two situations change the calculus.

A temporary operational hire or partner. Dual-running capacity can be bought, in the form of interim operations support that absorbs the reconciliation and exception handling during the overlap. This is a real option and it should be costed explicitly rather than assumed away, because the alternative is that the same work lands on people who also have day jobs.

A genuinely separable segment. If one part of the business runs on its own catalog, its own customers, and its own processes, phasing that segment first is low-risk regardless of overall capacity, because the overlap is bounded to a segment rather than spanning the whole operation. Wholesale is frequently the cleanest candidate.

Outside those two, treat dual-running capacity as fixed. It is the input most likely to be optimistic in a project plan and the one that determines whether the plan survives contact with a normal trading month.

Frequently Asked Questions

How long does an eCommerce replatform take? 

The data migration is measured in weeks and is rarely the constraint. Duration is set by the rebuild bucket: how many customisations, integrations, and pieces of commercial logic have to be reconstructed. Complete the three-bucket audit before committing to any timeline, because a date set before that audit is an estimate of work nobody has scoped.

Will we lose search rankings when we replatform? 

Some volatility is normal; sustained loss is usually preventable. The recurring causes are incomplete redirect maps, internal linking rebuilt from scratch by a new theme, structured data altered by template changes, and content shortened during the move. Crawl the existing site completely before anything changes, map redirects one to one against that inventory, and change content separately from platform.

Is a phased migration safer than a single cutover? 

Not automatically. Phasing spreads risk across time and raises operational load for the whole period, because two live systems have to be reconciled continuously. It is genuinely safer when the business has separable segments and the team has slack to run both. For a lean team with contained scope, a well-planned single cutover into a quiet window is frequently the lower-risk choice.

What is most often underestimated in a replatform? 

Two things. How much existing customisation exists to work around the platform being left, which belongs in the retire bucket rather than the rebuild bucket. And how much attention dual-running consumes from a team that still has to run the business through the entire period.

Key Takeaways

• Dual-running capacity is the binding constraint, not budget. If the team cannot operate two live systems for months without degrading the current one, phased and parallel approaches are higher-load rather than lower-risk.
• Sort assets into carries, rebuilds, and retires before setting a timeline. The rebuild bucket determines duration, and the retire bucket is where the most value sits and the most resistance appears.
• Search visibility is re-earned rather than migrated. Full crawl before changes, one-to-one redirect mapping, preserved internal linking, and validated structured data are the mitigations that work.
• Choose the path your capacity permits. A lean team with contained scope is usually better served by a single cutover into a quiet trading window than by a phased approach nobody has the attention to run properly.

The decision that damages businesses is not choosing the wrong path. It is committing to a date before the three-bucket audit exists, then compressing the search continuity work because it is the only part of the plan with no visible deadline attached.