Move from Kadence to a Next.js storefront

Kadence Blocks and core blocks both store content as block markup in post_content — HTML with structured comment delimiters, readable by any parser. Deactivate WPBakery and pages turn into visible shortcode text; Elementor keeps a nested JSON tree in post meta. A 200-page Kadence store extracts in days rather than weeks, so extraction is not where this budget goes — which changes what you should be negotiating about.

• Core blocks map to components almost one to one
• Kadence Blocks need a mapping table but no reverse engineering
• Block attributes carry the settings, so spacing and alignment survive
• Reusable blocks become shared components with no extra work

The biggest performance variable on a Kadence store is usually hosting and caching, not the theme, and that is the first thing to establish. Pull twelve weeks of CrUX field data for LCP, INP and CLS. If all three are green on mobile, a frontend rebuild will not help, and we will say so in the audit rather than after the invoice. If LCP is red while the theme's own CSS is under 50KB, the cause is almost always an unoptimized hero image, a slow server response, or a plugin loading in the head — and all three are fixable inside WordPress for a fraction of a migration budget.

The honest case for leaving Kadence is capability, and it comes down to three things a theme cannot solve regardless of how well it is written. Filtering a catalog past several thousand products fast enough that shoppers keep using it, because that needs a search index rather than database queries against wp_postmeta. Serving genuinely different merchandising per market rather than a translated copy of one storefront. And per-template control over what JavaScript ships, which no theme offers because a theme has to assume every template might need everything. Where none of those three describes the store, staying put is the correct decision and the rebuild is money spent on nothing.

Kadence's header and footer builder stores its configuration in theme mods, not in page content, so it sits outside every content export and gets missed by exactly the kind of parser that handled the rest of the site cleanly. It has to be read from the customizer and transcribed by hand: three rows of desktop slots, plus a separate mobile arrangement with its own visibility rules. Global colour palettes and typography are theme mods too, and the new design system has to reproduce them deliberately. This is a day of careful work, not a technical problem — but it is a day that does not appear in an estimate built from page count.

Stores ask because third-party comparisons show a gap — one reviewer's benchmark puts Blocksy at 83 against Kadence at 73. It changes nothing here. Both store content as block markup, both keep configuration in theme mods, both put the header builder outside content exports. Blocksy Companion adds an extension layer worth about half a day to inventory, and that is the only real difference. Ten points in a synthetic benchmark is not a migration argument, and a store picking between the two on speed is tuning a variable that matters less than its hosting.

The stores where this project pays back share a shape: a catalog large enough that filtering is a real product problem, a team that has already fixed hosting and caching, and a plan for maintaining a Next.js application after launch. Under about 500 products with green field vitals, there is nothing here to recover. Add no maintenance path and the project turns actively harmful: a fast storefront nobody can update is worth less in eighteen months than a slower one that gets patched. What we do recommend to Kadence stores more often than a migration: fix the image pipeline, move off shared hosting, and spend the remaining budget on the product pages themselves.

Because extraction is cheap, the schedule inverts relative to a WoodMart or Avada project. Less time on content archaeology, more on the catalog problem that justified the work — usually the search index and filter layer, which is where a large-catalog rebuild earns its money. Transcribe the header, footer and global styles early, since they gate every template. Keep checkout on WooCommerce. Expect the whole thing to run shorter than a comparable migration off a page-builder theme, and expect the performance delta to be smaller too. Both of those are the same fact seen from different sides.