WooCommerce to Next.js migration, step by step

The audit produces three lists, and the plugin list is the one that sets the size of the job. Split every active plugin into two columns. Backend plugins — tax, shipping, subscriptions, accounting connectors, order management, reporting — carry on untouched, because they operate behind the API. Frontend plugins render into a theme that will no longer exist: filters, sliders, review widgets, popups, page builders and anything else injecting markup needs an API-based replacement, a rebuild as a component, or a deliberate decision to drop it. The second list is URLs. Export every indexed URL and your top pages by clicks from Search Console, because the aim is for that structure not to change at all. The third is field data by template, and one number in it can end the project: if Time to First Byte is poor on uncached category and product pages, the server is the bottleneck and a new frontend will not fix it, which is the first of the reasons the migration is not worth it for some stores. Nothing on the live store changes in this phase.

The Next.js application is built against a staging copy of WordPress, with payment gateways in test mode, while the live store keeps selling on its theme. Products, variations, categories, attributes, images, prices and stock are read through the WooCommerce REST API or WPGraphQL. There is no export, no import and no mapping exercise, which removes the data risk that makes replatforming projects overrun. Each template reproduces what the old one emitted for search: titles, meta descriptions, canonical rules, structured data, sitemap entries and pagination. Reinvent none of them. Customer accounts are untouched as well. They are WordPress users, their passwords stay hashed in the same database, and nobody is asked to reset anything — the opposite of a Shopify move, where password hashes cannot be imported and existing customers have to set up their login again. Staging is also where most verification happens, and the pre-launch migration checklist lists the items, from API page limits to test orders.

This is the first change customers could notice, and done properly they will not. The Next.js application takes the domain, and every route it does not render yet is proxied back to WordPress; a fallback rewrite in next.config is the standard way to do it. On day one that is every route, so the store looks exactly as it did, while WordPress moves to an origin hostname shoppers never see. Cart, checkout and My Account are still WooCommerce pages, now served through the proxy on the same domain, which is why sessions and logins carry on without anyone signing in again. Switch in a quiet window with DNS TTL lowered in advance (the cutover without downtime page has the timings). Then confirm, before moving on, that order emails, payment webhooks and analytics events all still arrive through the new front door. Webhooks are the ones that fail quietly.

A template moves when its Next.js route goes live and the proxy stops sending that path to WordPress. The usual order is category, then product, then cart. Category pages carry the heaviest filter and grid scripts and do not touch money, so they make the safest first proof; product pages follow once that pattern holds. The cart goes last, rebuilt on the WooCommerce Store API, and because the Store API is called through the same domain, the cart lives in the ordinary WooCommerce session and the native checkout page opens holding the same items. Frontend plugins drop out as the templates they rendered into are replaced, so the phase-one list doubles as a schedule. Measure every template against the one it replaced on field data, and collect that data yourself with the web-vitals library or a RUM tool. The Chrome UX Report behind PageSpeed Insights is a trailing 28-day aggregate. A template switched last week is still mostly the old one in its numbers.

Checkout is the template many stores never move, and that is a sound outcome. With the handoff, payment gateways, tax calculation, shipping rates, coupons, fraud rules and subscription renewals keep working, because none of them is being rebuilt. A custom checkout on the Store API keeps the shopper inside the Next.js application, but it makes you responsible for correctness where money moves, and every gateway has to be integrated again. That is the worse choice unless you can name what it gains you, such as a measured drop-off at the handoff, and it has to be verified with real transactions and real refunds in live mode, not test mode alone. My Account follows the same logic. It carries little traffic, and with WooCommerce Subscriptions or Memberships installed it is full of plugin endpoints for renewals and payment-method changes, so rebuilding it means reimplementing plugin screens nobody asked to change.

No rollback here involves moving data, because orders were in WooCommerce the whole time, including any placed through a rebuilt checkout. Only the mechanism changes. Phases one and two have nothing live to undo. Phase three is undone by pointing DNS back at the WordPress host, which is why the theme stays installed and its hosting plan stays in place for two weeks after the switch. A single template from phase four is undone by deleting its route, so the fallback sends that path to WordPress again on the next deploy; that takes minutes and touches nothing else. A custom checkout is undone by pointing the cart back at the native checkout page. All of this depends on one condition: URLs that did not change. Once the structure moves, a rollback also means reversing redirects Google has already crawled, and that is the strongest argument for keeping every URL identical.

Each phase ends with a decision, and the useful ones are written down before work starts. After the audit, a poor TTFB on uncached pages means fixing hosting and stopping. After the first template, a category page that is not better than the old one on your own field data means finding out why before product pages move, because every later template inherits the same setup. Before checkout, if nobody can name the gain, the handoff stays. After cutover, Search Console coverage and 404s get a daily look for two weeks, and the theme is not deleted until those two weeks pass without a reason to go back. Skip a gate and the staged migration becomes a single cutover with extra steps.