E-commerce replatforming checklist: data migration and go-live readiness

E-commerce replatforming carries substantial risk to search rankings, revenue and customer data. Domain migrations took an average of 523 days to recover organic traffic in Search Engine Journal's study of 892 migrations. A structured approach to data audit, URL preservation, testing and contingency planning reduces these risks and protects the traffic retailers have spent years building.

With only 14 per cent of businesses satisfied with their current platform and 77 per cent feeling urgency to migrate within the next year, fashion and retail brands are facing replatforming decisions driven by legacy platform limitations, vendor deprecation schedules and rising maintenance costs. Adobe Commerce 2.4.5 extended support ended August 11, 2026, and Adobe Commerce 2.4.6 standard support ended August 11, 2026, with extended support running to August 31, 2027. These deadlines have accelerated migration planning across the sector.

What data needs to move during replatforming?

Data migration extends beyond simple file transfers. Data migration includes products, customers, orders, reviews, UGC and loyalty. At least product catalogue (images, variants, metadata), customer accounts, order history, discount codes, CMS content and URL structure must transfer intact to maintain operational continuity.

Conduct a comprehensive data scrub before exporting your catalogue; do not migrate redundant inventory, broken images or outdated customer profiles. Fashion brands face particular complexity with variant data structures. Product records connect to materials, sample histories, size charts and supplier details that must remain linked through migration.

Validate data in passes: run dry migrations, reconcile record counts and spot-check orders, prices and customer data. Each validation pass should compare source and target record counts, verify pricing integrity and confirm that relational data maintains correct associations.

How do you protect SEO during platform changes?

Search engines rank URLs, not products. When a product page changes address, search engines must rediscover the page and understand that it replaces the old one. Create a comprehensive one-to-one redirect map covering every indexed URL, prioritise high-traffic and revenue-driving pages and use 301 (permanent) redirects, not 302s.

Build the redirect map from three sources. Crawl the live site and export every URL Google has indexed or that receives traffic or backlinks. Build the list from a full crawl of the current store, the indexed and top pages in Search Console's performance report and the pages with external backlinks. This approach captures old campaign URLs that a crawl alone would miss.

Map like for like: product to product, category to category, blog post to blog post. If a product is gone for good, point it to the closest category, not the homepage. Mueller has advised staying under five hops, and Google's own documentation confirms Googlebot can technically follow up to ten but recommends staying under five as best practice; the practical target for a migration is one: old to new, not old to intermediate to new.

Google's site migration guidance recommends retaining redirects for at least a year, and longer where possible. Google recommends at least one year so it can transfer signals to the new URLs, and old links on other websites keep sending visitors long after that; on a store, there is rarely a good reason to remove redirects that still receive traffic.

What testing must happen before go-live?

Testing in production-like environments identifies defects before customers encounter them. Recheck the customer journeys that cannot fail: browse-to-cart (search or navigation, product detail, variants, availability, price display, add to cart, cart persistence and quantity changes) and checkout and payment (address validation, delivery selection, tax, payment authorisation, 3D Secure where applicable, order confirmation and customer notification).

Validate catalogue visibility, variants, bundles, subscriptions where relevant, restricted products and regional assortment rules; check inventory availability, reservation, low-stock messaging, oversell prevention, backorder handling, cancellation and stock release after failed or cancelled payment; compare displayed and charged prices, discounts, tax, shipping charges, currency conversion and refund values against agreed commercial rules.

Test redirects in a staging environment and verify canonical tags, hreflang attributes (for international sites) and structured data implementations. Run a crawl on staging and compare to production, fix 404s and redirect chains before launch and after eCommerce platform migration, submit sitemaps, spot check money pages and monitor index coverage daily for two weeks.

Run the critical paths at flash-sale or campaign-like volume, including concurrent add-to-cart, checkout, payment and inventory reservation activity. Load testing under realistic peak conditions reveals bottlenecks before they affect conversion.

Why do rollback plans require testing?

A rollback plan that has not been tested is a document, not a safety net; run through the procedures before go-live to identify gaps. Replatforming creates substantial technical and commercial risk. Cutover and rollback must be executable, not theoretical; if decision rights, escalation paths and rollback steps are unclear, teams lose hours improvising under pressure; clear ownership and rehearsed plans make the launch predictable.

Create a rollback plan with specific triggers and step-by-step procedures. Document the conditions that would trigger rollback, the technical steps required to revert, what happens to orders placed during the cutover window and how long reversion takes at production volume. An untested rollback is a plan and not a control.

Downtime during a peak event can cost 100,000 dollars an hour, which is why automated deployments with tested rollback matter more than manual fixes in production. Do not rely on manual fixes in production; automated deployments and tested rollback procedures save hours of firefighting and protect revenue during critical sales windows.

What defines go-live readiness?

An ERP go-live checklist is a phased evidence pack from T-30 readiness through cutover, go/no-go and Day 1-30 hypercare; each phase needs a named owner and proof (reconciliation report, signed defect log, approved rollback plan) so Dynamics 365 and Odoo cutovers are decided on evidence, not optimism. The same principle applies to e-commerce replatforming.

Readiness goes beyond UAT; a system can work in testing and still fail at launch if users are unprepared, support teams lack context or business processes are not aligned; validating technical, organisational and business readiness together prevents last-minute surprises.

A structured readiness checklist covers multiple dimensions:

• Data migration validation complete with reconciliation reports showing matched record counts within agreed tolerances
• UAT and critical-path scenarios signed off by business process owners with defect backlog below launch threshold
• Integration testing under production-like load with severity-one and severity-two defects closed or formally waived
• At least one timed mock cutover completed with actual timings logged and runbook updated
• Rollback triggers and authority documented and approved by project sponsor
• Access provisioned for new platform with legacy system deprovision plan ready
• Command centre active on launch day with escalation roster and hourly status cadence

Go/no-go decisions are based on criteria, not opinions; if a critical step fails or thresholds are breached, the rollback plan is triggered without debate. Define objective pass/fail criteria for each readiness dimension before launch day.

How long does post-launch monitoring last?

After go-live, monitor Search Console daily for the first two weeks to catch crawl errors, indexing issues or Core Web Vitals regressions before they affect rankings. Monitor traffic, conversions and rankings for two to four weeks. This monitoring window identifies issues whilst they remain fixable.

Google says to keep those redirects for at least a year and says a small to medium store can take a few weeks for most pages to move, with temporary ranking fluctuation along the way. Search performance may fluctuate during a move. Expect temporary volatility rather than immediate stabilisation.

Track specific metrics against pre-migration baselines: organic traffic by landing page, conversion rate by traffic source, average order value, checkout abandonment rate, page load speed and crawl error volume. Document any deviations and prioritise fixes by revenue impact.

Freeze code and content: lock changes during the migration window so source and target stay in sync. Maintain this freeze through the initial monitoring period. Introduce new features only after baseline performance stabilises and migration issues resolve.