Ecommerce Replatforming Without Losing Rankings

Most ranking losses blamed on a new platform are actually process failures: URLs that changed without redirects, content rewritten on the same day the domain moved, or a launch nobody crawled until traffic dropped. Replatforming can be done without lasting damage, but the discipline it requires is closer to a data migration than to a website redesign.

Start with an inventory, not a build. Crawl the current site and export the full URL list. Pull Search Console performance data for twelve months, export backlinks, and separate the pages that produce revenue from the pages that produce organic entrances. That combined list defines which URLs must exist after launch, which is a different set from the pages anyone feels like keeping.

Build the URL map before design approval. Every URL that changes needs a destination, ideally one-to-one. Category restructures, product consolidations, and discontinued items each require a decision: redirect to the closest equivalent, redirect to a parent category, or return a proper 404 instead of a soft redirect to an unrelated page. Faceted and parameter URLs need a rule too, or the new site will multiply duplicates the old one spent years accumulating.

Implement redirects as real 301s and test them in staging with the same paths users and crawlers will request. Avoid chains, because redirecting through three hops dilutes signals and slows people down. Export the map to a versioned file you control rather than hand-typing rules into a plugin, so that in six months someone can prove exactly what changed and when.

Preserve the signals that already rank. Keep titles, headings, and meta descriptions where they perform, port structured data types, keep internal links pointing at mapped destinations, and postpone content rewrites until the migration has stabilized. A replatform is the wrong week to also change brand voice, redesign the navigation, and rewrite two hundred product descriptions.

Data migration is where hidden scope lives. Products and variants map onto a new attribute model, customers need password resets rather than password copies, order history may be import-only, reviews usually need a dedicated service to travel, and media must be rehosted with references updated. Run the migration at least twice before the real cutover: the first pass surfaces mapping problems, and the second proves the process is repeatable, including the delta import of orders and customers created since the first pass. Fix the mapping file between passes rather than patching records by hand in the new admin, because manual fixes never get reapplied on the real run. For every data type, decide whether it must move, whether it can be recreated later, and how completeness will be verified. Spot-checking a handful of records is not verification; run count comparisons, review a sample per category, and keep a log with timestamps, record counts, and the name of whoever checked each pass. The rehearsal is the point: the live cutover should be the boring execution of a process already completed twice and timed end to end.

Technical QA should compare what crawlers see against what shoppers see. Verify that important content renders without JavaScript, that robots directives and sitemaps point at production URLs, that pagination is crawlable, and that consent tools do not hide the page from bots. Test search, filters, currency switching, and the complete checkout path on a staging store that mirrors production settings as closely as possible.

Plan the cutover in phases. Freeze content, take a final data export, run the migration on staging, verify, then switch DNS during a low-traffic window. Lower the DNS TTL beforehand so a rollback is fast, and keep the old environment available until the new one has survived at least one full business cycle, ideally including a promotional event.

Handle customer-facing continuity deliberately. Order history, saved addresses, subscriptions, gift cards, loyalty points, and password resets all need a decision and a communication plan. A store that looks identical but forgets a customer's order history generates support tickets and distrust, and those surface in reviews long before they surface in analytics.

After launch, watch the reports crawlers produce. Check Search Console coverage and 404 reports daily for the first two weeks, monitor redirect chains, confirm the new sitemap is being discovered, and compare organic entrances page by page against the old baseline. Checkout, payment, and tax flows deserve their own live test orders on the production domain, placed as a real customer would.

Expect volatility and resist the urge to panic-fix it. Rankings can move while search engines reprocess the site, and day-two heroics usually introduce new problems. Set a review point at two weeks and another at six, then decide whether a dip is a migration issue or normal settling.

Finally, write the rollback criteria down before launch: which metrics, over how many days, trigger a revert. Deciding the threshold in advance turns a stressful weekend into a documented decision that anyone on the team can execute.