A WordPress to Next.js migration for WooCommerce is a frontend migration before it is a technology upgrade. The business usually wants faster pages, a cleaner mobile experience and more control over the storefront, while the team still needs WooCommerce products, orders, payments, taxes and fulfillment to keep working.
This checklist is different from a pure SEO migration checklist. SEO deserves its own URL, metadata and redirect plan. The checklist below focuses on the operational storefront move: what to inventory, what to rebuild, how to keep checkout safe, how to test staging orders and how to switch traffic without surprising customers or staff.
Discovery and inventory
1. Inventory templates, not only pages
List every customer-facing template the current WordPress theme controls: homepage, category, product, search, cart, checkout, account, blog, landing pages, brand pages, vendor pages and any custom post types. A Next.js storefront needs templates and data rules, not just a visual copy of several screenshots.
Verify by crawling the site, reviewing theme files or builder templates, checking menus and asking the store team which pages customers actually use. Mark each template as rebuild, keep in WordPress, redirect or remove.
2. Export plugin and integration lists
Write down active plugins, custom snippets, theme functions and external services. Group them as admin-side, frontend-side, checkout-side, tracking or back-office integration. This prevents the common mistake of discovering late that a filter, badge, subscription rule or tax tool came from a plugin the new storefront does not render.
Verify by opening product, category, cart, checkout, account and thank-you pages and noting which plugin output appears. Then confirm whether each plugin has API access, webhook behavior or only WordPress-theme output.
3. Define the WooCommerce role
Decide what WooCommerce remains responsible for. In many migrations it should stay the system of record for products, stock, orders, coupons, customer accounts, taxes, shipping and refunds. The clearer this boundary is, the fewer surprises appear during development.
Verify by writing a responsibility map: WooCommerce owns these tasks, Next.js owns these templates, external services own these events. Share it with developers, marketers and operations staff.
4. Choose a checkout scheme early
Checkout is the highest-risk part of a WooCommerce migration. Choose whether checkout remains native WooCommerce, becomes hybrid with a storefront cart handoff or is rebuilt in Next.js. Do this before estimating timelines because payment, tax, shipping, subscriptions and fraud checks depend on it.
Verify by listing payment gateways, wallet methods, 3D Secure flows, local payment methods, coupons, shipping rules, taxes, invoices, refunds and failed-payment scenarios. If the list is complex, native or hybrid checkout is usually safer for the first launch.
Data and storefront architecture
5. Map product data fields
Products are more than names and prices. Map images, galleries, variations, attributes, stock status, sale prices, grouped products, bundles, subscriptions, downloads, reviews, brand data, dimensions and custom fields. The new frontend must know which fields are required on each template.
Verify by selecting sample products: simple, variable, sale, out-of-stock, high-review, bundled and custom-field-heavy. Build staging pages for all of them before assuming the product template is complete.
6. Decide API strategy
Next.js needs product, category, cart and content data from WordPress/WooCommerce. That may come through WooCommerce REST API, Store API, WPGraphQL, custom endpoints or a combination. The choice affects performance, cache rules and developer effort.
Verify by testing API responses for real catalog sizes, not only one product. Check pagination, filtering, variation data, authentication, rate limits, cache headers and error handling.
7. Plan cache and freshness rules
Not every page needs the same freshness. A buying guide can be static. A category may update every few minutes. A cart must be dynamic. Stock and price may need more careful rules than product descriptions. Next.js lets developers choose, but the business must define acceptable freshness.
Verify by writing rules per template: static, server-rendered, regenerated, client-fetched or dynamic. Include who triggers updates when products, prices, stock or category assignments change.
8. Rebuild navigation and search deliberately
Menus, breadcrumbs, search, filters and related products are core shopping paths. Do not treat them as decorations. They determine whether customers can reach products quickly and whether internal links continue supporting important categories.
Verify by testing common journeys: homepage to category, category to filtered result, search to product, product to related product, product to cart and cart to checkout. Run the same journeys on mobile.
Staging and QA
9. Build a staging order test plan
A storefront can look finished while ordering is broken. Create test cases for simple products, variable products, coupons, free shipping thresholds, paid shipping, taxes, guest checkout, logged-in checkout, failed payment, wallet payment and refund flow.
Verify by placing real test orders in staging and checking WooCommerce admin, customer emails, order notes, stock changes, analytics events and payment gateway status. Record every pass or failure.
10. Test cart state and handoff
If the Next.js storefront has its own cart or passes customers to WooCommerce checkout, cart state must be reliable. Products, variations, quantities, coupons and shipping assumptions should survive the handoff. Customers should not see a different total after clicking checkout unless the reason is clear.
Verify by adding, removing and changing products across devices and sessions. Test expired carts, unavailable products and changed prices. Confirm the handoff does not create duplicate carts or lose variation data.
11. Validate analytics and consent
A migration can break measurement even if orders continue. Product views, add-to-cart events, checkout start, purchase events, ad pixels, consent behavior and server-side tracking must be rechecked because the frontend implementation changes.
Verify with debug tools for analytics and ad platforms. Compare staging event names and parameters with the previous setup, especially product IDs, order value, currency and consent state.
12. Run accessibility and mobile QA
Speed is not useful if the storefront is hard to use. Check keyboard navigation, focus states, form labels, error messages, color contrast, tap targets, sticky bars and mobile drawers. Product filters and checkout forms deserve special attention.
Verify with automated checks and manual testing on real mobile sizes. Include at least one low-end or mid-range mobile profile, not only a large desktop monitor.
Launch preparation
13. Prepare the domain and DNS switch
A frontend migration often changes hosting and deployment. Confirm DNS, SSL, CDN, redirects, environment variables, API credentials and fallback behavior before the switch. Avoid making the first production test happen after customers arrive.
Verify with a launch runbook: who changes DNS, who watches logs, who tests checkout, who monitors analytics and who can revert. Lower TTL ahead of time if your infrastructure plan requires it.
14. Plan hypercare after launch
The first days after launch are part of the migration, not an afterthought. Staff may notice order issues, customers may report browser problems, and search engines may crawl new routes. Assign owners for operations, frontend bugs, checkout, analytics and SEO.
Verify by scheduling daily checks for orders, failed payments, 404s, API errors, Core Web Vitals signals, analytics purchases, customer support tickets and Search Console coverage.
15. Keep a rollback path
Even a well-tested migration needs a fallback. Rollback does not mean the project failed; it means the business has a safety plan if checkout, routing or API stability breaks in production. Keep the previous storefront deployable for a short window and document what data may need reconciliation after rollback.
Verify by defining rollback triggers before launch: payment failures above a threshold, major product data mismatch, sitewide routing errors, analytics outage or API instability. Make sure decision-makers know who can approve rollback.
What should not be mixed up with this checklist
This checklist does not replace a detailed SEO migration checklist. SEO needs URL exports, metadata parity, structured data, sitemap rules, redirects, canonical tags and Search Console monitoring. A WordPress to Next.js migration needs those, but it also needs operational checks around cart, checkout, data, plugins, analytics and launch support.
The safest project treats migration as a controlled business change. The new storefront should be faster and cleaner, but the customer must still be able to find products, trust the page, add the right item to cart and complete payment while the operations team continues using WooCommerce without disruption.