Verify the checkout flow end to end, with real conditions
Run a complete purchase yourself on the live site — not staging — covering the paths customers actually use: guest checkout and logged-in checkout, at least one product with variants, and any discount codes or promotions currently active. Check that order confirmation emails send correctly and that the order appears properly in your admin/order system afterward.
Don't assume staging coverage transfers automatically. Live payment gateways, live tax services, and live shipping-rate APIs sometimes behave differently than their staging or sandbox equivalents, which is exactly why this needs a real, live-conditions check rather than relying on what passed in staging.
Confirm payment gateways are fully live and correctly configured
Verify that payment processing is running in live (not test/sandbox) mode, that all payment methods your store previously supported are enabled and working, and that a real transaction settles correctly end to end — funds actually arriving, not just an order status changing. Check refund functionality too, since it's used less often than checkout and easy to leave unverified.
If you support multiple payment methods or currencies, test each one individually rather than assuming that because one method works, the rest are configured the same way.
Check tax and shipping rules against real orders
Tax and shipping logic is easy to get subtly wrong in a migration, since both often depend on configuration that doesn't map cleanly between platforms. Place test orders to your most common shipping destinations and confirm tax is calculated correctly and shipping rates and available methods match what you intended — not just what the new platform defaulted to.
Pay particular attention to any special cases your business relies on: tax exemptions, free-shipping thresholds, region-specific rules, or shipping restrictions on certain products. These are exactly the configuration details most likely to get lost or defaulted incorrectly during a migration.
Spot-check redirects, not just the ones you remember
Even with a complete redirect map built before launch, spot-check a real sample of URLs after cutover: your highest-traffic pages, a handful of lower-traffic ones, and a few of the deliberate exceptions (discontinued products, merged categories). Confirm each redirects to the correct destination in one hop, with no chains or loops.
Also check a sample of URLs that shouldn't exist on the old site — typos, old parameter-based URLs, anything a crawler might have indexed incidentally — to make sure they resolve sensibly rather than erroring in a way that looks like a broader problem.
Confirm analytics and tracking continuity
Verify that your analytics platform, conversion tracking, and any advertising pixels are firing correctly on the new site — a placed test order should show up in your analytics and ad platform reporting the way it did before. Tracking code is easy to lose silently during a platform change, since a missing or misconfigured pixel doesn't produce an error message; it just stops reporting data.
Compare early post-launch analytics numbers against your pre-migration baseline for the same type of day (weekday vs. weekend, similar traffic sources) rather than a raw before/after comparison, since normal traffic variation can otherwise mask or mimic a real tracking problem.
Check customer account access and order history
Have a few real (or test) customer accounts confirm they can log in, see their correct order history, and access any account features they relied on before — saved addresses, saved payment methods where applicable, loyalty or reward balances if your store has them. Account access issues are highly visible to the customers who hit them and directly affect trust, so they're worth verifying deliberately rather than assuming the account migration "probably worked."
If password migration wasn't part of the technical transfer (common when platforms use incompatible password hashing), make sure customers have a clear password-reset path and that it's communicated, not just technically available.
Monitor Search Console coverage in the following weeks
Keep watching Search Console (or the equivalent for other search engines) well past launch day — crawl errors, indexing status, and any spike in reported 404s are the earliest signals of a redirect or canonical issue that testing missed. Compare against your pre-migration baseline so you can distinguish a real regression from normal short-term fluctuation after a site change.
This monitoring period is also when it's worth resubmitting your sitemap if you haven't already, and confirming that pages you expect to be indexed are actually appearing in search results over the following weeks, not just crawled.
Frequently asked questions
How long should post-launch QA continue after cutover?
Active, daily-style checking typically matters most in the first one to two weeks, when most configuration and redirect issues surface. Search engine re-indexing and traffic pattern stabilization take longer, so lighter monitoring (Search Console, analytics trends) is worth keeping up for longer — several weeks is common — rather than stopping the moment the first week looks clean.
What's the single most important thing to check first after launch?
A real, live checkout and payment test, since it directly affects revenue and is the one flow every customer touches. Redirect and tracking issues matter too, but a broken checkout is the most costly problem to leave undiscovered even for a few hours.
Is it normal for search rankings to dip slightly right after a migration?
Some short-term fluctuation is common even with a well-executed migration, since search engines need time to re-crawl and re-evaluate the new URLs. What isn't normal is a sustained drop or a spike in crawl errors — that's the signal to check your redirect map and canonical tags for a real mistake rather than waiting it out.
Who on the team should own post-launch QA?
Ideally someone with visibility across the whole store, not just the technical migration team — because several of these checks (tax rules feeling right, customer account behavior, whether tracking numbers look normal) benefit from business context, not just technical verification that a feature is present.