# 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.

- Source canonique : [https://allaux.fr/en/wordpress-woocommerce/migration/constructeur-de-pages](https://allaux.fr/en/wordpress-woocommerce/migration/constructeur-de-pages)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Leave the old builder installed and active: its layout is stored as shortcodes or JSON in wp_postmeta, and deactivating it prints that raw content instead of the sections. Rebuild one pilot page in the new builder, compare it with the original on a staging copy, then work through the site page by page. Only uninstall the old builder once the last page has been rebuilt and checked.

## 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

1. **Inventory of affected pages** — I list every page built with the old tool and assess its complexity: number of sections, animations, custom layouts.
2. **Prioritisation** — I rank pages by traffic and SEO value, so the ones that matter most get rebuilt first if time is limited.
3. **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.
4. **Both builders coexisting** — The old plugin stays active until every page that depends on it has been migrated and visually validated.
5. **Final uninstall** — The old builder’s plugin is only removed once every affected page has been rebuilt and checked, never before.

## The point of no return: removing the old builder too soon

> Deactivating or uninstalling the old builder’s plugin before migrating every page that still depends on it makes their content unreadable: the raw markup stays in the database, but nothing can interpret it correctly any more.

## How I check a rebuilt page

> I visually compare each rebuilt page against a screenshot of the old version, on desktop and mobile, and check that the displayed text matches the original word for word before signing it off.

## Related reading

- **Switching to Gutenberg from the classic editor** — A specific case of builder migration, with its own rules. ([/wordpress-woocommerce/migration/gutenberg-depuis-editeur-classique](/wordpress-woocommerce/migration/gutenberg-depuis-editeur-classique))
- **Creating a WordPress child theme** — Useful for isolating customisations before a page rebuild. ([/guides/creer-theme-enfant-wordpress](/guides/creer-theme-enfant-wordpress))
- **Backing up your shop before any work** — The backup to make before touching page structure. ([/guides/sauvegarder-boutique-avant-intervention](/guides/sauvegarder-boutique-avant-intervention))
- **Migrating without losing your rankings** — What to check on the SEO side after a page rebuild. ([/guides/migrer-sans-perdre-referencement](/guides/migrer-sans-perdre-referencement))

## FAQ

### Can a WPBakery page be automatically converted to Elementor?

Not reliably. Conversion plugins exist but give rough results on anything but simple layouts: misplaced sections, lost styles. I prefer manual rebuilding, slower but reliable.

### Do all pages need to be migrated at once?

No. I prioritise pages with high traffic or SEO value, and keep the old builder active until every page that still depends on it has been rebuilt.

### Is text content lost during the migration?

No, text and images can be recovered even if the layout can’t. I export them before rebuilding to avoid retyping the content.

### What happens if I uninstall Elementor too early?

Pages still built with Elementor show raw JSON instead of their layout. That’s the point of no return for this kind of migration: never uninstall before everything is rebuilt.

### How long does rebuilding one page take?

It depends on complexity: a simple page can be rebuilt in a few hours, one with animations or a custom layout takes longer.