Search results
0No results yet. Try a broader topic or a shorter phrase.
Migration and launch
Map legacy URLs, historical orders and incremental data, then verify the buying journey, cutover conditions, exceptions and recovery at one cutoff.
For · Owners preparing a migration, redesign cutover or launch
1 / 4
Inventory & mapping
Decide which identities and routes to retain.
InputPrevious data, URLs and key journeysOutcomeMigration inventory and URL destinations
What should a migration inventory capture?
Capture URLs, products, customers, orders and critical journeys with their source and identity. Decide separately how to retain useful pages, retire unmatched URLs and preserve required records.
- Save exports with a capture time.
- Identify traffic entries, link destinations and system dependencies.
Search Console examples do not constitute a full site inventory.
When should an old URL stay, redirect or return 404?
Keep an address that still serves its intended content. Use a permanent redirect when there is a clear replacement, and return a genuine missing-page response when content has been removed without a replacement.
- Identify the original article, product or collection.
- Check the final destination, language, canonical URL and redirect chain.
Do not redirect every retired URL to the homepage to reduce a report count. A valid redirect source does not need its own indexed page.
Articles & checklists for this step
Legacy URLs: retain, redirect or retire
Build an evidence-based inventory
Record the old response status, content identity, language, market and purpose. Distinguish current pages, moved content, confirmed retirements and unknown identities. A shared language prefix does not establish that the pages serve the same purpose.
Choose the correct outcome
Where a directly relevant replacement exists, use a permanent redirect to that destination. A confirmed retired page without a suitable replacement can return a genuine 404 or 410. Keep active business pages and investigate unknown identities first.
Group by verified rules and sample
Separate primary, redirect and alias domains from individual path rules, and check query parameters and market subfolders. Apply shared rules only to confirmed matches. Sample articles, collections, languages and pages with backlinks; record the first response, final destination, content, language and canonical. Do not send unrelated old URLs to the home page.
Update discovery paths
Point internal links and sitemaps to current canonical pages that should be discovered. Check that temporary preview crawl restrictions are removed where appropriate; blocking a crawler is not a notice that a page was deleted.
Track site and search separately
Keep before-and-after samples, dates and a recovery method; reconcile orders and notifications across the cutover window. In webmaster tools compare the crawl date, declared canonical and index status of old and destination URLs. A correct site response does not mean search results have already updated.
Teaching scenario: three different outcomes
Suppose an old product page moves to a new URL for the same product: verify the permanent redirect. If an event has ended with no suitable replacement, verify a genuine 404/410. Keep a regional service page that is still in use. Confirm identity and destination before grouping; a passing sample does not mean a search engine has updated the whole group.
2 / 4
Data & accounts
Verify identities, cutoffs and differences.
InputInventory and original recordsOutcomeReconciled records and account behavior
How should you define a migration cutoff?
Use one time and time zone to identify the final changes included from the old store, and state when the new store takes over orders and stock. Reconcile by resource ID and distinguish historical data, the final delta and new activity.
- Record the final batch, open fulfillments and pending refunds.
- Assign each discrepancy and retain its resolution.
Normal sales do not replace order and inventory reconciliation. Real cutover evidence must come from project records.
How should customer login be tested after migration?
Separate customer records, account identity and sign-in method. Test existing and new buyers through the selected migration route, then verify notifications, order visibility and recovery before opening access.
- Test both successful and failed sign-in.
- Check order association, language and support routes.
Transferred customer records do not establish transferred passwords or authenticated sessions.
Articles & checklists for this step
Four checks on migration cutover day
Keep one cutover record with a result, evidence and an owner for each check. Use it to make the launch decision.
Record the data cutoff and handover
Record the cutover time and time zone, the last batch of changes and who owns orders and stock on each side. Use the same cutoff to reconcile open fulfilments, pending refunds and stock discrepancies. For imports linked to existing customers, test an old order with a different address. Compare the historical order address and the customer’s default address before and after import.
Test the customer journey
In a target market, follow the product, cart and checkout journey on a phone and desktop. Use a test order to verify addresses, shipping, orders, stock and notifications. Restore live payment settings before opening to customers and verify real payments and payouts separately. Compare the order record with checkout_completed. Check the thank-you page in a standard flow and the first offer page with a post-purchase upsell. Record what happens if that page fails to load.
Open important old URLs
Follow real old links to products, collections and policies. Check the final destinations, languages and canonical URLs. Confirm that live pages are accessible, check the sitemap and review any crawl restrictions used for preview. Shopify's FOOTDISTRICT case reports that redirects covered only the highest-traffic old pages. Rankings dipped after launch and then recovered. Before launch, sample old URLs with organic clicks or backlinks. Include long-tail products, collections and localized paths. Where a corresponding new page exists, check for a permanent redirect to that page. Record the status, final URL, language and canonical URL.
Agree when to stop or roll back
Pause the switch if checkout fails, important redirects are wrong or data discrepancies remain unexplained. If rolling back, record new orders, payments and stock changes first. Restore the previous entry point as planned and reconcile both sides again.
3 / 4
Transactions & cutover
Validate transactions before switching traffic.
InputVerified data and environmentsOutcomeTransaction evidence and launch decision
How should transactions be checked before cutover?
Follow options, cart, delivery, payment return and notifications using test addresses for target markets. Record actual currency and charges, verifying current plan and extension capabilities.
- Cover success, failure and cancellation routes.
- Match orders and refunds with downstream records.
Test payments are separate from settlement; do not create failures on real customer orders.
When should a launch be paused?
A failed buying journey, incorrect critical redirects or unexplained data differences should trigger the agreed stop decision. The owner decides whether to continue, fix or recover from recorded impact and evidence.
- Define triggers, decision owners and recovery order before launch.
- Separate simulated orders, real payments, notifications and later reconciliation.
Test payments and live payments are different. Do not overwrite the new store’s activity before reconciling what happened after cutover.
Articles & checklists for this step
Pre-launch checklist
Complete each check and retain evidence. Ticks last only for this page visit and reset on refresh.
4 / 4
Recovery & observation
Reconcile new activity after the switch.
InputCutover environment and new ordersOutcomeResolution, recovery and review
What should be observed immediately after cutover?
Inspect key entries, orders, payment evidence, legacy destinations and data differences. Pause expansion or recover according to agreed conditions, recording impact, ownership and resolution.
- Compare the same critical routes before and after cutover.
- Keep previous-environment and mapping records traceable.
Recovery must account for new data created after the switch.
Maintained by WESWOO · 2026-11-12
Related service · Migration and implementation scope ↗Working on a store project?
Connect what you have learned to the right scope, people and next steps.