This WordPress to Next.js migration checklist is for the weeks before launch and the launch itself, when a WooCommerce store's frontend is about to move to Next.js. Each item names a check and what passing looks like. What breaks on launch day is whatever rendered through the theme: plugin output, theme-level checkout tweaks, tracking tags. The fifteen checks below exist to find those first.
It assumes the scope is already decided. What moves, what stays and what it costs are covered on the WordPress to Next.js migration service page, and the order the work runs in is the phase-by-phase WooCommerce to Next.js guide. URLs, metadata and redirects have their own SEO migration checklist.
Inventory to close before the build freezes
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 a visual copy of a few screenshots.
Verify by crawling the site, reviewing theme files or builder templates, checking menus and asking the store team which pages customers actually use. Passing means every template carries one mark: 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.
Then open product, category, cart, checkout, account and thank-you pages and note which plugin output appears on each. For every plugin on the frontend list, record whether it has API access, sends webhooks or only prints into the theme.
3. Confirm the build decisions are on paper
Three answers have to exist in writing before staging can be checked against anything: which checkout scheme the first launch uses, which API each template reads from, and how fresh price and stock must be on each template. A checklist cannot make those choices; it can only test them.
Passing looks like a one-page responsibility map that developers, marketing and operations staff have all read: WooCommerce owns these tasks, Next.js owns these templates, external services own these events. If any line is still open, stop and settle it in the migration phases before going further down this list.
4. List every way a customer can pay
Write out payment gateways, wallet methods such as Apple Pay and Google Pay, 3D Secure flows, local payment methods, coupons, shipping rules, taxes, invoices, refunds and failed-payment scenarios. Each line becomes at least one staging order in step 9, so a missing line is a missing test.
A long list is also a warning. If it runs to several gateways, subscriptions and region-specific tax, the first launch should keep native or hybrid checkout, whatever the original plan said.
Staging checks on data and rendering
5. Build a sample product set
Products are more than names and prices. Pick sample products that cover images, galleries, variations, attributes, stock status, sale prices, grouped products, bundles, subscriptions, downloads, reviews, brand data, dimensions and custom fields: one simple, one variable, one on sale, one out of stock, one with many reviews, one bundle and one heavy on custom fields.
Build each as a staging page and compare it against the live theme field by field. The product template is complete when all seven render correctly, not when the first one does.
6. Test the API at full catalog size
Pull every category through the endpoint the storefront actually uses, at the real product count. The WooCommerce REST API and the Store API both cap per_page at 100, and WPGraphQL defaults to the same ceiling, so a 4,000-product catalog takes at least 40 requests to list in full. A build tested against one product page in development will quietly show the first hundred.
Check pagination, variation data, authentication, rate limits set by your host or firewall, cache headers, and what the storefront shows when the API returns an error instead of data.
7. Change a price and time it
Edit one product's price and stock in WooCommerce admin and time how long each template takes to show the change: product page, category grid, search results and cart. Passing means the cart and checkout show the new price at once, and the cached templates catch up inside the window the business agreed in step 3. Static rendering is unsafe on any template that shows price or stock without a live check.
Repeat it with a stock change caused by a staging order rather than an admin edit, because that change takes a different path through WooCommerce and is the one revalidation most often misses. If the storefront revalidates through WooCommerce webhooks, look for successful deliveries under WooCommerce → Status → Logs.
8. Walk the shopping journeys
Menus, breadcrumbs, search, filters and related products are core shopping paths. They decide whether customers reach products quickly and whether internal links keep supporting important categories, so they get tested as journeys rather than as components.
Walk homepage to category, category to filtered result, search to product, product to related product, product to cart and cart to checkout. Then run all six again on a phone.
Staging checks on ordering
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: eleven scenarios, plus each payment method from step 4.
Verify by placing the orders in staging and checking WooCommerce admin, customer emails, order notes, stock changes, analytics events and payment gateway status. Record every pass or failure. Before launch, place one order on the production gateway in live mode and refund it, because test mode cannot prove that live keys, the live webhook endpoint and payout settings are right.
10. Test cart state and handoff
Whether the Next.js storefront keeps its own cart or hands customers to WooCommerce checkout, cart state must survive the trip. Products, variations, quantities, coupons and shipping assumptions should all arrive intact, and customers should not see a different total after clicking checkout unless the reason is shown.
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.
Use GA4 DebugView and each ad platform's own event debugger, then 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, sticky bars and mobile drawers, and hold tap targets to at least 24 by 24 CSS pixels, the WCAG 2.2 AA minimum. Product filters and checkout forms deserve special attention.
Combine an automated scan, such as the Lighthouse accessibility audit or axe DevTools, with manual testing on real mobile sizes. Include at least one low-end or mid-range phone profile, not only a large desktop monitor.
Launch-day checks
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. The first production test should not 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. If the switch involves DNS, lower the TTL (how long resolvers cache the old address) ahead of time, by at least the length of the current TTL; the no-downtime cutover page has the timings.
14. Plan hypercare after launch
The first days after launch are part of the migration, not an afterthought. Staff will find order issues before your monitoring does, customers will report browser problems you cannot reproduce, and crawlers will hit the new routes within hours. Assign named owners for operations, frontend bugs, checkout, analytics and SEO before launch day, not during it.
Schedule daily checks for orders, failed payments, 404s, API errors, Core Web Vitals signals, analytics purchases, customer support tickets and Search Console coverage.
15. Write the rollback triggers down
Keep the previous storefront deployable for a short window, and decide before launch what would make you use it: payment failures above a set threshold, a major product data mismatch, sitewide routing errors, an analytics outage or API instability. A trigger agreed on a calm Tuesday is easier to act on than one argued over during an incident.
Passing means one named person can approve a rollback and everyone on the launch call knows who it is. How the rollback itself works at each stage is in the migration guide.
What this checklist leaves to the SEO migration checklist
URL exports, metadata parity, structured data, sitemap rules, redirects, canonical tags and Search Console monitoring are SEO work, and they have their own checklist. A WordPress to Next.js migration needs both lists. The SEO one protects how customers find the store; this one protects whether they can buy once they arrive.
The customer still has to find products, add the right item and pay while operations keep using WooCommerce. If nobody can say who owns checkout, analytics and rollback on launch day, the storefront is not ready to switch, however fast it looks on staging.