← All migration paths

Migrate away from WPBakery

WPBakery stores its pages as shortcodes in post_content. That single fact decides what a migration can carry across and what it cannot, so it is where this page starts.

What WPBakery stores

WPBakery, formerly Visual Composer, stores shortcodes in post_content much like Divi, but with a flatter structure and a simpler attribute model. That flatness is an advantage on the way out: less inference is needed to recover the intended hierarchy.

The part that actually costs time

WPBakery is frequently bundled with a theme, so the shortcodes on a given site often include theme-specific ones that exist nowhere else. Those have no generic equivalent and are the usual reason a "simple" WPBakery migration stalls.

Carries across

  • Text and headings
  • Images and galleries
  • Row and column structure
  • Most standard element attributes

Needs a decision, or a rebuild

  • Theme-bundled shortcodes, which die with the theme
  • Custom CSS classes applied per row
  • Anything relying on the theme’s own shortcode library

Where you can go from WPBakery

Migrate WPBakery to Gutenberg
Converts WPBakery pages to native Gutenberg blocks by parsing shortcodes, mapping elements to core blocks, and creating draft duplicates for review.
Migrate WPBakery to Bricks
Converts WPBakery pages to Bricks Builder by parsing shortcodes, mapping elements to Bricks equivalents, and creating draft duplicates for review.

How the migration actually runs

The agent works on a duplicate of the page, not the live one. The original keeps serving while the converted copy waits for review, and every write captures a before-state so a bad conversion is one call to undo. Nothing publishes without a human approving it.

All 16 migration paths → Pricing →
Summarize with Google AI Mode