I led a migration of roughly 8 million records (products, customers, orders, and the data tied to them) from Volusion to BigCommerce for a high-volume e-commerce store, on a live storefront, with zero data loss verified by reconciliation. No downtime customers felt, no orders lost in transit, no one locked out of their account. This was work I led during my time as senior engineer and solutions architect at a US-based e-commerce agency.
A migration like this is two jobs wearing one name: moving the data safely, and making sure the platform it lands on is actually built to carry it. “Better platform” and “safe migration” are completely different problems. The store keeps taking orders while you work. Customers expect to log in tomorrow. Google has already indexed tens of thousands of your URLs and will notice the instant they change. Get it right and you come out faster, ranking as well or better than before. Get it wrong and you lose customers, orders, and search traffic that takes months to win back.
The outcome, honestly. Zero records lost. Search traffic dipped mildly right after cutover (from the redirect issue and a couple of third-party scripts described below), then climbed back to pre-migration levels over the following months, once SEO monitoring surfaced the problems and we ironed them out. A clean migration isn’t “nothing moves”; it’s “you catch what moves, and you bring it back.”
Here’s how each risk was handled.
1. The stakes: what “losing one record” actually means
One missing record out of eight million sounds like a rounding error. It isn’t.
A single lost customer record is a person who can’t log in or check out: lost revenue, and often a customer who simply leaves. Missing order history or saved addresses drives churn, because in a competitive niche that history is part of why people stay. Broken logins send customers straight to a competitor; they won’t wait for a fix. And downtime that runs longer than you promised, or lands at peak hours, costs trust on top of orders.
The failures are individually small, collectively catastrophic, and most of them don’t surface until the customer is already gone. That’s why the bar is not “we moved the data” but “we moved the data and it still means the same thing.”
2. Pre-migration: discovery and planning
Most of the risk is retired before a single record moves.
Assess the old platform honestly. Catalog every data entity, custom field, integration, and quirk customers depend on. Confirm BigCommerce can carry all of it, and flag anything it can’t so you can plan a workaround before cutover, not during.
Map every field deliberately. This is the unglamorous core of the project. Every source field needs a defined destination, with explicit rules for type conversions and anything without a clean one-to-one home. Most “we lost data” disasters are really “we never mapped that field,” discovered too late.
Decide ownership up front, including who uploads the SEO redirects. That one omission caused the biggest problem we hit (section 8), and it was entirely preventable with a single line in the plan.
3. SEO: protecting rankings through the move
A platform change usually alters three things Google cares about at once: your URLs, your page performance, and your structured data. Handle them deliberately and a migration can improve your search position. Ignore them and you lose rankings that took years to build.
URLs and redirects. Old URLs that 404 after the move are the fastest way to destroy rankings: Google drops dead pages and the authority they carried. Every legacy URL needs a permanent 301 redirect to its new equivalent so both customers and Google are carried cleanly across and ranking signals transfer. At this scale you build the redirect map programmatically from the field mapping you already created, use pattern-based rules where URL structures are predictable, and reserve manual mapping for high-value pages. Then update canonical tags, internal links, and submit fresh XML sitemaps.
Core Web Vitals. A new platform is a new performance profile, and you can’t assume new templates are faster: you have to prove it. Test LCP, CLS, and INP throughout development against real pages and real data volumes, targeting parity with or improvement over the old platform before launch. Performance also degrades as content and scripts accumulate, so this is not a one-time check; we monitored for months after launch.
Structured data and JSON-LD. Product and breadcrumb schema drive how your listings appear in search (prices, ratings, availability), and none of it carries over automatically. Audit what the old platform emitted, rebuild it on the new one, and improve on it where you can.
SEO is not a post-launch cleanup task. It’s a design constraint you carry from day one.
4. Customer continuity: logins, data, and in-flight orders
Everything here serves one promise: a customer should not be able to tell, from the inside, that anything changed.
Logins. This is the hardest single problem. Volusion passwords can be decrypted, but decrypted passwords can’t be relied upon to carry over: BigCommerce enforces its own password policy on import, and a password that was valid on Volusion may not pass it. You can’t build a migration plan around something that silently fails for an unknown subset of accounts. The trick is to make the one unavoidable change (a new password) feel like a non-event, rather than a mass “reset your password” email that half of customers ignore and the rest read as “this site got hacked.” BigCommerce exposes this directly in its API: when you import customers, you flag each account so that the first time a customer signs in, they’re prompted to set a new password in the login flow itself. No re-registration, no separate reset campaign, no lost history. They enter the email they’ve always used, choose a password once, and they’re in. From their side, their identity never changed; they just picked a new password the first time through.
Order history and account data. Every order, address, and detail a customer could see before, they see after: same place, same meaning. This is what the field mapping was protecting.
In-flight orders. An order placed shortly before cutover stays fulfillable and visible afterward, handled by the cutover design in section 7.
5. Architecture: the migration approach
You don’t move eight million records in one pass. The migration was chunked into batches and run across multiple pipelines in parallel: the dataset was too large to push through a single sequential channel in any reasonable window.
What made that parallelism possible was the plan tier. On a standard tier, API rate limits are the hard ceiling that forces a throttled, single-pipeline crawl. This ran on a BigCommerce Enterprise plan without those rate limits, which let us fan the work across parallel pipelines and actually use the available throughput. If you’re scoping a migration this size, treat the plan tier as an architectural decision, not a billing one: it directly determines how fast you can move.
Every chunk ran the same loop: extract from the legacy platform, transform to the BigCommerce data model using the field mapping, load through the API in batches, then verify the batch. Failures went to a sheet and a follow-up script fixed and re-imported them. Because each chunk was independent and the import idempotent, a failure in one batch never threatened the others, and re-running a fix was always safe. That structure is what turns “eight million records” from one terrifying event into a few thousand small, checkable operations.
6. Verifying zero data loss
“Zero data loss” is only worth saying if you can prove it. We proved it with a verification step that read migrated records back out of the BigCommerce API, in batches, and checked them field by field against the source. Verifying in batches rather than per record is what makes this practical at eight million: per-record verification would roughly double the API calls and run into rate limits, while batches give the same confidence at a fraction of the cost and localize any failure to a small, known group.
The important distinction is what you verify. Not the password: customers set a new one on first login, so there’s nothing to verify against (section 4). You verify what actually has to be right: the customer’s email and account fields, every order and its details, every product and its attributes. If those imported correctly and landed in the right fields, the record is whole.
Failed records didn’t just get a count: they got a list. Each failure went to a sheet with enough detail to see why, and a follow-up script worked through it to resolve and re-import each one. That loop (verify, collect failures, fix, re-verify) is the difference between “we ran the import” and “every record is accounted for.” Nothing was assumed migrated; everything was confirmed or on the fix list until it was.
7. The live cutover
The cutover is the few hours everything else was built to make boring.
In the days before, the new platform is kept current with a recurring sync (including new and in-progress orders) so on switch day the gap between old and new is hours, not days. The switch itself is primarily a DNS change; lower the DNS TTL well in advance so propagation is fast, and schedule it for the lowest-traffic window. While DNS propagates, a few orders still land on the old storefront, so the plan accounts for them explicitly: after propagation completes, those final orders are migrated over. Nothing placed during the switch is lost, and a customer shopping through it never knows it happened.
8. What actually broke
The redirects.
The 301 map was correct and deployed cleanly at cutover. After launch, modifications were made to the redirect configuration outside the original deployment process, creating duplicate, conflicting rules that turned clean one-hop redirects into chains, where a single old URL bounced through several hops before landing. Chains bleed the ranking signal a 301 is meant to preserve, slow Google’s crawl, and make the site look unstable to the one crawler you can’t afford to lose.
Cleanup was harder than it sounds, because once the chains exist, removing the conflicting rules doesn’t undo them: the extra hops are already live. You have to remove them carefully, then prove URL by URL that every redirect resolves in a single hop. We did that with a custom script that takes the full list of documented URLs and checks each one, run against a sandbox before the corrected map goes live.
The part that genuinely hurt was the chains already recorded on Google’s side: Google had begun re-crawling in the broken state before the fix fully landed, so the chains existed in its index, not just in the configuration. Fixing the server is only half the job. The other half is getting Google to re-process what it recorded, which you can prompt but can’t force. So the fix ran on two fronts: clean and verify the redirects, then push the corrected state to Google’s index by resubmitting clean sitemaps, using Search Console’s URL inspection to flag the fixes for recrawl, and monitoring until the chains dropped out.
This, plus a couple of non-essential third-party scripts dragging on performance, is what caused the mild post-migration traffic dip. Both were found through monitoring and corrected, and traffic recovered to pre-migration levels over the following months. The root cause of the redirect episode wasn’t technical: it was a change made to production configuration outside the original review and deployment process. Tighter access control on post-launch redirect changes, and a documented review step before any modification, would have prevented it.
9. Lessons
Control access to production redirect configuration tightly, and require documented review for any post-launch change. The most consequential issues on a migration this size often come from configuration changes made outside the original deployment process, not from technical complexity in the migration itself.
Verify redirects with a script, on a sandbox, before they go live. Manual review doesn’t scale to thousands of URLs, and a bad redirect is far cheaper to catch in staging than after Google has crawled it. Treat the scripted check (every documented URL resolves in one hop to the right page) as a required gate, not a cleanup tool.
Test Core Web Vitals across many conditions, not one. A single test on a fast connection tells you nothing about real users. CWV regressions compound until a page crosses Google’s threshold and rankings slip. Run simulated tests across bandwidths and device profiles, and audit every third-party script for blocking behavior: non-essential tools must load async or deferred, or not ship. The third-party scripts that hurt us are exactly why.
Re-educate the client and team on the new platform. The client knows the old platform cold and the new one not at all. Run a hands-on session and be explicit about what not to touch, since something as innocent as changing the URL-structure setting can destabilize the whole storefront and make reconciliation enormously harder. The disasters that happen after launch are often self-inflicted and preventable with one good session.
Build remote logging in from day one, and stand up a dedicated support channel for the cutover. Bugs will surface once real customers are on the new platform. Centralized logging lets the team see problems before customers do; a priority support channel handles the ones that still get through. In the first weeks, speed of response is its own form of damage control.
Planning a migration, or building the thing it runs on?
A migration like this is really two jobs: moving the data without losing any of it, and making sure the platform it lands on is built to hold up: fast pages, clean redirects, solid logging, an architecture that won’t buckle under real traffic. Both jobs require the same discipline — careful planning, deliberate sequencing, and verification at every step. That’s the approach I bring to engagements through Ojixa today, whether you’re replatforming a high-volume store or building the storefront, integration, or tooling from the ground up.
Book an intro call → and let’s talk through what you’re moving, or what you’re building, before it becomes a fire drill.