The website replatforming guide:
move without losing what you built.

Should you replatform at all?

Only replatform when the platform itself is the limit. That means the problem is built into the software, not into how your site was built. That difference decides everything. A replatform is the most expensive and riskiest way to fix a website. Many briefs that say 'we need a new platform' really mean 'our current build is bad'.

The two problems look alike from the boardroom. A slow, fragile site on a capable platform needs renovation. That means rebuilding templates, speeding up the site, cutting plugins and fixing old shortcuts. That work is cheaper and faster, and carries almost none of a migration's risk. If a previous supplier left the site in a mess, that's a rescue job. Our fix and rescue team handles exactly that, and it isn't a reason to change platforms.

A real platform limit feels different. Every merchandising change waits for a developer. Licence and add-on costs climb while what you can do stays the same. The integration your business now depends on can't be built. Or the vendor has announced the end of the product, or security updates have stopped. If the limit remains even with a good build, the platform is the problem. Then a move is worth pricing.

What could you lose when you replatform?

Every replatform puts four things at risk: your data, your search rankings, your integrations and your team's know-how. List all four before you choose a new platform, not after. What you could lose decides which platforms are even possible. And a loss you never counted is a loss you'll never notice.

This list isn't red tape. It's what makes 'zero data loss' something you can check, rather than a hope. Count exactly what exists at the start: products, orders, customers, pages, media files, URLs, API connections and scheduled jobs. After the move, you can check the new site against that count, record by record. Without the count, 'nothing went missing' just means 'nobody has noticed yet'.

Which platform should you move to?

Choose the new platform by answering three questions in order. How do you sell? Who will maintain the site? And what must it connect to? Platform marketing answers none of these, because every vendor's homepage promises everything. So start from how your business works, not from feature lists.

How you sell narrows the field fastest. A catalogue-led store with a normal checkout suits a commerce platform. A content-led business publishing daily has quite different needs. Some brands must sell through apps, marketplaces and in-store screens at once. They need an API-first set-up, where one back end feeds many storefronts. Who maintains the site narrows the field further. A platform your team can't run without an agency on retainer is a dependency, not a capability. The integration list from your risk check is the hard filter. A platform that can't talk to your ERP is ruled out, however good the demo looked.

Two honest notes on the shortlist. First, if your limit is content rather than commerce, the same approach applies with different options. A publisher outgrowing its CMS usually chooses between good WordPress development and a headless content system. Shop platforms don't come into it. Second, commerce set-ups rarely fit one label neatly. Our eCommerce development team spends as much time steering clients off the wrong platform as building on the right one. The most expensive migration is the one you have to do twice.

How does a migration run without losing anything?

A careful migration runs in a fixed order: inventory, redirect map, build, rehearsal, switch-over, with a rollback plan ready. It never skips steps under deadline pressure. 'Zero data loss' isn't luck; it's a checking standard. Nothing on the old platform is switched off until its replacement matches the inventory. If a check fails, the switch-over stops until it passes. That is the whole method, and each step below applies it in order.

This is how our own migration projects run, and it works in practice. Take our published commerce case. Al Majed for Oud's full catalogue, order history and customer records moved with zero data loss. Every historic URL carried a mapped redirect. With its search rankings intact, the rebuilt store went on to 340% revenue growth in 7 months. Read how the move was planned. The steps above are what made that growth possible.

What do you watch after launch?

The migration ends when your numbers settle back to where they were before the move. Going live is not the end. Record that baseline before the switch: traffic, rankings, conversion rate, revenue, error rates and page speed. After launch, it's the only honest way to tell 'the move broke something' from 'sales are always slow on Tuesdays'.

The first week is about errors. Read the 'page not found' (404) logs daily against the redirect map. Watch server errors and response times, and test every payment method and integration with real orders. The first month is about search. Check that Google crawls and indexes the new URLs, and fix any chains of redirects. Track rankings with honest expectations: some movement in the weeks after a well-run move is normal. Anyone promising none is selling something. A steady decline after that is a fault to find, and the redirect map is the first place to look. Ongoing SEO monitoring is there to catch it early.

Two final habits. Watch conversion separately from traffic. A move that keeps visitors but loses checkouts has a design or speed problem the traffic graph will never show. And switch the old platform off last. It's your rollback insurance and your reference for checking records. Turn it off only when the numbers have settled, the fix list is clear and nothing still depends on it. Turning it off early to save a month's hosting can make a small problem impossible to fix.