Ecommerce Replatforming Checklist: Protect SEO and Orders When You Switch Platforms

TL;DR: A replatform fails in the gaps between teams: SEO assumes dev has the redirects, dev assumes marketing has the URL list, and nobody owns order data. Treat the move as five workstreams (URL and redirect mapping, catalogue and content parity, checkout and order data, integrations, and measurement), run a rehearsal on a staging copy, and keep a rollback plan until the new store has taken real orders. Google's own guidance says to expect temporary ranking fluctuation, to use permanent server-side redirects, and to change only one thing at a time. This checklist turns that into a plan you can hand to a project manager.

If you are reading this, you have probably already decided to leave your current storefront. Maybe it is a heavily customised Magento build that takes a specialist to change a banner. Maybe it is a WooCommerce site held together by forty plugins. Maybe your platform vendor has told you a version you depend on is moving out of support. The decision is made; what you want now is a way to do it without a week of silence on the order dashboard.

This guide is written for retailers and ecommerce leads in the UK, Australia and the US who are about to commission or manage a migration. It is a bottom-of-funnel document: we assume you know why you are moving and we focus on how to execute. We have kept it to things that can be checked against vendor and Google documentation, and where a number depends on your situation we say so rather than guess.

1. Decide what you are actually changing

Google's site-move documentation gives a deceptively simple piece of advice: change only one thing at a time (Google Search Central: Site moves with URL changes). In replatform projects that is the first rule broken. The same sprint swaps the platform, redesigns the theme, rewrites product descriptions, changes the URL structure and moves to a new domain. When traffic dips, nobody can say which change caused it.

Before any work starts, write down which of these you are changing, and defer anything that does not have to move in the same release:

• Platform only. Same domain, same URL patterns where the new platform allows it, same design intent.
• Platform and URL structure. Unavoidable on some platforms, because they fix certain paths. This needs a full redirect map.
• Platform and domain. The highest-risk option. It adds a Change of Address step in Search Console and a longer period of fluctuation.
• Platform and redesign. Common, tempting, and best split into two releases if your timeline allows.

If the commercial calendar forces a combined release, accept it knowingly and add monitoring time to the plan. The point is that the trade-off is made on purpose.

Monolith, SaaS or headless: pick the target before you map anything

The target architecture changes the checklist. A hosted SaaS platform removes most hosting and patching work but constrains URL structure and checkout customisation. A headless build separates the storefront from commerce logic, which gives freedom over URLs and page speed but means you own more of the moving parts, including rendering, caching and redirects at the edge. Our plain-English explainer on headless commerce for UK and Australian retailers covers the architecture, and the SaaS versus custom total cost of ownership analysis is a good companion if the target is still open.

A support-lifecycle check, if you are on Adobe Commerce

If your current platform is Adobe Commerce, check where your version sits in the vendor's lifecycle before you set the migration date, because it tells you how much runway you have. Adobe's lifecycle policy offers a three-year standard support window from general availability for each version. According to the policy page (last updated 18 September 2026 when we read it), version 2.4.6 reached the end of standard support on 11 August 2026 and is in extended support to 31 August 2027, while 2.4.7 has standard support to 31 May 2027 and 2.4.8 to 31 May 2028 (Adobe Commerce lifecycle policy). Adobe also states that from 1 June 2027 it will stop maintaining Cloud environments running unsupported Commerce versions. Dates change, so check the live page, but the practical point stands: an end-of-support date is a deadline for your project plan, not a reason to rush a launch into November trading.

2. Pre-migration audit: what you have today

You cannot protect what you have not inventoried. Spend the first one to two weeks of the project building a baseline. Everything in this section is cheap to collect now and impossible to reconstruct after launch.

Search baseline. Export from Google Search Console the queries, pages, clicks and impressions for at least the last twelve months, so seasonality is visible. Note your top landing pages by organic revenue, not just by traffic. A category page that drives a modest number of visits but most of your high-margin sales matters more than a viral blog post.

Crawl baseline. Run a full crawl of the live site and keep the export. You want every indexable URL, its status code, canonical, title, meta description, H1, internal link count and structured data types. This crawl is the left-hand column of your redirect map and the reference you will diff against after launch.

Revenue baseline. Record conversion rate, average order value, checkout step drop-off and payment method mix by device and by market. When the new store goes live, you will compare like with like.

Technical baseline. Capture Core Web Vitals field data, server response times and the robots.txt, sitemap and hreflang setup. If you serve more than one country, document which market uses which URL pattern and currency.

Feature inventory. List every behaviour the old store performs that no one wrote down: back-in-stock emails, saved baskets, tiered trade pricing, bundle logic, gift wrapping, postcode-based delivery rules, and the custom script someone added in 2019 that sets a cookie the finance team relies on. These hidden features are where replatform regret lives.

3. URL mapping and redirects

This is the section that decides whether organic traffic survives. Google's documentation sets out a five-step shape for a move with URL changes: follow general best practice, prepare and test the new site, prepare a URL mapping, configure redirects, then monitor.

Build the redirect map from several sources

Do not rely on a single export. Google suggests drawing old URLs from sitemaps, top-traffic URLs from logs and analytics, the Search Console Links report, your CMS, and server logs covering a period long enough to include seasonality. Add embedded images, PDFs and other assets you host. For ecommerce, also include:

• Product URLs, including variant and parameterised versions that have attracted links.
• Category and subcategory URLs, filtered and sorted views that are indexable, and paginated pages.
• Brand, collection and landing pages.
• Blog and guide content.
• Legacy URLs that already redirect on the old site. These are where chains form.

Map one-to-one wherever the content exists

Each old URL should point to the most relevant equivalent new URL. Google's guidance is to use permanent, server-side redirects (301 or 308) from the old URLs to the new ones, and it states that 301 and other permanent redirects do not cause a loss in PageRank. It also warns against sending many unrelated old URLs to one page such as the home page, which can be treated as a soft 404. If a discontinued product has no equivalent, a redirect to its closest category is reasonable; if the content is deleted with no replacement, the new site should return a 404 or 410.

Avoid chains and loops

Redirect straight to the final destination. If the old store already redirects A to B and your map sends B to C, the result is a chain unless you update A to go directly to C. Test the finished map with a crawler in list mode and fix every chain before launch.

Know your platform's constraints early

Platform URL rules can force changes you did not plan for. Shopify, for example, uses fixed paths such as /products and /collections, and its help documentation states that you cannot redirect URLs that use fixed Shopify paths, and that you can only redirect from broken URLs, those that would show a 404 (Shopify Help Centre: URL redirects). The same page lists a maximum of 100,000 redirects, rising to 20,000,000 on Plus, and describes a CSV import in the admin. If your current catalogue uses a different pattern, your map must account for that early, and a large catalogue with years of accumulated redirects should be checked against the limit before you promise a launch date.

Keep redirects for a long time

Google's guidance, in the part of its documentation we read as a summary, is to keep redirects for at least a year and to consider keeping them indefinitely where it is practical. Treat a redirect as part of the new store's permanent configuration, not as launch scaffolding to be removed in the next tidy-up.

Update everything you control

After the redirects exist, update the things that point at old URLs: internal links, canonical tags (each new URL should have a self-referencing canonical), hreflang annotations if you serve multiple markets, XML sitemaps, email templates, paid-search final URLs, social profiles, and links in your own app or marketplace listings. Redirects are a safety net; clean internal links are the real fix.

4. Catalogue, content and structured data parity

A redirect map that points to thin or missing pages will not rescue anything. Parity checks confirm that what a customer and a search engine find at the new URL is at least as good as what they found at the old one.

Product and category content

Export every product with its title, description, images, attributes, categories, related products and metadata, and reconcile counts after import. A common failure is that the importer silently drops products with unusual characters, very long descriptions or missing mandatory fields on the new platform. Compare counts by category, not just overall.

On-page SEO elements

For priority templates, check titles, meta descriptions, headings, canonical tags, robots directives, image alt text, internal links and breadcrumbs. Pay particular attention to faceted navigation. Decide which filtered views should be indexable and make sure the new platform's defaults do not create a large crawlable space of near-duplicates.

Structured data

Many ecommerce sites earn rich results from product markup. Google's documentation describes two classes: product snippets for pages where people cannot buy directly, and merchant listings for pages where customers can purchase, and it recommends providing a Merchant Center feed alongside page markup (Google Search Central: Product structured data). When you migrate, confirm the new templates output valid Product and Offer markup with price, currency and availability, and test with Google's Rich Results Test before launch. If you use a Merchant Center feed, check that product IDs, landing page URLs and prices in the feed match the new store, because a mismatch between feed and page is a common cause of disapprovals after a move.

Robots, noindex and staging leakage

Google's guide notes that owners often block crawling on a development site and that you should prepare the production robots.txt and the list of URLs where noindex comes off before the move. Put that on the go-live runbook as an explicit step with a named owner. The opposite problem is just as real: a staging site that was accidentally indexed. Protect staging with authentication rather than relying on noindex alone.

5. Checkout, payments, tax and order data

SEO is the failure people talk about. Checkout is the failure that is felt the same afternoon.

Payments

Confirm that every payment method you offer today exists on the new platform, in every market: cards, wallets, bank transfer, buy now pay later, and local methods. Test refunds, partial refunds, voids, and failed-payment retry flows, not just the happy path. Check how saved cards and subscriptions will be handled, because tokens held by a payment provider may not be portable without the provider's involvement, so raise this with the provider early.

Tax, shipping and currency

UK stores must handle VAT correctly, Australian stores GST, and US stores a patchwork of state and local sales tax, so test representative baskets for each market and compare totals line by line against the old store. Check shipping rules, thresholds, delivery estimates, free-delivery messages and cut-off times. If you sell across borders, verify duties and import messaging and how prices display for each currency.

Consumer-law behaviour at checkout

Checkout behaviour is increasingly scrutinised. Our guide on engineering checkout for UK, Australian and US consumer law walks through pricing display, drip pricing, and subscription cancellation. A replatform is the right moment to review them rather than rebuild the old behaviour by default. Have your legal adviser sign off the final flows; this article is not legal advice.

Order, customer and inventory history

Decide what history moves. Typical choices are open orders and the last few years of completed orders, customer accounts, wish lists, reviews and gift card balances. Each has a different technical route and different risk:

• Open orders need a cut-over rule. Either fulfil them from the old system until they are closed, or migrate them with all status information intact. Do not leave a gap where an order exists in neither place.
• Order history matters for customer service, returns and accounting. If full migration is impractical, keep a read-only archive and link your support team to it.
• Reviews carry SEO value and social proof. Confirm that the new platform or review provider can import them with their original dates and attribution.
• Gift cards and store credit are liabilities. Reconcile balances before and after, with finance in the loop.
• Inventory should be frozen or synchronised during cut-over so you do not oversell. For multi-channel sellers, see our piece on inventory and order management automation for multi-channel sellers.

6. Customer data and privacy

A replatform moves personal data to a new processor, often to a new hosting region, so privacy review belongs in the plan from week one rather than as a pre-launch gate.

• Record what you are moving and why. Customer accounts, addresses, order history, marketing consents and browsing data all have different lawful bases and retention rules.
• Carry consent forward faithfully. Marketing opt-ins and opt-outs must move with their timestamp and source. Re-subscribing people who had opted out is both a legal risk and a trust problem.
• Assess risk and document it. If your project changes how personal data is processed, consider whether a data protection impact assessment is appropriate. The UK Information Commissioner's Office publishes guidance on DPIAs (ICO: Data protection impact assessments); your data protection officer or adviser should decide whether one is needed for your project.
• Check contracts. The new platform vendor, hosting provider and any migration partner are likely to be processors. Make sure data processing terms are in place before data moves.
• Handle payment data properly. Card data should stay with your payment provider and not pass through your migration scripts or spreadsheets. If you operate your own checkout, review your PCI DSS obligations with your acquirer or a qualified assessor.

Our overview of data privacy compliance for ecommerce software goes deeper on GDPR, the Indian DPDP Act and PCI DSS for custom builds.

7. Integrations: the systems around the storefront

A storefront rarely stands alone. The integration list is usually longer than anyone remembers, and each item needs an owner and a test.

If the old platform exposes ad-hoc integrations built over many years, a good moment to rationalise them is the replatform. Syslabs designs and builds API development and integration layers so that the storefront can be swapped without rewiring every back-office system, and our retail POS and inventory work covers the in-store side for omnichannel retailers.

Do not forget analytics. If the old store tracked purchases through a particular data layer or tag set, the new one must produce equivalent events from day one, or you will lose your baseline. Our marketing automation and CDP page describes how customer events are unified across systems.

8. Staging, rehearsal and go-live

Build a staging copy that behaves like production

Test on realistic data volume. A catalogue of fifty test products will not reveal what happens at fifty thousand. Where possible, import a full copy of the catalogue and a sanitised sample of customer and order data, and make sure your staging environment is protected from search engines and from sending real customer emails.

Run at least two full rehearsals

A rehearsal covers the whole sequence: freeze, final data export, import, redirect deployment, DNS or routing change, smoke tests, and rollback. Time each step. The first rehearsal always overruns. The second tells you the real cut-over window and exposes steps that depend on one person's memory.

Write the go-live runbook

A usable runbook names an owner for each step, the expected duration, the check that confirms success, and the decision point for rollback. A simplified order looks like this:

1. Announce the change window to support, warehouse and finance.
2. Freeze content and catalogue edits on the old store; pause scheduled imports.
3. Take final backups and run final data syncs for new orders, customers and stock.
4. Deploy redirects and switch DNS or routing. Google's hosting guide recommends lowering the DNS TTL to a conservative value, such as a few hours, at least a week before a DNS-based move (Google Search Central: Changing hosting).
5. Remove crawl blocks and noindex directives from production; deploy the production robots.txt and sitemaps.
6. Run smoke tests: home, category, product, search, basket, checkout with a live low-value payment, refund, account creation, password reset, emails.
7. Check redirects on a sample of high-value old URLs, and the status of the top landing pages.
8. Verify analytics and ad tracking is recording purchases.
9. Hold a go or no-go call at a fixed time. Roll back if the agreed criteria are not met.

Choose the timing carefully

Google advises timing a move for lower traffic where possible. For retailers this means avoiding peak trading: do not cut over in the weeks before your biggest promotions. Allow a quiet period afterwards in which you can fix issues without a campaign running.

Prepare Search Console

Verify every property variant, including HTTP and HTTPS and www and non-www. If you are changing domains or subdomains, Google's guidance is to submit a Change of Address for each verified variant of the old domain; this is not needed for path changes, HTTP to HTTPS, or www to non-www within the same domain. Submit the new sitemap and keep verification working after launch.

9. The first 90 days after launch

Week one: watch daily

Google warns to expect temporary fluctuation in rankings during a move, and says that for medium-sized sites it can take a few weeks or more for new URLs to show, longer for larger sites. Do not panic at a day-three dip, but do act on evidence. Daily checks in week one:

• Search Console indexing and Sitemaps reports, plus crawl stats for errors and server response issues. Google notes it will temporarily crawl the new site more heavily than usual, so confirm your new hosting can cope.
• A crawl of the old URL list to confirm each redirect lands on a 200 page in a single hop.
• Server logs for 404s on URLs that used to get traffic, and for Googlebot errors.
• Revenue, conversion rate and checkout error rates against your baseline.
• Support tickets mentioning checkout, missing orders, login or delivery.

Weeks two to six: fix what the data shows

Work through the 404 and soft 404 reports and add redirects for URLs you missed. Compare rankings and landing page traffic against the baseline for your priority pages. Check structured data and Merchant Center diagnostics. Review page speed on real devices, since a new theme may behave differently from staging.

Weeks seven to thirteen: consolidate

Turn off old infrastructure only when logs show the traffic has gone; Google's hosting guide recommends shutting down the old provider once traffic reaches zero. Keep redirects in place. Archive the old store's data according to your retention policy, and hold a retrospective that records what the checklist missed so the next project starts better.

10. FAQ

How long does an ecommerce replatform take? It depends on catalogue size, integrations, custom features and how much data history moves. The honest answer comes from a scoped discovery: inventory the features, integrations and data, then estimate. Treat any timeline given before that inventory as a guess.

Will we lose rankings when we switch platforms? Some fluctuation is normal. Google's documentation says to expect temporary ranking fluctuation during a move, and that permanent redirects do not cause a loss in PageRank. Losses that last usually come from avoidable causes: missing redirects, pages that are thinner than before, blocked crawling, or broken structured data.

Do we need to keep the redirects forever? Not necessarily forever, but for a long time. Google's guidance is at least a year, and keeping them longer is reasonable where you can. There is little cost in keeping them.

Should we change the design at the same time? If you can avoid it, no. Changing one thing at a time makes problems diagnosable. If a combined launch is unavoidable, add monitoring and keep the content and URL structure as stable as possible.

Do we need a Change of Address in Search Console? Only if the domain or subdomain changes. Google says it is not needed for moves from HTTP to HTTPS, www to non-www, or path changes within the same domain.

Is a headless architecture better for SEO? Not automatically. It gives more control over URLs, speed and templates, and it also gives you more to get right, such as rendering and caching. Choose it for the flexibility you need, not as an SEO shortcut.

Who should own the migration? One accountable project owner, with named leads for SEO, payments, data and operations. Projects fail when everyone assumes someone else has the redirects.

Planning your replatform with Syslabs

Syslabs is a software engineering and consulting company that builds custom software for ecommerce, healthcare, fintech and other industries. For retailers, that includes headless commerce builds, integration layers between the storefront and back-office systems, and cloud migration work. If you want a second pair of eyes on your redirect map, cut-over runbook or integration plan, we are happy to talk it through. Scope and pricing are agreed on a consultation, after we understand your catalogue, markets and systems.

Book a meeting with the Syslabs team. The booking page shows availability in your own time zone.

References

• Google Search Central. Site moves with URL changes. https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
• Google Search Central. Changing hosting without URL changes. https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes
• Google Search Central. Redirects and Google Search. https://developers.google.com/search/docs/crawling-indexing/301-redirects
• Google Search Central. Product structured data. https://developers.google.com/search/docs/appearance/structured-data/product
• Shopify Help Centre. Creating and managing URL redirects. https://help.shopify.com/en/manual/online-store/menus-and-links/url-redirect
• Adobe. Adobe Commerce lifecycle policy. https://experienceleague.adobe.com/en/docs/commerce-operations/release/planning/lifecycle-policy
• Information Commissioner's Office. Data protection impact assessments. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/