Replatforming: moving platform without losing sales or rankings

Move platform when the one you have is costing you sales or money that a new one would demonstrably win back, and not before. A replatform done well takes a few months, keeps your search rankings and pays for itself. Done badly, it loses a slice of organic traffic, breaks the link between the website and the warehouse, and leaves you with a new site that has the old problems.

Most of the risk sits in four places: the data you move, the URLs you redirect, the integrations you rebuild and the week you choose to launch. None of them is technically hard. They go wrong because they are planned late.

The short version

• Replatform for a reason you can put a number on: running cost, lost conversion, or something the business needs that the platform cannot do.
• If the real complaint is the design, the speed or the agency, fix that first. It is cheaper and you find out whether the platform was ever the problem.
• Map every old URL that earns traffic, links or sales to its new address with a permanent redirect, and test the map before launch.
• List every system that touches the store (stock, warehouse, accounts, email, feeds) before you choose the new platform, because integrations are where budgets overrun.
• Launch in your quietest trading period, early in the week, with a rollback plan and nobody on holiday.
• Treat the first thirty days as part of the project: watch errors, rankings and conversion daily and fix fast.

When should you replatform?

The honest reasons are few. We'd move when at least one of these is true and you can evidence it.

• The running cost is out of proportion. Hosting, licences, security patching and developer time add up to more than a comparable store costs elsewhere. Our guide to what a platform really costs shows how to total it properly.
• Change is slow and expensive. Simple things (a new landing page, a promotion, a payment method) need a developer and a release.
• The platform is reaching end of support, or the version you are on no longer gets security updates.
• The business has outgrown it. You need trade accounts, several countries, or stock across many locations, and the platform handles them poorly.
• It falls over at peak. If you dread your own busiest day, that is a commercial problem.

When moving is the wrong choice

A replatform is often the wrong answer to a real problem. We'd tell you to stay where you are if:

• The complaint is how the site looks or how fast it loads. A new theme or front end on the same platform is a fraction of the cost and risk.
• The real problem is traffic or conversion. A new platform does not create demand. A programme of testing and optimisation usually returns more, sooner.
• You are unhappy with your agency. Change the agency.
• Peak is less than four months away. Wait until January.
• Nobody inside the business can give the project real time. A migration needs an owner on your side who can make decisions weekly.

Direction matters less than fit. We moved Simply Sound and Lighting from Magento to Shopify because the old platform's costs were rising and it could not keep up with the business. For Notcutts, with loyalty, stock and ERP systems to connect in real time, Magento was the right destination. If you have not picked a platform yet, start with how to choose an e-commerce platform.

The migration plan, step by step

1. Audit what you have. Export a full list of URLs from your sitemap, analytics and Search Console. Record a baseline: organic sessions, rankings for your main terms, conversion rate, revenue by channel. Without a baseline you cannot tell a launch dip from a seasonal one.
2. Write down every integration. Stock, warehouse, couriers, accounts, email, reviews, feeds, marketplaces, finance providers. For each: what data moves, in which direction, how often.
3. Decide what to leave behind. Discontinued products, dead categories, extensions nobody uses. A migration is the cheapest moment to simplify.
4. Design and build on the new platform, on a staging address blocked from search engines.
5. Migrate data in rehearsal, at least twice, before the real run.
6. Build and test the redirect map.
7. Rebuild and test integrations with real orders end to end.
8. Freeze, launch, check.
9. Monitor for thirty days.

Data: what moves and what does not

Products, categories, customers and order history all move, but not always cleanly. Check these early:

• Products. Variants, options and attributes rarely match one to one between platforms. Decide the new structure before you import, not after.
• Customer passwords. These usually cannot be transferred. Shopify, for example, states that passwords cannot be imported, so customers are invited to set a new one. Plan that email and its timing.
• Order history. Decide how many years customers and your service team actually need.
• Subscriptions, gift cards, loyalty points and store credit. These are money owed to customers. Reconcile the totals before and after.
• Reviews and content. Reviews often live with a third party and need re-linking to new product IDs. Blog posts and guides carry rankings, so move them with their URLs mapped.
• Consent. Marketing permissions must travel with the customer record.

URL redirects and SEO

This is where rankings are kept or lost. Almost every platform has its own URL pattern (Shopify, for instance, puts products under /products/ and categories under /collections/), so most of your addresses will change.

• Map each old URL to its closest new equivalent with a permanent (301) redirect. Product to product, category to category. Sending everything to the home page throws the value away.
• Prioritise by value: pages with organic traffic, external links or revenue first. Then cover the long tail with pattern rules.
• Carry over page titles, descriptions, headings, copy, structured data and canonical tags. A redirect to a thinner page still loses ground.
• Crawl the staging site with the old URL list and confirm every one lands on a live page in a single hop.
• After launch, submit the new sitemap in Search Console and remove the staging block. Leaving a noindex in place is the most common launch-day mistake we see.

Google's own site move guidance recommends permanent server-side redirects, kept for as long as possible and generally at least a year, and says a medium-sized site can take a few weeks or more to settle. Some fluctuation is normal. A sustained drop is a fault to find, usually missing redirects or lost content. Our SEO team runs this part alongside the build, not at the end.

Integrations

The store is the visible part. The orders, stock and money flowing behind it are what break. Rebuild each connection on the list from step two, then test with real scenarios: a multi-item order, a part refund, an out-of-stock item, a pre-order, a trade order, an international address. If you run an order management system such as Linnworks, check how it will treat the old and new stores during the changeover so stock is not counted twice. There is more detail in our guide to e-commerce integrations.

Testing

• Place real orders with every payment method, including refunds.
• Test on actual phones, not just a resized browser.
• Check tax, delivery rates and discount codes against the old site.
• Confirm analytics, ad pixels and product feeds fire correctly, or your first month's data is useless.
• Have the people who use the admin every day (customer service, warehouse, merchandising) run their real tasks.

Launch timing

Pick the quietest stretch of your year. For most UK retailers that rules out September to December. Launch on a Monday or Tuesday morning so a full team has the week to respond. Freeze content and catalogue changes on the old site a few days before, run the final data migration, switch the domain, then work through a written checklist: redirects, checkout, order flow to the warehouse, tracking. Keep the old site available privately so you can switch back if something serious appears, and pause paid campaigns for the first hours rather than paying to send traffic at an untested checkout.

The first 30 days after launch

Check the 404 report daily in the first week and add redirects for anything real people or search engines are still requesting.

How we'd approach it

We start with a short discovery: the commercial case, the integration list, the URL audit and the baseline. That tells us whether a move is justified and to where, whether that is Shopify, Shopify Plus or Adobe Commerce. Sometimes the answer is to stay and fix what you have.

If the move goes ahead, the redirect map and the integrations are scoped as their own pieces of work with their own owners, data is rehearsed before the live run, and the launch date is set around your trading calendar. We stay on the numbers for the first month, then move into testing and improvement.

Questions we get asked

Want a second opinion on your own setup? Thirty minutes with a strategist, and you leave with a clear next step.