Move from WPBakery to a Next.js storefront

Every other builder stores structured data somewhere retrievable. Elementor keeps a JSON tree in post meta. Divi and WPBakery both use shortcodes, but WPBakery's are broader and less consistent, because a decade of themes and add-on packs each registered their own. That has two consequences worth pricing honestly. First, the content cannot be read without a parser that knows every registered shortcode on your specific site, not on WPBakery in general. Second, you cannot run a partial migration where the old and new frontends coexist for a month — a page is either parsed and rebuilt, or it is broken. Migrations that assumed otherwise are the ones that stall.

Run a scan across post_content and count distinct shortcode tags. Core WPBakery tags — vc_row, vc_column, vc_column_text, vc_single_image — are handled once and reused everywhere. The cost sits in the tail: shortcodes registered by your theme, by add-on bundles, and by whichever developer added a custom one in 2019 that renders the shipping table. Below about twenty distinct tags the parser is a couple of days. Past sixty, and especially past sixty with heavy nesting, a general parser stops paying and rebuilding the pages that matter by hand wins.

• Count distinct shortcode tags across all post types, not just pages
• Separate core vc_* tags from theme-registered and custom ones
• Flag shortcodes with no matching render function — those pages are already broken
• Check product descriptions specifically; shortcodes there are the ones most often forgotten

Almost nobody buys WPBakery directly. It arrives bundled with a ThemeForest theme — Porto, The7, Betheme, Salient — and the theme registers its own element pack on top. So the real question at audit is which theme you are on, because that determines both the shortcode vocabulary and where the header, footer and product layouts are configured. A Porto store and a Betheme store both say "we use WPBakery" and need different work. If your theme also has its own theme-options panel driving the product page, that panel is a second content store the parser knows nothing about and it has to be transcribed by hand.

WPBakery's Grid Builder produces grids driven by queries — post type, taxonomy, ordering, item count — with the layout defined in a separate grid element that is referenced by ID. Two things break here in predictable ways. Grid definitions live apart from the pages that use them. A naive parse therefore produces a page referencing a grid template nobody migrated. And ordering set to custom maps to menu_order, so a rebuild sorting by date will silently reshuffle merchandised collections that someone arranged by hand. Enumerate every grid, map its query to the WooCommerce API, and check sort order against the live site rather than the settings screen.

Every request parses shortcodes server-side and ships a bundle covering every element the theme could render, including those this page never uses. A Next.js storefront renders once and ships only what the template needs — on a category page, usually the largest single reduction in transferred bytes available to a WooCommerce store. Slowness rooted in a 4,000-product catalog on an unindexed database survives it untouched, because the API reads the same tables.

A store under about 150 products, selling steadily, with green CrUX vitals has nothing to gain here. We say so rather than take the work. Keeping WPBakery for the blog while moving only the shop cannot be done cleanly, because the shortcode boundary runs through your content rather than between your sections. Half-measures here produce a site nobody can edit. And if there is no one on the team who can maintain a Next.js application or a support contract covering it, the migration converts a maintainable-if-slow store into a fast store that goes stale. That trade is worse than it sounds two years out.

Stage one is the shortcode inventory and a parser prototype run against your twenty highest-traffic URLs — this is where a quote becomes real, and where roughly one project in five turns out to be the hand-rebuild case instead. Stage two rebuilds templates: product, category, homepage. Stage three handles the long tail of content pages and the redirect map. Checkout stays on WooCommerce throughout. Launch with the old site intact behind a switch you have tested, and keep it there for two weeks — with shortcode content there is no partial rollback, so the whole-site switch is the only rollback you have.