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.

WPBakery stores layouts as shortcodes. Gutenberg uses blocks. There is no automated 1:1 conversion — every page must be rebuilt. For sites with fewer than 30 pages, a manual migration to Gutenberg takes 1-3 weeks. For WooCommerce stores, consider skipping Gutenberg entirely and going headless with a Next.js frontend — you are rebuilding anyway, so rebuild on a modern foundation.

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:

...

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.

Some migration plugins offer “convert all pages” functionality. Never run this on a live site without a staging backup first. Shortcode stripping is irreversible — if the conversion produces broken layouts, you cannot undo it without restoring from backup.

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.

Gutenberg outputs cleaner HTML and lighter CSS than WPBakery, which helps. But the fundamental architecture is identical: PHP generates HTML on each request, the browser loads WordPress's CSS/JS stack, and every uncached page hits your server. Gutenberg is faster than WPBakery, but it does not remove the WordPress rendering ceiling. For that, you need a headless architecture.

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

You have a content site (blog, brochure) with no e-commerce
Your team is non-technical and needs a visual editor
You have fewer than 30 pages to migrate
Performance improvement from removing WPBakery is sufficient
You want to stay fully within the WordPress ecosystem

You run WooCommerce and page speed affects conversions
You have developers comfortable with React/Next.js
You need Lighthouse scores above 90 consistently
You want to eliminate the PHP rendering ceiling entirely
You plan to sell across multiple channels (web, mobile app)

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.

Its shortcode architecture is a relic that costs you performance, flexibility, and — if you run an online store — revenue.

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.