Connect the checklist to one release decision
An SEO migration project and the store transition should follow the same delivery calendar. Do not use this list only as instructions sent to a developer. Product, operations, marketing and technical owners need visibility of the results. Record complete, incomplete or not applicable, along with evidence, an owner and the next check. A not-applicable decision needs a reason; for example, unchanged domains can require a different set of verifications.
In an illustrative migration, all products may be imported while an old collection link still reaches an incorrect destination. In another, payment succeeds but the customer receives no notification. Those findings affect different parts of the journey. The purpose is to identify what blocks release and what requires follow-up, rather than create a readiness score. A checked box without a described test should not be treated as acceptance evidence.
Record the data scope and source-to-target mapping
Product-data quality checks reveal fields that may disappear during a move. Beyond titles and prices, inspect variant identifiers, stock, dimensions, images, categories, technical attributes and associated files. Do not assume the old and new platforms use the same data model. Customer and order-history transfers require separately approved access, purpose and scope.
Matching record totals do not prove accurate migration. For example, a product with two sizes may become one undifferentiated item; the total can look plausible while the customer sees an incorrect choice. Begin with ordinary, variant-heavy, unavailable and custom-field products. Keep the source-file version and tested destination record together. Avoid copying real customer details unnecessarily into a shared checklist. Missing fields should become an explicit business decision rather than an unnoticed loss.
Products and variants
Match source identifiers, destination identifiers and representative values. Check the selected variant’s image, price and stock behaviour together.
Customers and history
Write which records are transferred and why. Validate account access and historic-order visibility against platform capabilities rather than assuming password migration.
Unsupported fields
Choose an alternative presentation for unsupported attributes or files. Obtain the business owner’s approval instead of silently dropping information.
FROM READING TO A NEXT STEP
Review the unresolved items in your migration
Share the old and new platforms, the intended change and your most important checklist gap. We can scope the first task from the evidence.
Map old destinations to relevant new pages
For ecommerce SEO, the old URL inventory includes more than pages visible in the navigation. Review product, collection, content and campaign destinations using available traffic records. Give each old destination a relevant new equivalent, a removal decision or an investigation state. Sending all addresses to the homepage is not an equivalent customer journey.
Google’s URL-change guidance includes mapping and verification in the move. Writing a redirect does not prove that its destination is correct, accessible or useful. Open representative old addresses and record chains, errors or irrelevant targets. Internal links, canonical destinations and the sitemap should describe the actual published structure. Search processing and traffic can fluctuate, so the checklist does not guarantee zero loss. Where an equivalent no longer exists, document the decision rather than creating an unrelated replacement simply to avoid an error count.
Rehearse complete orders with representative scenarios
For store operations, migration acceptance does not end when an item enters the basket. Review selection, payment outcome, delivery rules, the staff order view and customer messaging in one journey. Validate the test method against the platform and payment provider. If a real transaction is necessary, authorised staff use a limited, approved arrangement. Distinguish test outcomes from real trading reports.
Illustrative cases include either side of a free-shipping threshold, an unsupported delivery region, an unavailable variant, a discount condition, failed payment and cancellation. Add partial refunds or specialist delivery where relevant. Record the expected result before running each case. Duplicate orders from one payment or messages sent to the wrong recipient are not defects that a visual design review alone can detect. The test set should reflect your actual operation rather than a generic purchase.
Product and basket
Test variant, quantity and discount behaviour. Record whether important price and delivery explanations remain visible on mobile.
Payment and staff view
Distinguish successful, failed and uncertain outcomes. Check that the order record agrees with the payment provider’s result.
Delivery and communication
Validate the shipping option, staff action and customer message. Include cancellation or return messaging where the operation requires it.
Assign measurement, domain and rollback ownership
Retest the measurement implementation when the theme, applications or payment journey change. Validate events such as product consideration, basket actions and purchase with the necessary fields. Check whether one order is counted twice and whether tests can be identified. Do not send personal form or order values into analytics events.
Identify the account owner for DNS and platform changes, the release window and the person authorised to decide. A rollback plan is not simply reopening the old site: consider orders taken by the new store. Returning after data has changed can create conflicting stock and transaction records. Write the conditions for rollback, the records that must be preserved and the communication approach before publication. Include dependencies managed by another supplier so that access is not discovered to be missing during release.
Event evidence
Match event names, product identifiers and order states to test records. Check permission choices and duplicate counting separately.
Release authority
Identify domain, DNS and platform-account owners. The person approving the business release need not be the person making the technical change.
Rollback decision
Record the critical-error trigger, data-preservation method and decision owner. Do not exclude orders received after the transition.
Keep the checklist active after launch
Connected systems such as CRM and store integrations need observation with new orders too. Initial checks cover actual links, payment outcomes, notifications, shipping and error records. Before interpreting a traffic change, verify the period, channel and measurement definition. A sudden drop is not always an indexing loss; a tag or reporting rule may have changed.
At closure, hand over completed items, remaining tasks and monitoring owners together. Improve evidence if a screenshot does not explain what was tested. The list is platform-neutral, but subscriptions, dealer accounts or international selling can require additional scenarios. Share the old and new platforms, intended changes and most important customer journey for an initial discussion. Missing items can be scoped without sending sensitive account information. A useful completion record explains both what was verified and what is still uncertain.
Get the checklist and discuss your scope
Your email and phone are used for this request. This does not subscribe you to a newsletter.
BEFORE YOU DECIDE
Frequently asked questions
Does the checklist guarantee no traffic loss?
No. It makes errors and ownership visible but cannot guarantee search-processing time or user behaviour. Traffic, indexing and measurement changes should be evaluated separately after release, with the underlying evidence retained.
Is matching the product count enough to accept migration?
No. Validate variants, imagery, custom fields and stock behaviour in representative records. Information outside the transfer scope may require an alternative presentation and explicit approval from the business owner.
Will customer passwords move with the accounts?
That depends on platform data and security models and must not be assumed. Define the supported account-access method, customer communication and test arrangement separately.
Who should approve the release?
Assign an authorised business approver. Technical, product and operations owners provide test evidence. Record how critical gaps will be resolved or explicitly deferred instead of treating the checklist as automatic permission to publish.
Is returning to the old store an easy backup plan?
Not necessarily. After the new installation receives orders, rollback can create stock and record conflicts. Design the data-preservation approach, decision conditions and responsibilities before launch.
Can we use the list with our current agency?
Yes. Share the tasks with named owners and evidence. Explain not-applicable items, define expected outcomes for incomplete work and repeat the same scenario after the correction.
LET’S DEFINE THE SCOPE
Review the unresolved items in your migration
Share the old and new platforms, the intended change and your most important checklist gap. We can scope the first task from the evidence.
Discuss migration scope