A clean Shopify migration rollback has a shelf life of roughly six hours. Before your first real order lands on the new store, reverting is a DNS change and an apology email. After that first order, you are no longer rolling back — you are reconciling two systems, and the cost of doing it badly is usually larger than the sales you were trying to save. So the plan you need isn't "how do we undo this". It's a pre-agreed set of numbers that tell you, at 11pm on a Saturday, whether to point the domain back or stay and fix.
Most teams write the migration checklist and skip this part. Then day one goes sideways, everyone argues from vibes, and the decision gets made by whoever is loudest at 2am.
What a Shopify migration rollback can and cannot restore
Reverting the domain is easy. Lower your DNS TTL to 300 seconds a full 48 hours before cutover, keep the old A record and CNAME values in a text file, and you can be back on the old platform within about ten minutes plus resolver lag. That part we have never had trouble with.
What doesn't come back:
- Orders placed on Shopify. They exist in Shopify forever. If you revert, you either fulfil them from Shopify's admin while the storefront runs on the old platform, or you hand-import them into the old system as CSV so your ERP and accountant see one set of books. Both are messy. The second costs a day or two of somebody's time and always throws GST invoice-numbering questions.
- Customer accounts created after cutover. Shopify's new customer accounts don't export a password hash. Anyone who registered on the new store has to reset on the old one.
- Loyalty and store-credit balances that moved. If a customer burned 400 points on Shopify and you revert, those points are still sitting in the old platform's ledger. Gift cards and loyalty are the two things we most often get wrong on the first pass, and they're the two things customers notice fastest.
- Search engine memory. One flip forward and one flip back inside 48 hours does very little lasting damage. Four flips over two weeks, with the redirect map changing each time, will genuinely cost you organic traffic for a month.
So treat rollback as an emergency valve with a real price tag, not a safety net you can pull whenever the dashboard looks ugly.
The three windows, and what's available in each
0 to 6 hours, zero or near-zero orders. Full revert. Flip DNS, re-enable the old checkout, put the Shopify store back behind a password, done. Cost: the cutover weekend and your credibility with the board. Nothing else.
6 to 72 hours, orders flowing. Partial revert only. Storefront and checkout go back to the old platform; Shopify orders get fulfilled out of Shopify and reverse-imported later. You need someone who can reconcile inventory across both systems manually for the gap period, because your WMS will be counting one and not the other. If you're on Unicommerce, EasyEcom or Vinculum, expect the connector to need re-mapping in both directions.
After 72 hours. Fix forward. There is no rollback worth having. By now you have orders, returns, refunds, tracking links in customer inboxes, a Merchant Center feed pointed at new URLs and probably a payout cycle in motion. Every additional hour makes the reverse-import worse. We tell clients this before cutover so nobody asks for a rollback on day five.
Day-one "sales drops" that are not sales drops
Roughly half the panic calls we get in the first 24 hours after a migration are measurement problems. GA4 is firing twice, or not at all. The Meta pixel is on the theme but the Conversions API endpoint still points at the old server, so purchases arrive with no event ID and get deduplicated into nothing. Someone left the old GTM container live alongside Shopify's native channel integration.
Fix this before cutover by deciding that Shopify's own order list is the only source of truth for the first week. Not GA4. Not Meta. Not Shiprocket. Have one person pull order count and gross revenue from the Shopify admin every 30 minutes against the same clock hour from the previous four same-weekdays. If the admin shows normal orders and GA4 shows a cliff, you have an analytics bug. Ship the fix on Monday. Do not touch DNS.
The other free diagnostic: a synthetic checkout. Keep an unlisted ₹1 product, and every 15 minutes for the first six hours, run a real transaction end to end on a real card and a real UPI handle, then refund it. Two people, two devices, one on Jio 4G rather than office wifi. This catches the failure mode that costs the most and shows up the least in analytics — checkout completing for cards but failing for UPI, or COD silently unavailable because a shipping profile didn't get a rate for the pincode zone you sell most into.
Thresholds worth writing down before you cut over
Use conversion rate, segmented by channel, against a 14-day baseline from the same days of the week. Raw revenue on day one is too noisy and too easy to argue about.
- Checkout completion down more than 25% versus baseline, cause not identified within 60 minutes. Revert if you're inside the six-hour window. This is the one threshold we don't negotiate. A broken checkout doesn't fix itself and every hour is full-price.
- Add-to-cart normal, checkout completion down. Payment or shipping configuration, nine times out of ten. Fix forward. Median time to fix in our experience is under 40 minutes once you look at the right thing: gateway credentials, a Razorpay webhook still pointing at the old domain, a missing shipping rate, or a COD eligibility rule copied over with the wrong condition.
- Sessions down more than 30% on organic within 24 hours. This is almost never a real ranking loss — rankings don't move that fast. Check for a live noindex, a robots.txt that came across from staging, or the storefront password still enabled for a subset of traffic. Fix forward, minutes not hours.
- Add-to-cart rate down more than 20% with traffic flat. Now you're looking at the storefront. Broken variant selectors, collection pages returning 404, filters that lost their metafield mapping, or a mobile LCP regression that pushed the product page past four seconds. Fix forward, but set a 12-hour clock on it.
- Paid traffic down with spend flat. Feed and catalogue. Merchant Center disapprovals from changed URLs, or Meta catalogue product IDs that no longer match the pixel's content_ids. Fix forward. Pause the worst-performing campaigns rather than reverting the store.
- Cause unknown after four hours, conversion rate down more than 25%, still inside 72 hours. Revert. "We're close" at hour four usually means hour nine.
One more that matters: know your own noise floor. If your baseline is 216 orders a day, pure random variation gives you a standard deviation of about 15 orders — call it 7%. A 10% dip on day one is probably nothing. A 30% dip on that volume is four-plus standard deviations and is definitely something. On a store doing 25 orders a day, a 30% dip is eight orders and could easily be a slow Tuesday, which means you cannot make this call on numbers at all and should be watching the synthetic checkout instead.
The arithmetic, worked
Take a store at 12,000 sessions a day, 1.8% conversion, ₹2,300 AOV. That's 216 orders and ₹4,96,800 a day.
Day one after migration: 11,400 sessions, 150 orders. Conversion is 1.32%, down 27%. Revenue ₹3,45,000. You are losing ₹1,51,800 a day.
Now price the two options. Fix forward with an unknown cause: assume three days to find and ship it, because unknown causes are never one day. That's ₹4,55,400 of lost revenue. Revert instead: a partial revert at hour eight costs you the reverse-import of about 50 orders, a second cutover weekend two to three weeks later, and the engineering time for both. Budget ₹1,50,000 to ₹2,50,000 all in, plus the delay.
Revert wins, and it isn't close. Flip that to a known cause with a two-hour fix — ₹12,650 of lost revenue at that daily rate — and reverting would be indefensible. The whole decision reduces to one question: do we know what's wrong? That's why the threshold is written as a time limit on diagnosis, not a revenue number.
Preparation that makes the rollback cheap
Everything here costs a few hours before cutover and saves days after.
- DNS TTL down to 300 seconds, 48 hours ahead. Old records saved as plain text, not in someone's memory.
- Do not cancel the old hosting, licence or plan for 60 days. Put it in read-only if you can. The ₹15,000 you save by cancelling early is the most expensive ₹15,000 in the project.
- Take a full order, customer and inventory export from the old platform in the hour before the domain flips. Timestamp it. That file is your reconciliation baseline and there is no substitute.
- Freeze the old admin. No manual orders, no price edits, no inventory adjustments after the export. Tell the ops team in writing.
- Cut over on a Tuesday or Wednesday morning, not Friday night. You want your gateway's support desk, your 3PL and your own developers awake. Never in the four weeks before Diwali.
- Redirect map in version control, with the reverse map generated at the same time. If you have to revert, you need the old URLs to stop 301-ing to Shopify within minutes.
- Baseline Core Web Vitals on the old store and on the new theme, on the same five templates, before launch. A day-one conversion drop with traffic flat is often just a slower product page, and without a baseline you'll spend six hours arguing about whether it got slower. Keeping a running score afterwards is worth automating — SwiftStore is what we use for the monitoring side, and we cover the deeper theme and app-script work in speed optimisation.
- Name one decision owner with the authority to revert without a meeting. Usually the founder or head of eCommerce. Put the thresholds in a shared doc they can read on a phone.
The awkward cases
Subscriptions break this framework. If you've migrated recurring billing, a revert means customer payment mandates now live in two places and you can double-charge people. On subscription stores we don't offer a post-order rollback at all; we run the new store in parallel on a subdomain for a fortnight first.
Multi-location inventory is the second one. Reverting inventory sync across three warehouses and a retail counter, mid-day, with orders in both systems, is a manual stock count. Plan for it or plan not to revert.
And B2B: if you moved wholesale price lists and net terms, a revert puts your dealers back on pricing they may have already seen change. That's a phone call, not a config change.
The two-week tail nobody plans for
Day one is loud. Days 8 to 20 are where the real revenue leaks, and no rollback plan covers them because by then reverting is off the table. Watch three things: organic landing pages that lost their redirect and are now 404s in Search Console; email deliverability if you changed sending domain, since a fresh DKIM record needs warming and Omnisend or Klaviyo will show it as a soft bounce spike; and internal search, which on large catalogues quietly stops returning results when the old synonym and filter configuration didn't come across. That last one shows up as a conversion drop that looks like nothing in particular.
Book a 20-minute review at day 3, day 10 and day 21. Same three dashboards each time. Boring, and it catches more money than the launch-night war room.
If you're planning a cutover in the next quarter and don't yet have thresholds written down, that's the gap to close first. We can look at your current setup and tell you where the revert risk actually sits — request an audit, or read how we sequence the work on our migration page.