Moving a store without losing orders, customers or rankings
eCommerce migration moves a store to a new platform: products with their variants, customers with their accounts, order history, and every catalogue URL redirected. It carries more risk than a normal site migration because the data is transactional and the URL count runs into thousands.
Store migrations fail in ways ordinary site migrations do not, because a store carries obligations. Order history is a record customers and accountants rely on. Customer accounts hold credentials and addresses. And a catalogue of two thousand products is four thousand URLs when you count collections, every one of which someone may have linked to or bookmarked.
Product data is where migrations overrun. Variants modelled one way in the old platform and differently in the new. Attributes stored inconsistently because three people added products over five years. Images referenced by absolute URL to a domain that is about to stop serving them. Then the transactional layer: customers cannot log in because password hashes are not portable, order history arrives incomplete, and nobody notices until a customer asks for an invoice from eighteen months ago.
When this work makes sense
Questions worth asking any supplier
How is product data actually structured? It is usually messier than the export suggests.
Is order history moving, or being archived? Both are valid and they are different projects.
What happens to customer passwords? Hashes rarely transfer, so a reset flow is needed.
How many URLs exist including collections, filters and pagination? The count is always higher than expected.
Are there active subscriptions? Those are the hardest thing to migrate and need their own plan.
Deliverables
Product data audit establishing the real structure and its inconsistencies
Catalogue migration with variants remodelled to the new platform correctly
Customer migration with a password reset path communicated in advance
Order history migrated or archived accessibly, agreed explicitly either way
Complete URL map covering products, collections and content, with one-hop redirects
Image and media migration with references rewritten
Payment and shipping reconfigured and tested with real transactions
Reconciliation confirming counts match on both sides before cutover
Built with
Process
Migration is rehearsed in full on a staging store before the live cutover, and the reconciliation happens there. Product counts, variant counts, customer counts, order totals compared on both sides. The discrepancies found in rehearsal are the ones that would otherwise be found by a customer. Doing it twice costs a little more and turns the live cutover into a repetition of something that already worked.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Full migration, catalogue only, or a fresh start
Full migration
Fits: Established stores where history and customer accounts matter
Limits: Largest scope; order and customer data drive most of the cost
Catalogue only
Fits: Stores willing to archive history and ask customers to re-register
Limits: Customers lose accounts and history, which costs some of them
Fresh start
Fits: Very small or very old stores where the data is not worth moving
Limits: Loses everything, including the search visibility the old URLs carried
Case studies
No published migration case study. Store migration outcomes require before-and-after data from a named client.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
Will we lose our search rankings?
Not if every product and collection URL is mapped and redirected. That is the single determining factor, and store migrations are riskier than site migrations purely because there are so many more URLs to get right.
Can customer passwords be migrated?
Almost never. Hashes are not portable between platforms, by design. The standard approach is migrating accounts without passwords and asking customers to reset, communicated before the move rather than discovered at their next login.
What about our order history?
It can be migrated or archived somewhere accessible. Decide explicitly, because customers request old invoices and finance teams need records. Discovering the history did not come across, months later, is a bad way to find out.
How long does a store migration take?
It scales with catalogue size and, more importantly, with data condition. A clean thousand-product catalogue moves quickly. A messy one where attributes were used inconsistently takes far longer, and the cleaning is usually the bulk of the work.
Can we migrate without downtime?
Largely. The store runs in parallel on staging until cutover, with a short window while DNS propagates and final orders reconcile. Reducing DNS TTL in advance shortens that window considerably.
What happens to our reviews?
Depends where they live. Reviews in the platform can usually be exported and imported. Reviews in a third-party app depend on that app existing on the new platform. Worth checking early, because product reviews are difficult to replace.
What about active subscriptions?
The hardest part of any store migration. Payment tokens are typically not portable between providers, so subscribers may need to re-authorise. That needs planning and clear communication, and it is where migrations most often lose revenue.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.