WPBakery to Gutenberg Migration: Step-by-Step Guide

If you are searching for how to migrate from WPBakery to Gutenberg, you are likely stuck in one of two situations: your theme bundled WPBakery years ago and you want to use WordPress's native block editor instead, or you are planning a broader site modernisation and Gutenberg is the first step. Either way, the migration is not a simple plugin swap. WPBakery stores content as shortcodes that Gutenberg cannot read, so every page needs manual reconstruction.

This guide walks through the practical steps to convert WPBakery to Gutenberg, the tools that help, the pitfalls that catch people, and — crucially — whether Gutenberg is actually the right destination for your site.

Why WPBakery to Gutenberg is harder than it looks

The fundamental problem is data format. WPBakery stores your page content as nested shortcodes in the post_content field:

[vc_row][vc_column width="1/2"][vc_column_text]Your content here[/vc_column_text][/vc_column][/vc_row]

Gutenberg stores content as HTML with block comment delimiters:

<!-- wp:columns --><div class="wp-block-columns">...</div><!-- /wp:columns -->

These are completely different formats. WordPress cannot interpret WPBakery shortcodes as Gutenberg blocks. When you open a WPBakery page in Gutenberg, the entire content appears as a single “Classic” block — a wrapper that still depends on WPBakery to render. If you deactivate WPBakery, that content becomes raw shortcode text.

Step-by-step: migrating WPBakery to Gutenberg

Step 1: Audit your WPBakery pages

Before touching anything, catalogue every page that uses WPBakery. Check posts, pages, custom post types, and WooCommerce product pages. For each page, note:

Step 2: Choose your conversion approach

There are three ways to handle the conversion, each with trade-offs.

Option A: Manual rebuild (recommended for most sites)

Open each page in the WordPress admin, view the rendered output in a browser, and rebuild the layout using Gutenberg blocks. This is the most reliable approach because you can simplify layouts, remove unnecessary complexity, and ensure every block works correctly. For sites with 10-30 pages, this typically takes 1-2 weeks.

Option B: Plugin-assisted conversion

Plugins like “Developer Tools for Page Builders” can strip WPBakery shortcodes and convert content to clean HTML. This preserves the text content but loses the layout structure — you get paragraphs and headings without the column arrangements. Useful as a starting point, but you will still need to rebuild layouts manually.

Option C: Classic block wrapper (temporary)

Leave WPBakery active and let Gutenberg wrap the content in a Classic block. This avoids any immediate rebuilding but means you are still running WPBakery — with all its performance overhead — alongside Gutenberg. This is a transitional approach, not a solution.

Step 3: Handle WPBakery custom CSS

WPBakery stores custom CSS in post meta fields. This CSS is loaded per-page and often contains critical styling for the layout. When you remove WPBakery elements, this CSS becomes orphaned but may still load. After rebuilding each page in Gutenberg, check for and remove any leftover WPBakery CSS to prevent conflicts and unnecessary payload.

Step 4: Replace WPBakery add-on elements

If you use WPBakery add-on plugins (Ultimate Addons for WPBakery, Starter Templates, etc.), you need Gutenberg equivalents. The most common replacements:

Step 5: Deactivate and remove WPBakery

Once every page has been rebuilt in Gutenberg and tested, deactivate WPBakery. Check every converted page in an incognito browser to verify nothing breaks. Then delete the plugin entirely. Also remove any WPBakery add-on plugins that are no longer needed.

Run a site-wide performance test after removal. You should see an immediate improvement in page weight and load times from eliminating WPBakery's CSS and JavaScript bundles.

Gutenberg limitations you should know

Before committing to Gutenberg as your destination, understand its current limitations compared to what WPBakery offered.

Should you skip Gutenberg and go headless?

Here is the question most WPBakery to Gutenberg migration guides do not ask: if you are going to rebuild every page anyway, should you rebuild into Gutenberg or into a modern JavaScript frontend?

The work is similar either way. You are examining each page, identifying the content and layout, and recreating it in a new system. With Gutenberg, you recreate it as WordPress blocks. With a headless frontend, you recreate it as React components. The effort is comparable — but the outcome is dramatically different.

Gutenberg gets you:

A headless frontend gets you:

For a content-only blog or brochure site, Gutenberg is fine. For a WooCommerce store where page speed directly affects revenue, going headless during the WPBakery migration is the higher-ROI move. You spend similar effort but end up with a fundamentally faster store. For more on this comparison, see our WPBakery to headless frontend guide.

Decision framework

How WPBundle helps

If your WPBakery WooCommerce store needs more than a Gutenberg upgrade, WPBundle provides a production-ready headless frontend that replaces both WPBakery and the traditional WordPress theme entirely. Your WordPress backend stays unchanged — products, orders, customers, and content remain exactly where they are.

Whether you migrate to Gutenberg or go headless, the most important thing is getting off WPBakery. Its shortcode architecture is a relic that costs you performance, flexibility, and — if you run an online store — revenue. The only question is how far you want to go with the rebuild. For a deeper look at the headless path, see our headless vs traditional ecommerce comparison.