/ Journal — Migration
How to Test a Shopify Migration Before You Change DNS
Shopify migration testing should prove that the new store can trade safely before customers reach it. That means more than checking pages in a theme preview. You need evidence that migrated data is accurate, buying journeys work, orders reach downstream systems, SEO controls are ready, and the launch team can execute the cutover without improvising.
/ In plain terms
DNS is the traffic switch, not the start of testing.
By the time you change DNS, the important unknowns should already be closed. The remaining launch work should be a short, rehearsed sequence: final data delta, production activation, DNS change, smoke tests, and monitored handover.
Short answer: Test a Shopify migration on a password-protected or otherwise controlled Shopify store using production-like configuration and representative data. Reconcile imports, run end-to-end customer and operational journeys, validate payments, shipping, tax, integrations, analytics and SEO, complete business UAT, then rehearse the cutover. Change DNS only when every launch-critical gate has passed, owners are available, and rollback or containment decisions are documented.
/ What testing must prove ( 06 )
What Shopify migration testing must prove.
A migrated store can look finished while still being unsafe to launch. A product page may render correctly but carry the wrong tax status. Checkout may accept an order that never reaches the ERP. A redirect file may import successfully while high-value legacy URLs still return 404s. Testing has to cover the full trading system. Define the release in terms of outcomes:
( Release outcomes )
+Customers can find, understand and buy the right products.
+Prices, discounts, tax, shipping and payment totals are correct.
+Orders, inventory, fulfillment, refunds and customer communications flow to the right systems.
+Staff can operate the store using documented processes and appropriate permissions.
+Search engines receive intentional URLs, redirects, canonical signals and indexability rules.
+The team can launch, monitor and contain a failure without guessing.
Convert each outcome into an acceptance test with an owner, expected result and evidence. “Checkout tested” is not an acceptance criterion. “A UK guest can purchase a taxed physical product with the primary card method, receive the correct confirmation, and create the expected paid order in Shopify, the ERP and the 3PL” is.
/ Risk levels ( 04 )
Build a risk-based test strategy.
Do not test every page and SKU with equal effort. Start with the failures that could stop revenue, mischarge a customer, corrupt inventory, expose personal data or damage organic traffic. Then test representative combinations around those risks.
01 · Launch blocker
Fix and retest before DNS change
Checkout unavailable, payment capture failure, materially wrong tax, orders missing from fulfillment, critical data corruption.
02 · High
Fix before launch unless an explicit, safe containment is approved
Broken key-market shipping method, faulty customer login, missing top landing-page redirect, unreliable inventory sync.
03 · Medium
Assign an owner and resolution date
Non-critical content defect, edge-case layout issue, low-volume workflow with a documented manual workaround.
04 · Low
Move to the stabilization backlog
Cosmetic refinement or post-launch optimization.
Create a coverage matrix across the dimensions that change behavior: market, currency, language, customer type, device, browser, product type, inventory location, discount, shipping method and payment method. Use pairwise coverage for lower-risk combinations, but test every commercially important route end to end.
( Test evidence )
Keep evidence, not just a defect list.
When a fix lands, rerun the failed scenario and any adjacent journey it could affect.
Launch-critical test Evidence
Every launch-critical test should show
The input, expected result, actual result, environment, build or configuration version, tester and date.
/ Environments ( 04 )
Choose environments that are close enough to production.
Most teams test the Shopify build on its myshopify.com address, through a controlled preview, or on a password-protected storefront before the public domain points to it. The exact setup matters less than keeping customer traffic out while using production-like configuration.
01 · Development
Development
For theme work, app development and early integration checks. Test data can be disposable. Expect frequent change and do not use this environment for business sign-off.
02 · Rehearsal
Migration rehearsal
For repeatable imports, transformation fixes and reconciliation. Reset or clearly separate runs so old test records do not hide duplication problems.
03 · Pre-production
Pre-production Shopify store
For integrated QA and UAT with near-final theme, apps, markets, shipping, tax, notifications and production-like data.
04 · Production
Production at launch
For final activation and smoke testing after the domain switch. This is confirmation, not the first time a critical journey is attempted.
/ Side effects
Control side effects.
Test orders must not reach a live warehouse unless that is intentional. Customer emails and SMS should go to approved test recipients. Marketing automations, review requests, loyalty awards, accounting exports and marketplace feeds may all need suppression or sandbox endpoints.
Keep a configuration register for anything that differs before launch: payment test mode, API credentials, webhook URLs, domain references, email sender authentication, app billing, warehouse routing, analytics filters and search-engine access. Each difference needs a named activation step in the cutover runbook.
/ Data validation
Validate migrated data with counts and field-level checks.
Shopify’s migration guidance recommends importing products before customers and historical orders so records can be connected correctly. It also tells merchants to verify product details such as prices, weights and inventory after import. Your test plan should go further than confirming that an import job completed.
( Reconcile the population )
+Compare source and target counts by status and type, not only grand totals.
+Reconcile products, variants, customers, addresses, orders, line items, discounts, refunds, fulfillments, content and redirects.
+Explain exclusions such as obsolete products, suppressed customers or unsupported records.
+Check duplicate SKUs, handles, emails, external IDs and records created by reruns.
+Confirm that the final delta can capture records created or changed after the main export.
/ Edge cases
Sample the difficult records.
Random samples are useful, but deliberately select edge cases: products with many variants, bundles, subscriptions, preorders, unusual weights, tax overrides, multi-currency orders, partial refunds, guest customers, duplicate emails and discontinued products. Verify relationships as well as individual fields.
For products, inspect status, sales-channel publication, title, handle, description, media, options, SKU, barcode, price, compare-at price, cost, weight, taxability, inventory and metafields. For customers, check addresses, consent, tags, exemptions and account behavior. For historical orders, verify dates, currency, totals, discounts, tax, payment state, fulfillment state, refunds and links to customers and products.
Run transformations from scripts or documented rules wherever possible. A migration that only works after undocumented spreadsheet edits is not ready for a final delta under launch pressure.
/ Customer journeys ( 08 )
Test complete customer journeys.
Journey testing follows a user from entry page to post-purchase service. It catches failures between components that isolated page checks miss.
01Land on a top organic, paid, email and direct URL.
02Navigate collections, search, filters, sorting and recommendations.
03Open simple, multi-variant, discounted, bundled, subscription and out-of-stock products.
04Add, update and remove cart items; apply and remove valid and invalid discounts.
05Check guest, new, returning, tax-exempt and international customer flows.
06Complete checkout with representative addresses, delivery methods and payment types.
07Verify confirmation pages, emails, account history and tracking links.
08Cancel, edit, refund, return and exchange orders where those workflows are in scope.
Test on the browsers and devices that matter in real analytics, including a lower-powered mobile device and constrained network. Check keyboard navigation, focus, labels, error recovery, contrast and screen-reader-critical controls. A migration should not carry known accessibility failures into a new platform by default.
/ Payments
Test payments without creating false confidence.
Shopify documents test orders using Shopify Payments test mode or Shopify’s Bogus Gateway, subject to the store and provider setup. Use the supported test method to exercise approved and declined payments, but remember that a simulated authorization does not prove the complete production settlement path.
Before DNS changes, confirm that the production payment account is approved, live credentials are available, payout and statement settings are correct, and the launch owner knows which test settings must be disabled. After cutover, place a controlled low-value live order where operationally and legally appropriate, then verify capture, notifications, downstream export, cancellation or refund, and payout visibility. Never leave test mode active on a public store.
01Test successful authorization, decline, retry and customer abandonment.
02Check immediate versus manual capture behavior.
03Verify 3D Secure or other authentication behavior where applicable.
04Test full and partial refunds, cancellations and inventory restoration.
05Check accelerated wallets and alternative methods used by key markets.
06Confirm fraud tools, order risk handling and staff review processes.
07Verify correct payment status reaches the ERP, OMS, accounting and support systems.
08Document the exact switch from test mode to live credentials.
/ Shipping, tax and duties ( 04 )
Test shipping, tax and duties by scenario.
A single local postcode cannot validate a multi-market store. Build a scenario table from actual commercial rules.
01 · Shipping
Shipping
Scenarios: domestic, remote area, free-shipping threshold, heavy parcel, split location, pickup, unsupported destination.
Verify: rate, carrier, service name, delivery promise, exclusions and fallback behavior.
02 · Tax
Tax
Scenarios: tax-inclusive and exclusive markets, taxable and exempt product, exempt customer, relevant state or region.
Verify: registration, product tax status, displayed price, checkout calculation, rounding and order record.
03 · Duties
Duties
Scenarios: cross-border order, delivered-duty-paid or unpaid route, restricted product.
Verify: customer disclosure, calculation, carrier or service handoff and reporting.
04 · Inventory
Inventory
Scenarios: single and multi-location stock, oversell, backorder, partial availability.
Verify: sellability, routing, decrement, reservation, cancellation and restock.
Use known expected totals for each scenario and compare them line by line. Ask finance, operations and any qualified tax adviser to approve the cases that carry regulatory or accounting risk. The migration team should not infer tax policy from whichever total checkout happens to produce.
/ Integrations ( 08 )
Prove every integration end to end.
An API returning 200 is not the same as a working business process. Test the complete chain, including retries and human exception handling.
+ERP or OMS: product, price, customer and order creation; edits; cancellation; refund; source identifiers.
+WMS or 3PL: routing, allocation, holds, split shipments, tracking, cancellation and inventory updates.
+PIM: field ownership, variant matching, publication, images, metafields and deletion behavior.
+Subscriptions: plan selection, contract creation, renewal, skipped or failed payment and customer self-service.
+CRM and service: profile matching, consent, tickets, order lookup and redaction rules.
+Marketing: audience sync, transactional versus promotional consent, abandoned checkout and suppression logic.
+Analytics: consent state, page and ecommerce events, currency, value, item data, attribution and duplicate prevention.
+Marketplaces and feeds: product eligibility, pricing, availability, order ingestion and cancellation.
Force failures: expire credentials, send an invalid identifier, pause a downstream service, duplicate a webhook and exceed a normal processing delay. Confirm retries are safe and idempotent, alerts reach an accountable person, and replay does not create duplicate orders or inventory movements.
/ SEO migration testing
Run SEO migration testing before DNS changes.
SEO testing should compare the old and new sites at URL level. Start with an inventory assembled from the legacy sitemap, a crawl, analytics, Search Console, backlinks, product feeds and campaign landing pages. Map each valuable old URL to the most relevant new destination.
Shopify notes that redirects only work from URLs that are actually broken and that some reserved or fixed paths cannot be redirect sources. Review the current Shopify URL redirect rules before finalizing a large map. Test redirects on the Shopify store path before launch where possible, then repeat critical checks on the public domain after DNS changes.
Keep the pre-launch store out of search results while it is not ready, but do not accidentally carry blocking controls into production. Password protection, noindex rules, robots behavior and app-level access controls all belong in the cutover checklist.
01Crawl the Shopify build while it is controlled and verify status codes, internal links and crawl depth.
02Check titles, meta descriptions, headings, body copy, image alt text and important structured data.
03Verify canonical URLs, indexability directives, hreflang or market signals and pagination behavior.
04Test high-value redirects individually and the full redirect set programmatically.
05Find chains, loops, redirects to irrelevant pages and legacy URLs with no mapping.
06Update internal links so they point directly to final Shopify paths.
07Confirm analytics and Search Console verification will remain available after launch.
08Prepare post-launch sitemap submission and monitoring for 404s, indexing and ranking changes.
/ UAT ( 06 )
Make UAT a business decision, not a demo.
User acceptance testing should be performed by the people who will sell, merchandise, fulfill, support and reconcile the store. Give them realistic tasks rather than a guided tour.
( Realistic UAT tasks )
01Merchandising creates and schedules a product, collection and promotion.
02Customer service finds a customer, edits an order, cancels an item and issues the approved refund.
03Warehouse or operations receives, fulfills and partially fulfills representative orders.
04Finance reconciles order, tax, payment, refund and payout records.
05Marketing publishes content and verifies campaign tracking and consent behavior.
06Store administrators manage staff access and complete routine configuration safely.
Record acceptance by functional owner. If the business accepts a known defect, document its impact, workaround, owner and deadline. Silence or attendance at a demo is not sign-off.
/ Cutover rehearsal ( 08 )
Rehearse the cutover before you touch DNS.
Run the launch plan against a fresh or clearly controlled state. Time every step and include communications, approvals and pauses. The rehearsal should expose dependencies that a spreadsheet cannot: export duration, import queues, app synchronization lag, certificate timing, provider support and the time required to validate the final delta.
01
Step 01
Start the freeze
Define which source-store changes stop and how approved exceptions are captured.
02
Step 02
Export the final delta
Include new and changed customers, orders, products, inventory, content or other scoped records.
03
Step 03
Transform and import
Use the same repeatable process proven in rehearsal.
04
Step 04
Reconcile
Compare counts, totals and launch-critical samples before traffic moves.
05
Step 05
Activate production services
Enable live payments, webhooks, integrations, email settings and operational routing in dependency order.
06
Step 06
Execute DNS changes
Use confirmed registrar access and pre-approved records. Shopify advises that third-party domain changes often take effect within two hours but can take up to two days, so plan for variable propagation.
07
Step 07
Run smoke tests
Test domain, SSL, navigation, checkout, live payment, order flow, analytics and critical redirects from multiple networks where practical.
08
Step 08
Hand over to hypercare
Monitor orders, payment failures, 404s, integrations, inventory and customer contacts with named owners.
/ Go/no-go gates ( 08 )
Use explicit go/no-go gates.
Data
Reconciled counts, approved exclusions, passed field samples and proven final delta
No-go: unexplained variance or repeatability failure in critical records.
Commerce
Passed key journeys across priority markets, products, discounts and customers
No-go: checkout, pricing, promotion or account blocker.
Payment
Test transactions, live-account readiness, refund path and activation checklist
No-go: unavailable primary method, wrong status flow or unresolved settlement risk.
Operations
Orders reach ERP/WMS/3PL; fulfillment, cancellation, refund and inventory flows pass
No-go: lost, duplicated or unroutable orders.
Shipping
and tax
Approved scenario totals for every priority market
No-go: material mischarge or unsupported core destination.
SEO
Crawl review, critical redirect pass, metadata and index-control checks
No-go: large-scale 404s, blocking production indexability or broken key templates.
People
Business UAT sign-off, support rota, access and escalation contacts
No-go: no accountable launch authority or operational coverage.
Cutover
Timed rehearsal, registrar access, backups, monitoring and containment plan
No-go: unrehearsed critical step or missing recovery decision.
( Hold the decision meeting close enough to launch that the evidence is current. One person should have authority to say “no-go.” Commercial pressure is not a reason to reinterpret a failed blocker as an acceptable risk. )
/ Final pre-DNS checklist ( 10 )
Final pre-DNS checklist.
+All launch-critical tests passed with current evidence.
+Migration counts, totals, exclusions and final-delta process approved.
+Priority customer, payment, shipping, tax and operational journeys passed.
+Production credentials and activation steps verified without exposing them in test evidence.
+Critical integrations passed normal, failure and retry scenarios.
+SEO crawl, redirect and index-control checks completed.
+Business owners signed off UAT and known exceptions.
+Cutover was rehearsed, timed and assigned.
+DNS access and records were independently checked.
+Monitoring, escalation, containment and post-launch ownership are active.
The best signal that a migration is ready is not an empty bug tracker. It is a body of evidence showing that the new store can take an order, operate it correctly, preserve discoverability, and recover from foreseeable failures. Build that evidence before DNS makes the decision public.
/ FAQ ( 08 )
Shopify migration testing FAQs.
When should Shopify migration testing start?
Start as soon as the first representative data and working journeys exist. Test imports and integrations in repeated cycles rather than waiting for a visually finished store. Final integrated QA and UAT should use a stable, production-like release before cutover rehearsal.
Can you test a Shopify store before changing DNS?
Yes. Teams commonly use the store’s myshopify.com address, a controlled theme preview or a password-protected storefront. Test the near-final configuration there, while preventing test orders, messages and data from leaking into live operational systems.
How do you test Shopify payments before launch?
Use the supported test method for the configured provider, such as Shopify Payments test mode or Shopify’s Bogus Gateway where available. Test approvals, declines, capture and refunds. Then include a controlled low-value live transaction after production activation because simulated payments do not prove settlement end to end.
What data should be checked after a Shopify migration?
Reconcile products, variants, customers, addresses, orders, discounts, refunds, fulfillments, inventory, content and redirects. Check both counts and field-level accuracy, with deliberate samples for complex variants, multi-currency orders, partial refunds and other edge cases.
How many test orders should a Shopify migration include?
There is no useful universal number. Build coverage from risk: every priority market, payment method, customer type, product type, shipping rule, discount route and downstream order flow needs evidence. A smaller structured suite is better than many repetitive orders that all follow the same path.
How should SEO redirects be tested before DNS changes?
Build a legacy URL inventory, map each valuable URL, import redirects, then test status and destination in bulk on the Shopify store where possible. Review chains, loops, irrelevant destinations and Shopify path limitations. Repeat critical tests on the public domain immediately after launch.
What is the difference between QA and UAT in a Shopify migration?
QA verifies that the implementation meets technical and functional requirements. UAT proves that business teams can complete real work and accept the result. Both are required: a technically correct store can still fail operationally, while a successful demo can miss serious integration defects.
What should block a Shopify migration launch?
Block launch for failures that can stop checkout, mischarge customers, lose or duplicate orders, corrupt critical data, break core fulfillment, create material compliance risk or cause uncontrolled SEO damage. High-risk exceptions need an explicit workaround, owner and approval; launch blockers need a fix and retest.
/ Next
Need an independent migration readiness review?
Signature Works helps established ecommerce teams test and launch Shopify and Shopify Plus migrations. We can review the migration architecture, reconcile critical data, test customer and operational journeys, validate integrations and SEO controls, and turn the cutover into an evidence-based release plan. Talk to us before the DNS change becomes the deadline.
Also worth a look: Migrations and rescues · Store audits · Shopify technical ownership
/ Next
Want this done on your store?
Tell us what’s going on. A first look costs nothing.