WooCommerce to Next.js: Moving Products, Orders and Subscriptions Without Dropping a Sale

The store lives in the database, not the theme

Owners tend to think of their store as the theme they bought. WoodMart, Flatsome or Storefront decides what the shop looks like. WooCommerce and its extensions decide what the shop is. Products are posts of the product type, each variation a post of its own, with prices, stock and attributes in meta fields. Customers are WordPress users with billing and shipping details attached. Orders sit in WooCommerce's own order tables on stores using High-Performance Order Storage, or in the posts tables on older ones. Subscriptions, bookings, memberships and bundles each add their own records.

So the first job is an inventory of the data, not the design. Which extensions hold data that matters? Which ones only add display features the new build will replace? A store with simple products, a payment gateway and flat-rate shipping is a modest move. A store with subscriptions, product add-ons, wholesale pricing and three years of orders is a project, and it should be planned like one.

Products and variations: easy to export, fiddly to map

WooCommerce has a built-in CSV exporter on the Products screen, and it is a decent start: names, SKUs, prices, stock, categories, images and variations come out in one file. The fiddly parts are the ones that make a catalog work.

• Global attributes such as color or size are shared across products and drive filters. Custom attributes typed into a single product are not. Both need mapping into a consistent option model.
• Variations each carry their own SKU, price, stock, weight and image. A t-shirt in five colors and five sizes is 25 records, and each must keep its SKU so inventory and accounting still match.
• Extension fields from product add-ons, bundles, composite products or custom fields plugins do not appear in the standard export and need their own extraction.
• Theme features such as WoodMart's built-in swatches, wishlist, compare and size guides store data or settings the theme reads, so the new store rebuilds them as components or drops them by choice.

Product images follow the plan in the images migration guide: originals only, alt text carried, and any product photo that ranks in Google Images kept at its address or redirected. Reviews are stored as comments on the product, with a star rating in meta, and move as structured review records.

Customers, order history and passwords that cannot travel

Customer records move easily: names, emails, addresses, phone numbers. Passwords do not, at least not as passwords. WordPress stores them as one-way hashes, and most new systems cannot verify a WordPress hash. The usual approach is a friendly email at launch inviting customers to set a new password, plus a reset link on the login page that works the first time. Some custom builds can check the old hash once and upgrade it silently, which is smoother but more work.

Order history raises a different question: who needs it? Customers want to see past orders in their account. Your accountant needs every order for the tax year. Support needs recent orders for returns. Many stores import the last year or two of orders into the new system for customer accounts and archive the full history as an export the bookkeeper can read. Importing every order since 2016 is possible, and occasionally necessary, but it is rarely the best use of the budget.

Subscriptions and saved cards: the part that can cost real money

Recurring revenue is where WooCommerce migrations get dangerous. A WooCommerce Subscriptions store charges renewals using a saved payment method held by the gateway. The store keeps a token; the card itself lives with the processor. Whether the new system can charge that card depends entirely on the gateway.

With Stripe the news is usually good. The WooCommerce Stripe gateway creates customers and saved payment methods inside your own Stripe account, so a new store connected to the same account can charge them once the customer and payment method IDs are mapped across. Other gateways vary, and some tie tokens tightly to the plugin that created them. Moving card data between processors is possible but runs through the processors themselves, on their timeline. Ask before you plan the cutover, not after.

Timing matters as much as tokens. If the old store and the new one both believe they own a renewal, a customer gets charged twice. If neither does, revenue quietly stops. We pick a cutover date, stop automatic renewals in WooCommerce, run the next renewals from the new system and reconcile both against Stripe in the days that follow. WooCommerce Subscriptions has its own safeguard here: when the site address changes, it treats the copy as a staging site and stops automatic payments and its renewal emails. If renewals are already misbehaving, read why WooCommerce subscriptions stop renewing first.

The third option

Athena CMS, with AI agents on staff.

Not a theme and not a blank Next.js repo. The content system we put behind every custom site: plain fields, a real preview, every version kept, and AI agents that handle the chores a plugin only nags you about.

• PPicassoImages
• AApolloSite analysis
• AAresCompetitor watch
• PPrometheusContent holes
• AAtlasPage depth and structure
• DDelphiAI search visibility

ZDAOAand 12 more agents. Two come with Athena; the rest are monthly add-ons.

Meet the agentsTake the Athena tour

PPicassoWeekly · ImagesAApolloWeekly · Site analysis

Tax, shipping and payment gateways rebuilt as rules in code

In WooCommerce, tax rates, shipping zones and gateway settings live in settings screens and extensions, often configured years ago by someone who has since left. A migration is the moment to write them down. Every shipping zone, method, rate and free-shipping threshold; every tax rate or tax service connection; every gateway, with which payment methods it offers and which currencies.

In the new build those become explicit rules. Shipping logic is code with tests: an order to Alaska over a certain weight either gets the right rate or the build fails. Tax is usually handed to a tax calculation service connected to the checkout, because rates and rules change faster than anyone wants to maintain by hand. Payments run through the processor's own hosted or embedded checkout, which keeps card numbers off your servers entirely. The checkout gets tested with the processor's test mode for every path: guest, account, coupon, failed card, refund.

Product, category and cart URLs

WooCommerce's default addresses are /product/name/, /product-category/name/ and /product-tag/name/, with /shop/, /cart/, /checkout/ and /my-account/ as pages. Stores can change the bases under Settings, Permalinks, so check what yours uses rather than assuming. Product and category pages carry most of the store's search traffic, and the safest plan keeps them character for character, as the URL structure guide explains.

• Product and category pages keep their exact addresses, trailing slash included.
• Product tags keep their pages only if they earn traffic; the rest redirect to a category.
• Variation links with attribute parameters, such as ?attribute_pa_color=blue, should still open the product with that option selected.
• Filter URLs from layered navigation carry filter_ parameters; they are rebuilt as filters, not redirected one by one, and kept out of the index.
• Add-to-cart links using ?add-to-cart= in old emails and ads point at the product page at minimum.
• Cart, checkout and account pages move to their new paths with a permanent redirect for each.

Choosing the engine: a commerce service, a custom store or Athena

A Next.js front end needs something behind it to hold products, carts and orders. There are three honest choices, and the right one depends on the catalog and the business, not on what we prefer to build.

Membership sites are a close cousin: if what you really sell is access, Athena's password-protected membership areas with login levels and Stripe subscriptions may replace several WooCommerce extensions at once. For a deeper look at the trade-offs, read WooCommerce vs Next.js e-commerce and headless vs traditional e-commerce.

A store cutover in seven steps

1. 1

   Inventory data and extensions

   List products, variations, customers, orders, subscriptions, coupons and reviews, and every extension that stores data of its own.

2. 2

   Confirm the payment path

   Check with the gateway that saved payment methods can be used by the new system, and plan the renewal cutover date.

3. 3

   Build and load the catalog

   Import products, variations, images and reviews into the new engine and compare counts, prices and stock against WooCommerce.

4. 4

   Rebuild tax, shipping and checkout

   Write the rules down, implement them, and test every checkout path in the processor's test mode.

5. 5

   Freeze, sync and switch

   Pause catalog edits, sync final stock and recent orders, stop WooCommerce renewals, switch DNS and turn on the redirects.

6. 6

   Invite customers back

   Send the password-setup email, watch the login and reset flows, and answer the first questions quickly.

7. 7

   Reconcile for two billing cycles

   Compare orders and renewals against the processor daily until two full renewal cycles pass cleanly.

Stores are the most involved migrations we run, so we quote them after a free audit, starting at $3,500, and e-commerce financing is available. The e-commerce development service and our WordPress to Next.js development team handle the build, and your team runs the shop afterward in Athena CMS.