Shopify doesn't give you a staging environment. There's no dev.mystore.com that mirrors production, no branch you promote, no way to test a checkout without touching real money. So when someone searches for Shopify staging store testing during a migration, what they're really asking is: which of three imperfect setups do I use, and what can each one actually prove? A duplicate theme on the live store tests front-end code and nothing else. A free development store tests almost everything except real payments. A paid new store with password protection switched on tests everything, including a live Razorpay transaction, while search engines stay locked out. For a migration, the third one is the answer. The first two are for theme work.
What follows is the script we run on a password-protected store before cutover. It's ordered by what breaks most often, which is not the order most people test in.
Why Shopify staging store testing isn't really staging
The new store is the production store. That's the uncomfortable part. You're not testing a copy that gets thrown away, you're testing the thing that will take orders on Friday, and every test order, test customer and test discount code you create stays in the database unless you clean it up. Write that down as a task now, because nobody remembers on launch day and the first week's revenue report is off by ₹6 worth of bogus orders.
Development stores are useful for the build phase, particularly if the client hasn't picked a plan yet. But they can't take a real payment. Bogus Gateway will happily accept card number 1 and return a success, which tells you the order flow works and tells you nothing about whether your gateway account is configured, whether UPI intent works on Android Chrome, or whether the COD fee lands on the invoice. Shopify Payments isn't available in India either, so the test-mode toggle that merchants in the US and UK use is off the table. You test with real money or you don't test payments.
Which means: pick the plan, build on the real store, keep the password on, and place small real orders. We usually use ₹10 and refund immediately. Note that the gateway's transaction fee on a refunded payment generally isn't returned, so a dozen test orders cost you a few rupees. Cheaper than a broken checkout.
What the password actually blocks (and the cookie that gets you round it)
Storefront password protection stops anything that fetches your URL as an anonymous visitor. That list is longer than people expect:
- PageSpeed Insights, Lighthouse via web, and any hosted speed tool
- Google's Rich Results Test and the URL Inspection tool in Search Console
- Facebook's sharing debugger, so you can't validate Open Graph tags or the WhatsApp link preview your customers will actually see
- Screaming Frog and most crawlers, unless you configure them
- Google Merchant Center feed fetches, which matters if Shopping is a big channel for you
Two workarounds. Enter the storefront password in a browser, then copy the storefront_digest cookie out of dev tools and give it to your crawler's custom-headers config. Screaming Frog will then crawl the whole site and you can check titles, canonicals, redirect chains and orphan pages before launch. The other is the share-preview link from the theme editor, which bypasses the password for whoever holds it, and is handy for getting client sign-off without teaching six people a password.
Speed is the one thing you genuinely cannot benchmark properly until the password is off, because the password page isn't your theme and the preview link adds Shopify's editor overhead. Run Lighthouse locally against the preview for a rough read, then take a real baseline within an hour of going live. If you want that measured continuously rather than remembered once a quarter, SwiftStore is the app we built for it, and our notes on what actually moves LCP on a Shopify theme are on the speed optimisation page.
The payment script
Order matters here. Test the boring path first, then the ways people abandon.
- One prepaid order via card, one via UPI, one via netbanking. On mobile, on a real phone, not a resized desktop window. UPI intent handoff is the most common thing that works on desktop and fails on an in-app browser.
- A deliberately failed payment. Enter a card that will decline, then check that the customer lands back on the cart rather than a dead end, and that Shopify records an abandoned checkout with the email attached. This is where recovery revenue comes from and it's almost never tested.
- COD, with every rule you've configured. Minimum cart value, maximum cart value, pincode restrictions, product exclusions. If you use a COD app, test the boundary: if COD is blocked above ₹5,000, put ₹4,999 in the cart and then ₹5,001.
- The COD fee itself. If it's ₹49, confirm whether GST applies on top and whether the fee appears on the invoice your accountant sees. We get this wrong on the first pass often enough that it's a standing checklist item.
- Partial-COD or advance-payment flows, if you sell high-ticket items. These break in interesting ways when the customer edits the cart after paying the advance.
- An international card, if you sell to the diaspora. Check the presentment currency, whether 3DS triggers, and what the customer is charged versus what you're settled.
Then refund one of them end to end, because refund permissions and the gateway's refund API are a separate configuration from payments, and the day you discover this is usually the day a customer is shouting.
Tax checks that catch most migrations
The single most common data error we see in a Shopify migration is tax-inclusive pricing imported as tax-exclusive. Here's the arithmetic, because it's easy to check and easy to miss.
Say your catalogue is priced inclusive of 18% GST and a product sells at ₹1,499. Set up correctly, Shopify shows ₹1,499 at checkout and breaks it into ₹1,270.34 base plus ₹228.66 tax (1499 ÷ 1.18 = 1270.34). Set up wrongly, with "all prices include tax" unchecked, Shopify shows ₹1,499 plus ₹269.82 = ₹1,768.82. Your customer sees an 18% price rise overnight and your conversion rate tells you about it before your reports do.
The fast cart-level check: on a tax-inclusive store, total tax divided by order total should equal 18/118, or 0.15254. Put three of that product in the cart, total ₹4,497, and tax should read ₹685.98. If it reads ₹809.46, the setting is wrong. Do the same test for each rate you charge.
Two more that bite:
The Variant Taxable column. Shopify's product CSV has one, and if your export from WooCommerce or Magento left it blank on some rows, those variants charge zero tax and nobody notices until a GST filing. Filter your import file for it before you upload, and after import, sort products by tax status in the admin.
Look at rate thresholds too. Some categories in India change GST slab above a price point, and Shopify's tax overrides are set per collection and per region, not per price. Which means the override that's correct for a ₹900 kurta is wrong for a ₹3,200 one, and you need collections that split on price, or an app, or a manual process someone owns. Confirm the current thresholds for your HSN codes with your CA rather than trusting a blog post, including this one. Rates move.
If you're selling into the UAE, test a Dubai address for 5% VAT and confirm the tax registration number appears on the invoice. If you sell B2B to GST-registered buyers, test that the GSTIN field on checkout is actually collected and actually reaches your invoicing app, not just stored as a note nobody reads.
Tracking, on a store analytics can't reach
The password page is not your theme. It's a separate template that loads almost none of your scripts, so GA4 won't fire there and you'll see a handful of sessions with strange landing pages. Ignore them.
What you can test, using the password to get in:
- GA4 in DebugView with the Google Analytics debugger extension on. Walk the funnel: view_item, add_to_cart, begin_checkout, purchase. Confirm the purchase event carries the right value and currency, and that value is ex-tax or inc-tax consistently with however your reporting is set up.
- Meta pixel plus Conversions API. The thing to check is deduplication: one Purchase in Events Manager, not two, with matching event IDs. Test-event codes make this quick.
- Custom pixels in Shopify's Customer Events, since the additional-scripts box on the order status page no longer exists on current checkouts. If your migration brief says "port the tracking scripts across", someone needs to rewrite them as pixels rather than paste them.
- Consent behaviour. If you're using a consent banner, test that events actually fire after acceptance, and that they don't before. Half the consent implementations we inherit block everything permanently because the banner never registers a decision.
Server-side and offline conversion setups are worth a second pass a week after launch, once you have real volume to compare against Shopify's own order count. Pre-launch, you're only proving the plumbing exists.
Redirects you can only half-test before DNS moves
Your 301 map lives in Shopify's URL redirects, and those redirects only fire when a request reaches Shopify. Until DNS points at the new store, a request for the old URL goes to the old platform, so you cannot test the redirect itself. You can only test the destination.
So do that. Take your redirect CSV, feed the destination column to a crawler with the storefront cookie set, and confirm every target returns 200. Any 404 in that column is a redirect that will send Google and your customers to a dead page the moment you cut over. Pull the old site's top 200 URLs by organic traffic and check those first; the long tail can be fixed in week one.
Keep the collection and page URL structure the same wherever the old platform allows it. Every URL you don't have to redirect is a redirect that can't break. And if you're moving from a platform with a different handle scheme, expect the product-URL map to be the largest single line item in the project. More on how we sequence this on the migration page.
Data checks nobody enjoys
Counts first. Products, variants, images, collections, pages, blog posts, customers. Compare the old export line count to the new admin count and explain any gap. "Roughly the same" is not a check.
Then the ones that hide:
Inventory has to sit at the right location. This breaks if you have more than one, and it breaks silently: the total is right, the split is wrong, and your rate profiles start quoting shipping from a warehouse that doesn't hold the item. Test a checkout for each location's catchment.
Customer passwords never migrate. Nobody's do, from any platform, because they're hashed. Your customers will need to reset or accept an account invite, so decide before launch whether you're sending invites in batches or letting people reset on first login, and write the email accordingly. Sending 40,000 account invites at once from a fresh sending domain is a good way to meet your spam folder.
Metafields, subscription contracts and review content each need their own verification. Reviews in particular: importing them into Judge.me or Loox is straightforward, but star ratings only reappear in Google after the structured data is crawlable, which is after the password comes off.
Emails, notifications and the things that wait for DNS
Place a test order and read every email it triggers. Order confirmation, shipping confirmation, refund notification. Check the from-name, the reply-to, the logo, and whether the currency renders as ₹ or as a broken box in Outlook.
Sender authentication is the piece that can't finish before cutover, because SPF and DKIM records live on the domain you haven't moved yet. Prepare the records, get them ready to paste, and lower the TTL on the domain to 300 seconds a full day before launch so the switch propagates in minutes rather than hours.
The last thirty minutes
In order: turn off the password, verify robots.txt isn't blocking the storefront, submit the sitemap in Search Console, take a PageSpeed baseline on the homepage and one product page, place one real order with your own card at full price, and watch the first ten organic sessions come through in real-time analytics. If the first real order includes the right tax, the right shipping rate and the right tracking event, you've had a good launch.
Then leave the old store's admin accessible for at least ninety days. Historical orders, dispute evidence, a customer asking about something from March. You'll want it.
If you're partway into a migration and want a second pair of eyes on the tax setup and redirect map before you take the password off, send us the store and the URL list through the free audit form. We'll tell you what we'd test first.