During an online store migration, customers still need to find products, see the right prices and complete their orders. Existing search results, refunds and everyday administration also belong in the plan.
This checklist is our recommended approach to defining and accepting a migration. Google and Stripe provide the primary references for URL changes and payment notifications. The implementation depends on your platform and payment provider.
Start with what your store needs to do
Create a function inventory before choosing a design or technology. Have the owner and the person processing orders walk through a normal working day together. For each function, record what must remain, what can be removed and what should work differently.
This prevents a quote from counting products and pages while missing the difficult work until development begins. Integrations, exceptions and historical data often determine the real scope.
- Product variants, stock, price lists, discount codes and shipping rules.
- Tax settings, invoices, returns and full or partial refunds.
- Payment methods, subscriptions, open orders and any stored payment mandates.
- Accounting, carriers, suppliers, marketplaces and other integrations.
- Administration roles, languages, customer accounts, downloads and information you need to retain.
Keep URLs when possible; map changes when necessary
Changing technology does not automatically require changing public URLs. If addresses change, Google recommends mapping old URLs to new ones, configuring permanent redirects and monitoring the move. Google also warns that search rankings may fluctuate temporarily.
Our recommendation is a table containing the old address, new address, reason and test result. Start with product and category pages receiving traffic or external links. Include images, manuals and other useful files. Avoid sending every discontinued product to the homepage without a relevant destination.
Before launch, check important pages, internal links, canonical URLs, language references and the sitemap. Keep a baseline of traffic and errors so changes after launch can be assessed. A platform change alone cannot guarantee unchanged rankings.
Test the complete payment journey
A thank-you page does not prove that an order has been paid and processed correctly. Stripe describes webhooks as notifications for asynchronous events, including payment confirmations. Its documentation covers verification and testing. For another provider, use that provider’s integration guidance.
Our recommended acceptance test follows an order from basket to administration. Use test data and your provider’s testing environment. Separately agree whether a limited live payment and refund test is needed, who performs it and how the result will be checked.
- Successful, failed, cancelled and pending payments produce the correct order status.
- Duplicate or delayed payment notifications do not trigger duplicate fulfilment or stock changes.
- Confirmation emails, invoices, shipping charges and discounts are correct.
- Full and partial refunds are reflected correctly in the store and administration.
- Existing subscriptions and mandates transfer only where the provider and chosen integration support it.
Plan the final data transfer and the way back
Orders may continue arriving in the old store during migration. Record when the final transfer happens, whether ordering will pause and how new orders and stock differences will be reconciled. Restoring an older database could overwrite orders received in the meantime.
Our recommendation is to agree a go or rollback decision point with an owner and clear stop conditions. Examples include an unavailable checkout, incorrect amounts or missing payment confirmations. Document what happens to new orders if you roll back. Possessing a backup file is not a complete rollback plan.
After switching, check real order statuses, provider notifications, error logs and important old URLs. Retain the old environment only for the agreed period and purpose. Prevent both environments from independently processing the same orders.
What TovieIT needs first
For a bespoke React and Node.js rebuild, we first discuss existing functions, integrations, data and your preferred administration workflow. Scope, phases, hosting, maintenance and acceptance criteria can then be agreed. A visually similar demo does not establish that all commerce functions have been transferred.
Start with your platform, approximate catalogue size, payment provider, important integrations and reasons for moving. Identify the functions that must keep working. Share exports or credentials only after clear arrangements have been made.
Sources checked:
Sources & verification
The links below lead to the original documentation. Versions and advice may change; ask your host to check your own setup.
Updated:
About this publication. TovieIT builds and hosts websites. This guide is our own publication; general information is not an individual security assessment.