You’re moving a live store while customers are in the middle of checking out. That sounds like a bad dream or bad planning, reminding us once again why an e-commerce migration checklist isn’t just a formality. It’s your safety net to keep orders, product catalogs, and traffic from disappearing mid-transition.
Our migration guide covers six phases, each addressing a single question: what usually breaks at this stage, and how can you avoid it? Minor disruptions after launch still happen; they are part of the process, not a failure. We’ll help you to predict and prevent more serious issues.
Phase 1. Audit what you have
Before transferring a single item, you need a complete snapshot of your store’s current state. It should be a specific list you can open in a spreadsheet and review line by line.
Here’s what to include in your audit:
- Full URL inventory. Go beyond the sitemap: export it from Crawl and Search Console. Not everything that actually gets indexed ends up in the sitemap.
- Top 100 pages by traffic and by revenue. These are two different lists, and comparing them shows which pages can’t be lost under any circumstances.
- Product catalog structure. List all product options, attributes, custom fields, and bundles.
- Customer data. Export accounts, addresses, password hashes, order history, and other relevant details you request and store.
- Every integration. Have a list of all connections, such as ERP, PIM, payment gateway, tax, shipping, email, reviews, analytics, along with notes on who owns it.
- Additional tools. Don’t forget to list all the third-party apps and scripts connected to the store at the moment.
- SEO and structured data. It is important to save and transfer all the custom title tags, meta descriptions, and schema markup.
- Content debt. This is something you’re about to carry across for no reason. Knowing what exactly belongs here will help you avoid extra work.
Let’s focus on the last item. You need to decide what to leave behind: dead SKUs, spam accounts, outdated content, etc. An audit is a perfect moment to clean up the clutter that has accumulated over the years.
Another key part of an audit is involving the people who use the systems daily: the marketer who knows every active script, the warehouse manager who sees the real catalog structure, and the accounting team that holds all the tax details.
Phase 2. Map the data before you move it
Once the inventory is ready, the next step is deciding how each field from the old system maps to the new one. This is the most tedious part of the process, which is why it’s most often rushed. That’s a mistake: most post-launch issues don’t stem from code, but from fields that seemed “obviously clear where they’d go.”
Fields that never map cleanly
Product variants and options are handled differently across Shopify, BigCommerce, or other platforms: what’s an attribute on one system could be an entirely separate product on another.
Customer groups and tiered pricing rarely transfer automatically. Order statuses have different taxonomies across platforms, tax classes have their own logic, and password hashes might use incompatible algorithms. This means that some customers will need to be asked to reset their passwords after the migration.
A few examples of how that mapping plays out in practice:
| Old system | New system | Note |
| Product variant (e.g. “T-shirt, size M, red”) | Variant option value | Requires recalculating SKU relationships |
| Customer group (Tier 2 pricing) | Price list B | Tiers don’t match 1:1, reconcile manually |
| Order status “Partial” | No direct equivalent | Split into two statuses in the new system |
What you don’t migrate
Before e-commerce data migration, decide early and in writing what gets left behind. These can include, among other things, orders older than a certain date, inactive SKUs, abandoned carts, and spam accounts. Otherwise, your team will need to make split-second decisions right in the middle of the migration, and that’s when critical details slip through the cracks.
Phase 3. Build and test on staging
A staging environment should contain data close to production volume, not a handful of sample products meant for a demo. With a smaller dataset, most real-world issues don’t show up. Search indexing acts differently, filters behave differently, and integration workloads are entirely unrepresentative.
Here are several things worth checking at staging:
- Core features and product pages.
- Payment gateway in test mode.
- Real checkout runs including failure paths.
- Search and filtering against the full catalog.
- Transactional emails and webhooks.
- Authentication and access.
Run at least two full data migration cycles onto staging and walk through real operational workflows. This shouldn’t be a test run, but a repeatable process that will show whether the result is stable or if the first attempt was just pure luck.
A second run often reveals what the first one hid. Data that looked clean during the initial migration can still show duplicates, broken links between products and variants, or inventory levels that shifted because of time zone differences between systems. If your staging deployment works perfectly the first time around, don’t celebrate; start investigating.
Phase 4. Prepare the SEO part
SEO is the easiest layer to break silently. The technical side of the store will keep functioning, with orders placed and processed. Yet, with mistakes or something overlooked here, you risk to witness a traffic drop. And fixing it is not a quick task. Hence, pay attention to the following.
URL structure
The first decision you’ll have to make is whether you are going to change the URL structure at all. If there is a way to keep it, keep it: every URL change costs a portion of the accumulated redirect equity, even when the redirect is set up perfectly.
301 redirect map
The redirect map is built from the Phase 1 inventory, with one row per old URL. Map every old URL to its closest relevant match, rather than redirecting in bulk to the homepage: both search engines and users react poorly to redirects that go nowhere. Always verify the map on staging prior to launch.
Canonicals, sitemaps, robots
The classic disaster is a staging noindex tag that accidentally slips into production, blocking the entire store from search engines. Don’t just hope it’s fine. Verify it explicitly. You need to resubmit the sitemap on day one and keep an eye on indexing reports.
What you should expect to lose
Post-migration traffic dips are normal. Persistent drops mean something broke. Recovery takes a few weeks. If traffic hasn’t bounced back after a month, look for a technical cause rather than waiting any longer.
Phase 5. Launch the new store
Launch day is not just a push of one button. It is a number of steps where the order matters as much as each separate step.
- Lower DNS TTL (24–72 hours prior). Drop the TTL to 300 seconds so global DNS caches clear before launch day.
- Content freeze. Block catalog updates, blog edits, and setting changes on the old store.
- Final delta migration. Run a final sync for customer accounts, orders, and inventory created since the last test run.
- SSL and security validation. Verify that SSL certificates are correctly installed on the new platform and check for mixed content errors to prevent browser security warnings.
- Point DNS and live redirects. Update domain records to the new platform and switch 301 redirects to active.
- Flip payment gateways. Transition gateways from test mode to live; run one real $1 purchase and refund it immediately.
- Analytics and tag verification. Confirm Google Analytics/GTM tags, pixel fires, and conversion tracking register real-time events.
- Enable error monitoring. Turn on log monitoring, 404 tracking, and ERP sync alerts.
And don’t forget a rollback plan. It should always be a part of the risk mitigation strategy, no matter how well everything has been planned and prepared up to this point. Define your rollback triggers and time window before going live.
Phase 6. Stay alert the first 30 days
The first month after launch requires close monitoring of metrics based on how quickly a potential malfunction could impact the business. Focus on checkout completion rates, 404 logs, order-to-ERP sync, transactional email deliverability, and only then start being more demanding of organic traffic and search rankings.
Search rankings take time to update, so don’t panic on day three—but don’t relax by day ten either. If the dip hasn’t started leveling off by the end of the first couple of weeks, it’s a signal to look deeper into the new platform and its settings.
A good habit for the first 30 days is reviewing key metrics daily. An ERP synchronization issue caught on day three normally takes a few hours to fix. That exact same issue found two weeks later means mountains of mismatched orders, a warehouse that can’t see real inventory, and customers who received confirmation for items that don’t actually exist.
Where migrations tend to go wrong
There are a few recurring scenarios to watch as you prepare to move to the new platform. This isn’t exactly a checklist but rather stories that may be useful during planning, especially for the risk management part.
#1 An integration nobody owned. Something breaks post-launch, and it turns out no one knew who was responsible because an owner wasn’t assigned during the audit.
#2 A redirect map built from a sitemap instead of a crawl. This approach misses pages that were never in the sitemap but still ranked, causing 404 errors after launch.
#3 A “mostly complete” catalog migration. SKUs quietly vanish or get corrupted, only discovered when customers complain they can’t find their past purchases.
#4 Launching in the fourth quarter. The transition falls on peak season instead of a quiet period, so any glitch hits your maximum revenue instead of a regular day.
Conclusion
Migrating a live store is intimidating, but it’s a common practice. The difference between a team that navigates this calmly and one that puts out fires for weeks after launch isn’t luck. It’s how thoroughly the audit was conducted, how well the data mapping was planned, and how closely the staging test run matched real-world load.
If e-commerce replatforming is a certainty for you, navigate it with experienced partners who know where pitfalls lie. Our team handles migrations from audit to post-launch monitoring. Reach out to discuss your starting point whenever you are ready.