BSc (Hons) Software Engineering, Liverpool John Moores University. Has shipped Shopify migrations, custom POS systems, and AI automation builds for ecommerce and regulated-retail clients.
In this article
Most comparisons stop at build cost and timeline. The question that actually determines whether a migration goes smoothly is what breaks during cutover — and how long the storefront is genuinely unable to take orders while it happens.
This is the question we get asked most often by brands that have been through a migration before. They read the comparison guides. They got the timeline estimates. They went through the build. And then something broke at launch that the guide didn't mention, and they spent three days unable to take orders while they fixed it.
The specific things that break in a migration are predictable. They break in the same order, in the same way, on most migrations. Knowing what they are in advance doesn't make the migration risk-free, but it makes the risk manageable — because you can plan for it, test for it, and have a fix ready before go-live rather than diagnosing it under pressure while orders aren't coming through.
Customer accounts, order history, and SEO equity are the three things a rushed Shopify migration loses first. We've handled migrations from Magento, custom PHP carts, and BigCommerce, and the work that actually prevents this is unglamorous: mapping every historical order and URL before touching DNS, not after.
Customer accounts break because passwords cannot be migrated between platforms. This is a security constraint, not a technical limitation — storing unhashed passwords is a security violation, and you don't have access to the unhashed versions even if you wanted to migrate them. Every existing customer who tries to log in on the new platform after migration will fail until they reset their password. This is not avoidable. What is avoidable is the failure to communicate it: a proactive email to all existing account holders before migration, explaining that they'll need to reset their password and why, reduces support ticket volume by 60–80% compared to letting customers discover the issue at login.
SEO equity breaks when URLs change without 301 redirects. A product URL that was indexed at `/products/leather-wallet-brown-slim` on your old platform and now lives at `/products/leather-wallet-brown-slim-12345` on Shopify (because Shopify appended a variant ID) is a broken link from Google's perspective. The page still exists, but the authority accumulated at the old URL doesn't transfer until the redirect is in place. On a catalog with 500+ products and 3 years of indexed URLs, this mapping work is 2–3 days of careful spreadsheet work that most migration timelines don't allocate.
Order history breaks when the historical import is incomplete or incorrectly mapped. Customers who call support asking about orders placed before the migration should be able to see those orders in their account. If the historical order data wasn't imported — or was imported with incorrect date formatting, currency conversion, or line item mapping — support staff can't answer these questions and customers lose trust in the new platform.
The honest answer depends on whether you're moving between two live platforms or launching fresh, and how DNS propagation behaves for your specific registrar. We plan a staged cutover window rather than a single flip specifically to avoid an extended dead period at checkout.
In a best-case scenario — DNS propagation completes in under 30 minutes, all integrations test correctly on the staging environment, no surprises in the first hour of live orders — checkout downtime is 30–60 minutes during the DNS cutover window. This is achievable if the preparation is thorough.
In a realistic scenario — a major payment gateway integration has a configuration difference between staging and production, or the email provider needs a domain verification step that wasn't anticipated — checkout may be unavailable for 2–4 hours. This is the most common outcome for teams that have done solid preparation but didn't have a full production-environment test.
In a worst-case scenario — a critical integration fails at cutover and the rollback to the old platform fails because the old environment was decommissioned too early — downtime can extend to 12–24 hours. We've seen this happen once. The solution is to never decommission the old platform until the new one has been live for 72 hours and all integrations are confirmed working under real traffic.
The practical playbook: lower DNS TTL to 5 minutes 48 hours before cutover. Schedule the cutover for your lowest-traffic window (typically 2–4am local time for most brands). Keep the old platform running for 72 hours post-cutover. Have a rollback plan documented and the team briefed before the cutover begins.
Cross-device testing and a staged rollout against a full launch checklist — covering analytics and tracking, not just the storefront itself — is what turns a migration from a risky one-shot event into a supervised go-live with a rollback plan.
Staging environment testing is necessary but not sufficient. A staging environment uses test payment credentials, test order data, and usually a different domain. The production environment uses real payment processors, real customer accounts, and the live domain. Things that pass on staging can fail on production for reasons that are invisible in the testing environment — production payment gateway rate limits, real customer email domain quirks, live CDN caching behaviour.
The most valuable staging test is a full end-to-end order: find a product, add to cart, check out with a real payment method (most payment gateways have a test mode that uses real processing infrastructure), receive the order confirmation email, verify the order appears in the admin, trigger the fulfillment workflow. If any step in this sequence fails on staging, it will fail on production. Running this test for each supported payment method and each shipping zone is the minimum bar for a safe launch.
Analytics and tracking are the most commonly forgotten items in QA. A migration that loses Google Analytics tracking for three weeks is a migration that blinds you to the performance delta between the old and new platform during the period when you most need that data. Verify every tracking pixel, every conversion event, and every third-party integration before go-live.
Most Shopify Plus rebuilds and migrations land between 6 and 12 weeks, depending on catalog complexity, custom checkout requirements, and how many third-party integrations need to be rebuilt rather than just reconnected.
The variance in this range is almost entirely driven by integration complexity, not storefront complexity. A visually complex storefront with custom sections and a rich product display page is well-understood engineering — it takes time, but the time is predictable. Integrations are less predictable because they depend on third-party API documentation quality, sandbox environment availability, and vendor responsiveness.
A migration from BigCommerce to Shopify Plus with fewer than 10 integrations and a catalog under 500 SKUs can be completed in 6–8 weeks. A migration from Magento with 30+ integrations, a complex B2B pricing structure, and a catalog over 5,000 SKUs typically takes 14–18 weeks. Between these poles, the timeline is driven by the integration audit — how many of the existing integrations have native Shopify equivalents, and how many need to be rebuilt from scratch.
Not if the redirect mapping is done correctly before DNS cutover. Every URL that changes needs a 301 redirect to its new equivalent. Product, collection, and blog URLs are the most critical — these are typically the pages with the most accumulated link equity. Done correctly, most SEO equity transfers within 4–6 weeks as Google re-crawls and processes the redirects.
Orders (all historical orders with line items, customer details, and shipping information), customers (accounts, addresses, order history), products (with all variants, metafields, and media), blog posts (with their URLs for redirect mapping), and a full URL crawl of the current site for redirect planning. Back up everything before touching DNS.
Schedule the DNS cutover during your lowest-traffic window, lower DNS TTL to 5 minutes 48 hours in advance, keep the old platform live for 72 hours after cutover, test the full checkout flow on the new platform before going live, and have a documented rollback plan. The rollback plan is the most important item — knowing exactly what steps to take if something goes wrong is what limits a problem to hours rather than days.
Work with us
We build Shopify stores, custom software, and AI tools for ecommerce brands — remote, worldwide.
Related reading
Headless Shopify costs 2–3× more to build than Shopify Plus and takes twice as long. Here's the pricing breakdown and how we decide which one a project actually needs.
Read moreA plain-English breakdown of when each platform wins — and the specific signals in your roadmap that should push you toward one over the others.
Read more