Migrating from one page builder to another
Elementor, Divi, WPBakery, native Gutenberg: each stores its layout in a format of its own, and not always in the same place in the database. Switching between them isn’t a setting, it’s a page-by-page rebuild.
Why switching builders isn’t a one-click job
How the layout is stored differs from one builder to the next, and none of the formats is interoperable. Native Gutenberg and WPBakery both write into the post_content field of the wp_posts table — the first with HTML comments delimiting each block, the second with nested shortcodes. Elementor instead keeps its layout as JSON in the dedicated _elementor_data meta field, replayed when the page loads. All three describe the same idea — a page made of sections — but none of them can read another’s format.
There’s no reliable converter that automatically translates a WPBakery layout into an Elementor one, or the other way round. Some plugins claim to do this conversion, but in practice the result keeps misplaced blocks, lost styles or empty sections on anything but the simplest layouts. The method that actually works is manual rebuilding in the new builder, optionally using a text and image export to avoid retyping the content.
The breakage doesn’t stop at layout: each builder also generates its own element identifiers (for instance classes like elementor-element-xxxxx), which separately added custom CSS often targets. That custom CSS stops applying as soon as the page is rebuilt elsewhere, since the new elements carry different identifiers — it has to be rewritten, not just copied over.
What appears if the builder is deactivated too early
- Shortcodes shown as plain text on the page, like [vc_row][vc_column]…, instead of the layout
- JSON displayed as text instead of being interpreted, on pages built with Elementor
- A layout that collapses into a single column, with no styling or spacing
- Images or icons that stop displaying, previously loaded by the deactivated builder
How I run this kind of migration
-
Inventory of affected pages
I list every page built with the old tool and assess its complexity: number of sections, animations, custom layouts.
-
Prioritisation
I rank pages by traffic and SEO value, so the ones that matter most get rebuilt first if time is limited.
-
Page-by-page rebuild
Each page is recreated in the new builder, keeping the text, images and heading structure, without copying the old tool’s markup.
-
Both builders coexisting
The old plugin stays active until every page that depends on it has been migrated and visually validated.
-
Final uninstall
The old builder’s plugin is only removed once every affected page has been rebuilt and checked, never before.
Related reading
-
Switching to Gutenberg from the classic editor
A specific case of builder migration, with its own rules.
-
Creating a WordPress child theme
Useful for isolating customisations before a page rebuild.
-
Backing up your shop before any work
The backup to make before touching page structure.
-
Migrating without losing your rankings
What to check on the SEO side after a page rebuild.
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.