Skip to content
Senior web & app development · 20 capabilities
oakstone.digital
Journal / ecommerce

When to replatform your store

Replatforming is expensive, disruptive and occasionally the only sensible option. Here is how to tell which situation you are in.

Published /By , Commerce/3 min read

Signals that justify it

Five reasons hold up under scrutiny: your platform is end-of-life or unsupported; licence and hosting costs have outgrown the value; merchandising changes require engineering every time; the platform cannot express your pricing or account model; or performance is capped below what your traffic needs.

Notice that four of the five are operational rather than technical. That is usually where the real cost sits.

Signals that do not

Three common reasons do not survive examination. The site looks dated — that is a theme project. Conversion is poor — that is usually product pages, speed and checkout friction, all fixable in place. A new hire prefers a different stack — that is a preference, not a business case.

Replatforming to fix conversion is the most expensive way to run an experiment you could have run in a fortnight.

Price the migration honestly

The build is the visible cost. The real budget includes data mapping and reconciliation, several hundred redirects, integration rewiring, staff retraining, and a period of reduced merchandising velocity while everyone learns the new admin.

There is also a ranking risk. It is manageable with a proper URL map and monitoring, but it is not zero, and any agency telling you otherwise has not done enough of them.

A staged path exists

You do not always have to move everything at once. Content can move ahead of commerce, a single region or brand can pilot the new platform, and the old system can keep serving legacy order history behind an internal tool.

Staging costs a little more in total and removes most of the risk that makes replatforming frightening.

The cheaper experiment to run first

Before committing to a replatform on conversion grounds, spend three weeks on the current platform doing four things: fix the product page, remove or defer every third-party script you cannot justify, cut a step from checkout, and put real delivery information in front of the buyer.

If conversion moves meaningfully, you have your answer and you have saved a six-figure project. If it does not move at all, you now have evidence that the constraint is structural — which is a far stronger business case to take to a board than a preference for a different admin.

Questions people ask about this

Four to seven weeks for a single store with a few hundred SKUs, including a full dry run. Multi-currency, multi-store or subscription-heavy migrations run three to five months, mostly in reconciliation and integration testing.

A short dip of one to three weeks is common; a permanent loss is not, provided every indexed URL is mapped, structured data is rebuilt and coverage is monitored daily through the transition.

Yes. Customers, addresses, orders and subscription state migrate and should be reconciled line by line against the source system before cutover. Where a platform cannot hold a legacy field, agree an archive strategy rather than dropping it quietly.