Flatsome to Next.js: How to Migrate a Flatsome WooCommerce Store

UX Builder writes shortcodes, and shortcodes need the theme

UX Builder is a pleasant drag-and-drop editor, and what it saves is not pleasant at all. Every layout is stored in the page's post content as nested shortcodes in a section, row, column, element order. Banners are [ux_banner] with a [text_box] inside, product grids are [ux_products], galleries are [ux_gallery], and tabs and accordions have their own tags. Only Flatsome knows how to turn them into HTML.

Reusable pieces live in UX Blocks, a custom post type dropped into pages, widgets and Theme Options with a shortcode like [block id="homepage-slider"]. Since version 3.13.0, mega menus can be UX Blocks assigned to menu items, so the navigation depends on them too. Deactivate the theme and all of it prints on screen as bracketed text.

• Count the tags. A database query for each shortcode name gives the real inventory: how many pages use [ux_banner], how many product grids, how many UX Blocks are nested inside other UX Blocks.
• Separate content from decoration. Headlines, copy, images and links come out as data. Padding, background colors and animation settings are attributes we read once and redraw as components.
• List Theme Options. The header builder, Header Mobile settings, footer and shop layout live in the Customizer, not in pages, so they need their own screenshots. If the header is already going missing or the mobile menu misbehaves, note which version you want rebuilt.

If UX Builder already refuses to open, our UX Builder not loading guide gets you back in long enough to record what is there.

Products, orders and customers: the data that has to arrive whole

The design is the visible part of a store. The data is the business. None of this belongs to Flatsome: it is WooCommerce data, and it moves the same way no matter which theme drew the pages. That is the good news. The care goes into making sure every row arrives.

Two traps catch stores most often. Orders on a store with High-Performance Order Storage may sit in WooCommerce's own tables while an older copy lingers in posts, so export from the source of truth (our HPOS sync guide explains how to tell). And nobody can read a customer's WordPress password, by design, so returning customers either set a new one by email or log in through a system that accepts the old hash.

Template overrides: Flatsome's version of the product page

Flatsome ships its own copies of WooCommerce template files, which is how it draws a product page, shop grid, mini-cart and checkout in its own style. It is also why WooCommerce sometimes warns that the theme contains outdated copies of template files: the overrides need a Flatsome update to catch up, and any you placed in a child theme must be fixed by hand.

In a migration these overrides are not data to move. They are the design brief. We open each one, and each child-theme override in particular, and note what it changes: gallery layout, quick view, the free-shipping bar, sale badges, how variations display. That list becomes the spec for product, category, cart and checkout components in the new build. If Catalog Mode was switched on to hide the cart, the new store simply launches without one.

Checkout is where stores lose money during a move, so we test it hardest. If yours already misbehaves, our Flatsome checkout troubleshooting and the general WooCommerce layout guide explain the usual culprits, and the Flatsome WooCommerce review covers what the theme adds to a store.

The other exit: Flatsome's own Site Builder

Fairness first. Next.js is not the only road out of Flatsome Classic. On September 30, 2026, UX-Themes put the Flatsome Site Builder into beta: a block-based builder plugin on core WordPress blocks and theme.json, paired with a new Flatsome Block Theme and sold directly at yearly per-site prices rather than through ThemeForest.

Our Flatsome vs Next.js comparison weighs the roads in more depth, and our Flatsome developers will test the beta on a staging copy if that is the road you pick.

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

Moving the store without closing it

1. 1

   Audit the storefront

   Crawl every URL, count UX Builder shortcodes and UX Blocks, and list each WooCommerce plugin with what it does for revenue.

2. 2

   Export the catalog

   Pull products, variations, attributes, categories, images and reviews. Check counts per category against the WordPress admin before going further.

3. 3

   Build the storefront on staging

   Rebuild home, category, product, cart and checkout as components from the override notes and UX Builder screenshots.

4. 4

   Connect payments in test mode

   Attach the same gateway account, set up webhooks for the new site, and run test orders through every shipping zone, tax rule and coupon type.

5. 5

   Import customers and order history

   Bring accounts across with addresses, load past orders as history, and reconcile totals against WooCommerce reports.

6. 6

   Load and test redirects

   Map every product, category and page URL. Run the full list against staging until every old address lands in one hop.

7. 7

   Freeze, sync, switch

   Pause catalog edits, sync orders and customers created since the export, then move DNS during the store's quietest hours.

8. 8

   Watch the first orders

   Confirm order emails, stock deductions and gateway payouts on real orders, and keep the old store read-only for reference.

Keeping /product/ and /product-category/ addresses alive

Flatsome does not change WooCommerce's URL scheme, so your product and category addresses come from Settings > Permalinks: by default /product/slug/ and /product-category/slug/, with child categories nested underneath. Search engines, Google Merchant Center feeds, ads and old emails all point at those addresses. The simplest plan keeps them exactly, and Next.js routes can mirror both patterns.

• Products: keep the slug. If the URL base changes, redirect each old product URL to the new one with a single 301.
• Categories: preserve nesting, or redirect each nested path individually. Category pages often rank better than products, so they deserve the most care.
• Variations: WooCommerce can link to a preselected variation with query strings. Keep the parameter working or send it to the parent product.
• Filters and sorting: filtered URLs with query strings should not each get a redirect. Canonical tags handle them.
• Cart, checkout, account: redirect to their new equivalents so bookmarked links and old receipts still work.

If you advertise products, update feed URLs on launch day. The patterns are covered in our URL structure guide and redirect guide, and ranking protection in migrating without losing SEO.

Payments, taxes and emails on day one

Payments move by reconnection, not migration. With Stripe, customers and saved payment methods live in your Stripe account rather than in WordPress, so a new checkout on the same account can often reach them; confirm with your gateway before you promise customers their saved cards will appear. PayPal and other gateways reconnect with new API credentials and webhook addresses.

Tax rates, shipping zones and coupon rules get rebuilt and then tested against a spreadsheet of real past orders, so the new totals match the old ones to the cent. Transactional emails (order received, shipped, refunded) are rewritten as templates and sent through a proper mail service, which also cures the order emails that never arrive on many WooCommerce stores.

A store migration is finished when the first real order clears, not when the homepage looks right.

Timeline drivers and life after Theme Options

Catalog size matters less than catalog shape. Five hundred simple products move faster than eighty products with deep variations, bundles and custom fields. These drive the schedule and the fixed quote we give after a free site audit:

• How many distinct UX Builder elements and nested UX Blocks the pages use.
• The number of child-theme template overrides and what they change.
• Variation depth, product add-ons and any subscriptions or bundles.
• Whether order history comes across in full or as a summary.
• Integrations: ERP, shipping labels, marketplaces and email platforms.

Phase-by-phase detail is in migration timelines and migration cost; the store-specific pieces are in WooCommerce to Next.js. Ecommerce financing is available.

Afterward, Athena CMS runs the catalog with built-in e-commerce, plain fields and a real preview, and every version kept. Picasso keeps product images described and sized, Iris drafts product titles and descriptions for search, Echo helps manage reviews and Argus flags failing forms and slow pages. If your store is small and you love UX Builder, though, stay on Classic and tune it with our Flatsome speed notes. The migration hub and our WordPress to Next.js development team are here when you outgrow it.