E-Commerce Migration Testing: Prelaunch and Postlaunch Checklist

An e-commerce migration is not complete when the new website looks right. It is complete only when products, customers, orders, URLs, redirects, checkout, payments, shipping, tax, analytics, SEO signals, admin workflows, and support processes work in production with real constraints.

Most migration damage happens in the gaps between teams. Developers test pages. Designers test layouts. Marketing checks a few headlines. Finance assumes payment reporting will match. Operations assumes stock and shipping rules moved correctly. SEO assumes redirects exist. Analytics assumes purchase events fire once. Customers then find the missing edge cases on launch day.

This guide gives you a practical testing system for e-commerce migrations: what to verify before launch, what to monitor after launch, how to protect SEO and revenue data, and how to decide whether a migrated store is ready to receive traffic. Use it when moving from WooCommerce to Shopify, Shopify to WooCommerce, a hosted builder to a custom site, HTTP to HTTPS, one domain to another, an old CMS to a new CMS, or a legacy custom store to a modern stack.

If the platform choice is not final, start with the E-Commerce Platform Selection Guide. If payment work is part of the migration, use the Payment Gateway Integration Guide for Sri Lankan Websites. For checkout-specific defects, pair this article with the E-Commerce Checkout Optimization Guide.

Key Takeaways

• Test migration as a business system, not as a visual website refresh.
• Freeze and reconcile source data before moving products, customers, orders, coupons, and content.
• Build a URL mapping before launch and test redirects in bulk.
• Follow Google Search Central guidance: prepare the new site, map URLs, redirect old URLs, monitor old and new URLs, submit the new sitemap, and expect temporary ranking fluctuation.
• Remove development noindex and robots blocks before launch, but only after the live site is ready.
• Validate checkout, payment callbacks, refunds, shipping rates, tax, stock, emails, admin workflows, and fulfilment.
• Confirm GA4 e-commerce events, transaction IDs, currency, item data, and revenue reconciliation.
• Run small live payment and order tests before sending campaign traffic.
• Monitor logs, Search Console, analytics, orders, payment failures, crawl errors, and support tickets after launch.
• Keep a rollback and incident plan, because the first 72 hours matter.

Table of Contents

1. What Counts as an E-Commerce Migration

2. Migration Risks to Plan For

3. Build the Test Plan

4. Prelaunch Data Testing

5. SEO and URL Migration Testing

6. Content and Merchandising Testing

7. Checkout, Payment and Order Testing

8. Shipping, Tax and Inventory Testing

9. Analytics and Revenue Validation

10. Performance, Accessibility and Security Testing

11. Launch-Day Checklist

12. Postlaunch Monitoring

13. Rollback and Incident Response

14. Migration Test Matrix Template

15. 100-Point Migration Readiness Score

16. Frequently Asked Questions

What Counts as an E-Commerce Migration

An e-commerce migration is any change that moves an online store from one meaningful state to another while customers, search engines, payment systems, and staff still expect continuity.

Common migrations include:

• Domain change
• HTTP to HTTPS
• Platform change such as WooCommerce to Shopify
• CMS change
• Theme or storefront rebuild
• Headless commerce launch
• Product URL structure change
• Category taxonomy change
• Checkout replacement
• Payment gateway replacement
• Hosting change
• Multi-language or multi-currency launch
• ERP, inventory, courier, or order-management integration replacement
• Analytics stack migration

Some migrations change URLs. Some do not. Some change checkout but not content. Some change data but not design. Testing must match the actual change, not the project name.

Migration is not only SEO

SEO is important, but an e-commerce migration can fail even if rankings survive. A store can preserve traffic and still lose money if:

• Payment callbacks fail.
• Stock is oversold.
• Product variants are mismatched.
• Tax is wrong.
• Coupon rules changed.
• Order emails do not send.
• Finance cannot reconcile settlements.
• Customer accounts are broken.
• Analytics double-counts purchases.
• Staff cannot fulfil orders.

Migration testing protects the whole commercial system.

Migration Risks to Plan For

Start by listing risks before writing test cases.

Main risk categories

Each risk should map to a test, an owner, and evidence.

Decide the launch risk threshold

Not every defect blocks launch. A typo on a low-priority page is different from broken checkout. Define severity levels:

Write this before launch pressure arrives.

Build the Test Plan

A migration test plan turns vague confidence into evidence.

Test plan fields

Use real product examples. A store with variants, sale pricing, size charts, bundles, and out-of-stock products cannot be tested with one simple product.

Define migration samples

Create test samples for:

• Top traffic products
• Top revenue products
• Products with variants
• Products with sale pricing
• Products with multiple images
• Products with downloadable files
• Products with custom fields
• Products with reviews
• Products with stock constraints
• Out-of-stock products
• Discontinued products
• Top categories
• Blog posts or guides with backlinks
• Search landing pages
• Customer accounts
• Historical orders
• Coupons and gift cards

The sample should include business-critical and technically awkward examples. Easy products prove very little.

Prelaunch Data Testing

Data migration should be reconciled, not eyeballed.

Product data

Test:

• Product count by status
• SKU count
• Variant count
• Product titles
• Slugs and handles
• Descriptions
• Short descriptions
• Prices
• Sale prices
• Compare-at prices
• Cost data if migrated
• Currency
• Tax class
• Stock quantity
• Stock status
• Backorder settings
• Weight and dimensions
• Product type
• Brand or vendor
• Category assignment
• Tags and attributes
• Variant options
• Product images
• Image alt text
• Download files
• Related products
• Cross-sells and upsells
• Reviews and ratings
• Schema-relevant fields

Run both aggregate checks and sample checks.

Aggregate example:

`text

Source active products: 2,148

Target active products: 2,148

Source variant SKUs: 6,921

Target variant SKUs: 6,921

Products missing images: 0 critical, 12 low-priority archived

`

Sample example:

`text

SKU: SHIRT-BLK-M

Source: title, price, sale price, stock, image count, category, URL

Target: same values confirmed

Evidence: source export row, target admin screenshot, live preview URL

`

Customer and order data

Depending on scope and privacy rules, test:

• Customer account count
• Email address integrity
• Consent status
• Saved addresses
• Account activation or password reset route
• Historical order count
• Order numbers
• Order statuses
• Payment statuses
• Fulfilment statuses
• Refund records
• Customer notes
• Subscription status if applicable
• Gift card balances
• Loyalty points where applicable

Do not migrate sensitive data casually. If passwords cannot be migrated securely, plan account activation or password reset messaging.

Coupons, gift cards and promotions

Test:

• Coupon codes
• Expiry dates
• Usage limits
• Product/category restrictions
• Minimum order values
• Free shipping rules
• Customer restrictions
• Gift card balance
• Store credit
• Automatic discounts

Coupons often behave differently across platforms. Do not assume the exported rule means the same thing after import.

SEO and URL Migration Testing

SEO migration testing protects discovery and revenue from organic search.

Google Search Central's site move guidance recommends preparing and thoroughly testing the new site, creating URL mappings, redirecting old URLs to new URLs, monitoring both old and new URLs, using Search Console, submitting the new sitemap, and keeping redirects for as long as possible, generally at least one year. It also warns that temporary ranking fluctuation is normal while Google recrawls and reindexes moved URLs.

URL mapping

Create a URL mapping table before launch:

Include:

• Top organic landing pages
• Top revenue pages
• Pages with backlinks
• Paid ad landing pages
• Email campaign URLs
• Marketplace profile links
• Social profile links
• Old XML sitemap URLs
• Internal search landing pages if indexable
• Image and PDF URLs that receive traffic

Redirect testing

Test redirects in bulk:

• Old URL returns 301 or appropriate permanent redirect.
• Destination is the most relevant new page.
• Redirect does not chain through multiple hops.
• Redirect does not loop.
• HTTP redirects to HTTPS.
• www/non-www canonical host resolves correctly.
• Trailing slash rules are consistent.
• Query parameters are handled intentionally.
• Discontinued pages return 404 or 410 where no relevant replacement exists.
• Old sitemap URLs are covered.

Avoid redirecting many unrelated old URLs to the homepage. Google specifically warns that irrelevant redirects can confuse users and may be treated like soft 404s.

Indexability testing

Before launch, check:

• robots.txt on production
• noindex meta tags
• X-Robots-Tag headers
• canonical tags
• sitemap URLs
• hreflang if applicable
• pagination
• faceted navigation rules
• internal links
• structured data
• product availability markup
• category and product title tags
• meta descriptions
• Open Graph image behavior

Development sites are often blocked by robots.txt or noindex. That is fine during staging, but you need a launch checklist item to remove or change those rules at the correct moment.

Search Console preparation

Verify old and new properties where relevant. Google recommends verifying variants such as www/non-www and HTTP/HTTPS where applicable. For domain moves, use the Change of Address tool for the old site after redirects are active. HTTP to HTTPS migrations do not use the Change of Address tool.

Submit the new sitemap after launch and monitor indexing, coverage, redirects, crawl errors, and performance.

Content and Merchandising Testing

Content migration is not only text import.

Product pages

Check:

• Title and H1
• Variant selector
• Price display
• Sale badge
• Availability
• Images and zoom
• Video
• Size chart
• Delivery estimate
• Return information
• Reviews
• Related products
• Product schema
• Breadcrumb
• Add-to-cart button
• Out-of-stock handling
• Internal links

Use the Product Page SEO Guide as the quality bar for migrated product templates.

Category pages

Check:

• Category title
• Product grid
• Sort options
• Filters
• Facet URL rules
• Pagination or load-more behavior
• Category copy
• Internal links
• Canonical tags
• Empty category behavior
• Product count
• Mobile usability

Use the E-Commerce Category Page SEO Guide for faceted navigation and cannibalization checks.

Static content

Check:

• Home page
• About page
• Contact page
• Terms
• Privacy Policy
• Return and refund policy
• Shipping policy
• Size guides
• Buying guides
• Blog posts
• Landing pages
• PDF downloads

Policies matter for gateway approval, customer trust, and support. Do not treat them as footer decoration.

Checkout, Payment and Order Testing

Checkout testing must be end-to-end.

Checkout scenarios

Test:

• Guest checkout
• Returning customer checkout
• Account creation after purchase
• Password reset during checkout
• Cart preservation after login
• Billing same as shipping
• Billing different from shipping
• Local address
• International address if supported
• Address with apartment or unit
• Phone-number validation
• Discount code valid
• Discount code invalid
• Free shipping threshold
• Out-of-stock during checkout
• Quantity changed in cart
• Tax calculation
• Delivery method selection
• Terms acceptance where required

Payment scenarios

Test:

• Successful payment
• Failed payment
• Customer cancellation
• Gateway timeout
• 3D Secure or bank authentication
• Wallet or local method if supported
• Notify/webhook callback
• Duplicate callback
• Return without callback
• Callback without return
• Wrong amount rejection
• Wrong currency rejection
• Refund
• Partial refund if supported
• Payment dashboard reconciliation

The Payment Gateway Integration Guide for Sri Lankan Websites covers these states in more detail.

Order workflow

After payment, test:

• Order created once
• Order status correct
• Payment status correct
• Stock reduced correctly
• Confirmation page shown
• Customer email sent
• Admin email sent
• Invoice or receipt correct
• Fulfilment queue updated
• Courier integration triggered if applicable
• Refund updates status
• Cancelled payment does not create paid order
• Failed payment does not fire fulfilment

A migration has failed if the customer pays and the business cannot see, fulfil, or reconcile the order.

Shipping, Tax and Inventory Testing

Shipping, tax, and inventory are common migration traps because their rules are often embedded in platform settings rather than visible page content.

Shipping

Test:

• Shipping zones
• Local delivery
• Islandwide delivery
• International delivery if offered
• Pickup
• Free shipping
• Weight-based rates
• Order-value-based rates
• Product exclusions
• Bulky item surcharge
• Courier API rates
• Delivery cutoff times
• Unavailable address behavior
• Shipping tax if applicable

Tax

Test:

• Taxable products
• Non-taxable products
• Tax-inclusive display
• Tax-exclusive display
• Invoice tax line
• Shipping tax
• Cross-border tax rules if applicable
• Rounding
• Discounts before or after tax as required

Get finance approval. Developers should not guess tax behavior.

Inventory

Test:

• Stock quantity after import
• Variant stock
• Multi-location stock
• Backorders
• Low-stock alerts
• Reservations during checkout
• Stock reduction after payment
• Stock restoration after cancellation or refund if configured
• ERP or POS sync
• Marketplace sync if used

For multichannel sellers, connect this with the Cross-Listing Inventory Management Guide.

Analytics and Revenue Validation

Migration is a dangerous time for analytics because URLs, data layers, consent tools, checkout pages, and confirmation pages often change together.

GA4 recommends e-commerce events such as view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, refund, add_to_cart, remove_from_cart, view_item, and view_item_list for online sales. Google's GA4 e-commerce guidance also recommends using debug mode for troubleshooting, setting currency when sending value, and sending available e-commerce parameters so reports populate properly.

Validate event coverage

Test:

• view_item
• view_item_list
• select_item
• add_to_cart
• remove_from_cart
• view_cart
• begin_checkout
• add_shipping_info
• add_payment_info
• purchase
• refund
• search if site search matters

Validate purchase quality

Confirm:

• purchase fires only once per order
• transaction_id is unique
• value matches order revenue logic
• currency is set
• tax and shipping are correct
• coupon is captured where applicable
• items array includes product IDs, names, categories, variants, prices, and quantities
• failed payments do not fire purchase
• cancelled payments do not fire purchase
• refunds map back to transactions where possible
• consent behavior is understood
• ad platforms receive the intended conversions

Do not trust a migration until analytics purchases reconcile reasonably with platform orders and payment records.

Performance, Accessibility and Security Testing

Migration can improve technology and still make the user experience worse.

Performance

Test:

• Home page
• Top category page
• Top product page
• Cart
• Checkout
• Search results
• Blog article
• Image-heavy page

Look at real user conditions, not only a developer machine. Check image sizes, third-party scripts, theme code, tag manager changes, app/plugin bloat, server response time, caching, and checkout dependencies.

Accessibility

Test:

• Keyboard navigation
• Focus states
• Form labels
• Error messages
• Color contrast
• Screen reader names
• Touch targets
• Zoom and reflow
• Cart and checkout completion
• Payment authentication support

Accessible migration testing is especially important when changing themes or checkout components.

Security

Test:

• HTTPS
• Mixed content
• Admin access
• User roles
• Password reset
• Customer account access
• Payment secrets
• Webhook signature validation
• Plugin/app permissions
• Backup and restore
• Staging access restrictions
• No staging URLs indexed

Security testing should include handover: who owns credentials, recovery emails, provider accounts, and emergency access?

Launch-Day Checklist

Launch day should be boring because most decisions were made earlier.

Before DNS or traffic switch

Confirm:

• Final source data export completed
• Content freeze communicated
• Redirect rules deployed
• Production robots.txt ready
• noindex removed where appropriate
• Canonicals point to production URLs
• Sitemap generated
• Search Console properties verified
• Analytics tags live
• Payment live credentials configured
• Test live order passed
• Refund test passed if feasible
• Email deliverability checked
• Backup completed
• Rollback decision point agreed
• Support team briefed
• Campaign traffic paused or scheduled carefully

Immediately after launch

Check:

• Homepage loads
• Top product pages load
• Top category pages load
• Old URLs redirect
• robots.txt is correct
• Sitemap accessible
• Checkout works
• Payment works
• Confirmation email sends
• Admin order appears
• Analytics realtime/debug events appear
• Search Console sitemap submitted
• Server logs normal
• Error monitoring active

Record the exact launch time. It helps interpret analytics, logs, and Search Console changes later.

Postlaunch Monitoring

Postlaunch testing is not optional. Some issues appear only with real customers, real banks, real traffic, real crawlers, and real fulfilment work.

First 24 hours

Monitor:

• Orders per hour versus normal baseline
• Checkout failures
• Payment failures
• Server errors
• JavaScript errors
• Search Console crawl activity where available
• 404 logs
• Redirect logs
• Slow pages
• Support tickets
• Customer emails
• Stock sync
• Shipping API errors
• Analytics purchase count
• Payment dashboard transaction count

First 7 days

Review:

• Organic landing page traffic
• Top old URL redirect coverage
• Indexing and sitemap reports
• Product feed errors
• Paid campaign landing pages
• Email campaign links
• Conversion rate by device
• Payment method performance
• Refund and cancellation rate
• Support themes
• Internal search terms
• Zero-result searches

First 30 days

Audit:

• Search Console performance trend
• Indexed URL count
• Redirect dependency
• Top backlinks updated where possible
• Broken internal links
• Duplicate title or canonical issues
• Revenue attribution
• Product feed health
• Customer-account issues
• Admin workflow issues
• App/plugin update issues

Google notes that search fluctuations are normal during significant site moves while pages are recrawled and reindexed. Use baseline, logs, and Search Console data rather than panicking after one noisy day.

Rollback and Incident Response

A rollback plan is not pessimism. It is responsible launch planning.

Decide rollback triggers

Rollback or emergency intervention may be needed if:

• Checkout cannot accept payment.
• Paid orders are not created.
• Payment gateway returns inconsistent status.
• Majority of old URLs return 404.
• Production site is blocked from crawling.
• Customer data is exposed.
• Admin cannot access orders.
• Shipping or tax rules are materially wrong.
• Revenue tracking is unusable and campaigns are active.
• Severe performance outage affects customers.

Prepare response roles

Define:

• Launch commander
• Developer owner
• SEO owner
• Analytics owner
• Payment owner
• Operations owner
• Support owner
• Final decision maker

During an incident, do not let ten people make conflicting changes. Communicate status, assign one owner per problem, record changes, and retest after each fix.

Migration Test Matrix Template

Use this simplified template and expand it for your store.

The test matrix should live in the project documentation, not in someone's chat history.

100-Point Migration Readiness Score

Use this score before launch approval.

Scoring guidance:

• 90-100: Ready for launch with normal monitoring.
• 75-89: Launch may be possible after resolving named high-risk items.
• 60-74: Delay launch unless the remaining risks are explicitly accepted.
• 40-59: Migration is not ready for customers or search engines.
• Below 40: Rebuild the migration plan before attempting launch.

Frequently Asked Questions

What is e-commerce migration testing?

E-commerce migration testing is the process of verifying that a moved or rebuilt online store preserves commercial function. It checks products, URLs, redirects, SEO, checkout, payment, shipping, tax, inventory, analytics, emails, admin workflows, and postlaunch monitoring.

When should migration testing start?

Start before development finishes. The URL map, data-reconciliation plan, payment test cases, analytics requirements, and launch criteria should be defined during planning. Testing only at the end usually reveals expensive surprises.

How many old URLs should be tested?

Test all URLs if practical. At minimum, test top organic landing pages, top revenue pages, pages with backlinks, old sitemap URLs, paid landing pages, important product and category URLs, and a representative sample of long-tail pages. For larger stores, run bulk crawls.

Should every old URL redirect?

No. Valuable pages should redirect to the most relevant new page. Deleted content with no useful replacement can return 404 or 410. Avoid redirecting unrelated pages to the homepage because that hurts users and can look like a soft 404.

How long should redirects stay live?

Google recommends keeping redirects for as long as possible, generally at least one year, and from a user perspective keeping them indefinitely can be useful. Update internal links and important external links to reduce redirect dependency.

Should we launch if analytics is not ready?

If analytics purchase tracking is completely unreliable and campaigns or SEO decisions depend on it, delay or limit launch. At minimum, orders, payments, transaction IDs, and revenue should reconcile well enough for the business to understand performance.

What is the biggest migration mistake?

The biggest mistake is testing the new website visually while ignoring old URLs, production payment behavior, order workflows, data reconciliation, and postlaunch monitoring. A migration must be tested as an operating store.

Do rankings always drop after migration?

Not always, but temporary fluctuation is normal during significant site moves while search engines recrawl and reindex URLs. Careful URL mapping, relevant redirects, clean indexability, sitemaps, internal links, and monitoring reduce avoidable damage.

Do we need live payment testing?

Yes, when the provider and business process allow it. Sandbox testing is necessary, but live small-value testing confirms production credentials, payment result handling, order creation, email, gateway dashboard records, settlement references, and refund workflow.

Who should approve migration launch?

Launch approval should include business, development, SEO, analytics, payment/finance, operations, and support owners. A single visual sign-off is not enough for an e-commerce migration.