How to Migrate an Ecommerce Store Without Losing Traffic or Sales

Replatforming is where good ecommerce businesses go to lose six months of organic traffic through preventable mistakes. The technology switch itself, moving from WooCommerce to Shopify, from Magento to Shopify Plus, from one headless stack to another, is rarely the hard part. The hard part is preserving everything that took years to build: search rankings, customer accounts, order history and the trust signals search engines and shoppers have accumulated around your existing URLs.

This playbook is platform-agnostic because the discipline is the same regardless of which two platforms are involved. It covers what to inventory before touching anything, what actually transfers between platforms and what does not, how to protect SEO through the switch, how to plan cutover day, and what a normal traffic dip looks like versus one that signals something broke.

Before You Touch Anything: The Pre-Migration Audit

Migrations fail most often because the team started building the new store before fully documenting the old one. Four things need to be inventoried and locked down before any development work begins.

Full URL inventory. Export every indexed URL from Google Search Console, plus a full crawl of the live site using a tool like Screaming Frog, to catch pages that are live but not yet indexed. This becomes your redirect mapping source of truth later, and skipping it is the single biggest cause of lost rankings post-migration.

Ranking and revenue baselines. Record current organic rankings for your top 50 to 100 keywords, current organic traffic and revenue by month for the trailing twelve months, and current conversion rate by traffic source. Without this baseline, you cannot tell a normal post-launch dip from an actual problem three weeks in.

Data audit. Catalog every data type living in the current platform: products and variants, customer accounts, order history, product reviews, active subscriptions, gift card and store credit balances, discount codes, and any custom fields or metafields built up over time. For each, note the volume (how many records) and whether the destination platform has a native equivalent.

Feature parity matrix. List every feature, app and custom function the current store relies on (subscription billing, loyalty points, custom shipping rules, B2B pricing tiers, a specific checkout customization) and confirm how each will be replicated on the new platform, whether through a native feature, an app, or custom development. Gaps found here after cutover are expensive; gaps found here during planning just get budgeted for.

Data Migration: What Transfers and What Commonly Does Not

Not everything moves cleanly between platforms, and knowing the exceptions ahead of time prevents unpleasant surprises on launch day.

Products and variants. Generally the most reliable data to migrate. Most platform migration tools or scripts handle titles, descriptions, images, pricing and variant structure well. Complex variant combinations (products with 5 or more variant options) sometimes need manual review since not every platform supports the same variant depth.

Customers and passwords. Customer records (name, email, address, order history association) transfer reliably. Passwords almost never transfer, because passwords are stored as one-way hashes specific to the originating platform's hashing algorithm. Plan for customers to reset their password on first login post-migration, and communicate this in advance by email rather than letting them discover it at checkout.

Order history. Historical orders generally migrate, though the depth of detail varies. Line items, totals and customer association usually come across. Detailed fulfillment tracking numbers and internal notes sometimes do not, depending on the migration tool.

Reviews. This is one of the more commonly dropped items. Native review data rarely has a direct import path between platforms, especially when reviews live in a third-party app (Judge.me, Yotpo, Loox) rather than the platform itself. Check whether your review app supports both platforms and offers an export/import path; if not, budget for either a CSV-based manual import or accepting the loss of historical review display (the review count and content is usually preserved by the review app itself if you keep the same app across the migration, which is the simplest fix).

Subscriptions. Active subscription billing relationships are the highest-risk data category in the entire migration. Moving a customer's active subscription from one billing system to another (Recharge, Bold, native Shopify subscriptions) without disrupting their billing cycle requires careful coordination with the app vendor and sometimes cannot be done without a brief customer re-authorization step. Start this workstream early and involve the subscription app's migration support team directly.

Gift cards and store credit. Gift card balances usually can migrate with the right export and import process, but the codes themselves sometimes have to be reissued, which requires a customer communication plan. Store credit balances tied to a specific app often do not migrate automatically and need a manual reconciliation process.

SEO Preservation: The Part That Actually Determines Whether You Keep Your Traffic

Redirect mapping. Every URL from your pre-migration inventory needs a mapped destination on the new platform, ideally a one-to-one 301 redirect from old URL to the equivalent new URL, not a blanket redirect to the homepage. Blanket homepage redirects are treated poorly by search engines and tank both rankings and user experience. Build this map in a spreadsheet before development finishes, test every redirect before launch, and keep the map itself as documentation.

Metadata. Title tags, meta descriptions and header structure (H1, H2 hierarchy) should be audited and, where possible, preserved or improved, never regenerated from a generic platform default. A platform migration is not the moment to accidentally reset months of on-page SEO refinement to template defaults.

Structured data. Product schema, review schema and organization schema all affect how listings appear in search results (star ratings, price, availability). Confirm the new platform or theme outputs equivalent structured data before launch, since losing rich results is a subtle but real traffic hit that shows up in click-through rate rather than rankings.

Sitemaps. Submit the new XML sitemap to Google Search Console and Bing Webmaster Tools on launch day, and keep the old sitemap accessible briefly (or ensure old URLs 301 correctly) so crawlers discover the redirect chain rather than hitting dead ends.

Canonical tags and internal linking. Confirm canonical tags point to the correct new URLs, and update internal links across blog content, navigation and footer menus to point directly to new URLs rather than relying entirely on redirects to carry that weight.

Cutover Planning

DNS. Lower the TTL (time to live) on your DNS records to 300 seconds or less at least 48 hours before cutover, so that when you do point the domain to the new platform, the change propagates quickly rather than taking up to 24 to 48 hours under a longer TTL.

Freeze windows. Schedule a defined order freeze window, typically the store's lowest-traffic hours, during which no new orders are accepted on the old platform while final data syncs and DNS propagates. Communicate this window to customers in advance with a simple maintenance notice rather than letting them hit a broken checkout.

Rollback plan. Before cutover, document exactly what triggers a rollback (checkout completely broken, payment processing failing, catastrophic data loss discovered) and exactly how to execute one (revert DNS, reopen the old platform for orders). Assign one person the authority to make the rollback call during the launch window, because indecision during an active incident costs more than the rollback itself.

Staging verification. Before the real cutover, run a full order end to end on the new platform in a staging or test environment: browse, add to cart, checkout, receive confirmation email, and verify the order appears correctly in the admin. Test at least one international or edge-case order (different tax jurisdiction, a discount code, a gift card if applicable) since edge cases are where migrations quietly break.

Post-Launch Monitoring for the First 30 Days

The first month after migration is not a victory lap, it is when problems that were invisible during testing surface under real traffic and real search engine re-crawling.

Week 1. Monitor checkout completion rate hourly for the first 48 hours, watch for 404 errors in Google Search Console's coverage report, and confirm order confirmation and shipping emails are firing correctly. Spot-check redirects daily using the URL inventory from the pre-migration audit.

Weeks 2 to 3. Organic traffic typically shows its first real signal here as search engines re-crawl redirected URLs. Compare weekly organic sessions and top keyword rankings against your baseline. Continue checking for crawl errors and monitor conversion rate by traffic source against pre-migration figures.

Week 4. Rankings for most keywords should be stabilizing, though full recovery of the old rankings profile commonly takes 6 to 10 weeks for a well-executed migration. Review revenue by channel against baseline, confirm subscription billing cycles have processed correctly for at least one full cycle, and close out any lingering redirect gaps found through 404 monitoring.

Realistic Timeline and Budget

A straightforward migration (under 500 products, no subscriptions, standard catalog) between comparable platforms, for example WooCommerce to Shopify, typically runs 6 to 10 weeks end to end and costs $8,000 to $20,000 depending on catalog size and how much custom functionality needs rebuilding rather than reconfiguring.

A complex migration (thousands of SKUs, active subscriptions, B2B pricing, significant custom functionality, or a move to or from a headless architecture) typically runs 12 to 20 weeks and costs $25,000 to $80,000-plus. Our ecommerce development team scopes these individually because the subscription and B2B workstreams in particular vary enormously in effort from one store to the next.

Do not underbudget the SEO and QA phases specifically. A migration that comes in under budget by cutting redirect mapping short or skipping staging verification tends to cost far more in lost revenue over the following months than it saved during the build.

The Normal Traffic Dip Versus the One That Means Something Broke

Some organic traffic softness in the first two to four weeks after migration is normal, even with a well-executed redirect strategy, simply because search engines need time to re-crawl and re-index the new URL structure. A dip of 5 to 15 percent in organic sessions during weeks one to three, recovering by week six to ten, is within the range we see on carefully executed migrations.

A dip beyond that, or one that does not begin recovering by week four to six, usually points to a specific problem: broken or missing redirects (check Search Console coverage report for a spike in 404s or "not found" errors), a robots.txt accidentally blocking crawlers on the new platform, missing or malformed structured data suppressing rich results, or a canonical tag configuration pointing to the wrong URLs. All four of these are diagnosable within a day by pulling the coverage report and spot-checking a sample of redirected URLs, so there is rarely a good reason to let a real problem sit unexamined for weeks. If your migration is already underway and traffic has dropped further or faster than expected, that is worth an urgent look rather than a wait-and-see approach, and it is the kind of diagnostic work our team does regularly for stores that migrated elsewhere and hit trouble.

FAQ

How much organic traffic loss is normal during an ecommerce migration?

A temporary dip of 5 to 15 percent in the first two to four weeks, recovering within 6 to 10 weeks, is within the normal range for a well-executed migration with proper redirect mapping. Losses beyond that, or ones that do not recover, usually indicate a specific fixable problem.

Can passwords be migrated to the new platform automatically?

Almost never. Passwords are stored as platform-specific one-way hashes and cannot be decrypted and re-encrypted for a new system. Customers will need to reset their password on first login, and this should be communicated by email ahead of the migration rather than discovered at checkout.

What is the riskiest data type to migrate?

Active subscriptions carry the highest risk because moving a live billing relationship between systems can disrupt a customer's billing cycle if not coordinated carefully with the subscription app vendor. This workstream should start earliest and get the most dedicated attention.

Should I migrate everything at once or in phases?

For most stores, a single coordinated cutover with a defined freeze window is safer than a phased migration, since running two platforms in parallel for an extended period creates data synchronization problems (inventory, orders) that are harder to manage than a clean, well-tested single cutover.

If you are planning a migration and want a second set of eyes on your redirect strategy, data audit or cutover plan, book a free 1-hour strategy call and we will walk through it together.