WordPress Page Builder Migration: Elementor, Bricks, Oxygen, Divi and WPBakery to Etch or Gutenberg

Every builder promises that you can leave whenever you like. Then the day comes, a license renewal, a performance problem, a team that wants a different editor, and you find that a thousand pages are stored in a format only one plugin can read. A WordPress page builder migration is possible, and plenty of sites do it every month, but it goes well only when you treat it as a planned project with a start, a finish and a way back. This guide gives you that plan. It covers the honest reasons to switch, what each builder leaves in your database, a decision matrix for the common pairs, a ten step runbook, how to protect rankings, how to use staging and rollback, and when the right call is to stay exactly where you are.

The advice applies whether you are moving from Elementor, Bricks, Oxygen, Divi or WPBakery, and whether the target is another builder, Etch or the plain block editor. For step by step detail on one specific pair, follow the links as you go. The full set lives in the migrations directory.

Key takeaways

• Builders store layouts in private formats, so a migration is a rebuild with the old site as the reference, not a conversion.
• Your posts, media, menus, users and SEO data belong to WordPress and stay put. Layouts, templates and builder specific features are what you rebuild.
• An inventory comes before any design work. Pages ranked by business value decide where the care goes.
• Keep URLs and metadata identical wherever you can, redirect what you retire, and compare crawls before and after.
• Work on staging, keep the old site live until the new one is checked, and write the rollback plan before you start.
• Some migrations should not happen. If the current site works and the pain is small, staying put is a valid result.

Contents

• 1. Why is a WordPress page builder migration a rebuild, not a conversion?
• 2. Should you switch page builders at all?
• 3. What does each builder leave behind in your content?
• 4. Which source and target pairs carry over what?
• 5. How do you take a content inventory before you move anything?
• 6. What is the 10-step runbook for a page builder migration?
• 7. How do you keep your URLs and rankings through a switch?
• 8. How should staging and rollback work?
• 9. Where does an AI agent help, and where must a person decide?
• 10. What does each route look like in practice?
• 11. When should you stay put?

Why is a WordPress page builder migration a rebuild, not a conversion?

A page builder keeps the design of each page in a format of its own. Elementor stores a layout record for each page. Bricks keeps an element tree in post meta and leaves the main content field close to empty. Oxygen holds its designs in its own data. Divi and WPBakery write shortcodes into the post content. Etch and the block editor use native WordPress blocks. These formats do not share a vocabulary, so a column in one is not a column in another, and a widget with ten settings has no automatic twin.

That is why one click converters disappoint. They either keep the text and lose the layout, or they produce markup that you spend a week cleaning. The dependable route is to rebuild each page in the new system while the old site stays online as the reference, then compare the two until they match in the ways that matter. If you want the short version of the same argument, our post on what transfers and what does not lays it out.

What is not lost

The content layer is yours and survives. Posts, pages as records, media files, categories, menus, users, comments and the metadata written by your SEO plugin are WordPress data, not builder data. That is good news, because most of the value of a site lives there. What you rebuild is presentation: layouts, theme templates, reusable sections and any behavior that the old builder supplied.

What is at risk

• Layouts and spacing, especially on small screens.
• Header, footer and archive templates, which every page depends on.
• Popups, sliders, tabs, animations and other builder specific widgets.
• Forms and the places their submissions are sent.
• Dynamic content such as query loops, conditions and custom fields wired into layouts.
• Shortcodes and builder markup left behind in old content.

Should you switch page builders at all?

Before you plan anything, check the reason. A migration costs time, risks mistakes and returns nothing if the motive was weak. Good reasons look like this: the editing experience slows your team down, the front end is heavier than you can accept, a license or support model no longer fits, the builder is unmaintained, or you want content stored in blocks so that future design changes do not start from zero. Weak reasons look like this: a new tool looked exciting, another site uses it, or the current one feels old.

Test the reason against the pain

Write the problem in one sentence and name how you will know it is solved. A site that feels slow needs a measurement before and after. A team that dislikes the editor needs an editing task timed in both. If you cannot describe the finish line, you are not ready to start. It is far better to learn that now than halfway through a rebuild.

Run a one page pilot

Choose one representative page, ideally a landing page with a header, a few sections and a form, and rebuild it in the target. Time the work, note what you had to decide, and ask the people who will edit the site to try it. A pilot costs a day and answers the question that matters: does this target do what we need, at a price we can pay?

What does each builder leave behind in your content?

Knowing where your layouts live tells you what a migration will touch. Use this as a quick reference before the inventory.

Add your add-ons to the picture. Third party widget packs, form plugins, popup tools and custom code often hold more of the design than the builder itself. Each one needs a decision: replace, rebuild or retire.

Which source and target pairs carry over what?

Use the matrix below to set expectations for the most common pairs. It is qualitative on purpose. It tells you what kind of work to expect, not how long it takes, because that depends on your site. Pair specific detail is in each linked guide.

Reading the matrix honestly

Notice how much stays constant. In every row the content and the data survive and the presentation is rebuilt. Where a move goes from a builder to plain blocks, expect to give up some effects, since core blocks do not offer sliders, filterable portfolios or scroll animations. That is not a failure of the migration. It is a design decision you should make on purpose, page by page.

How do you take a content inventory before you move anything?

An inventory is the single most valuable hour in the project. It turns a vague worry into a list you can sort, share and tick off. Build it in a spreadsheet and fill it in before you design anything. An AI agent connected to the site can read much of this for you and return a first draft, which you then check and correct yourself.

Content inventory template

Create one row per page or template and these columns:

• URL and slug, copied exactly.
• Page type: page, post, landing page, template, popup or reusable part.
• Builder used, or none if it is already plain blocks.
• Traffic, leads or sales it contributes, with the source of the number.
• Title tag, meta description and canonical, copied from the SEO plugin.
• Primary keyword and whether the page ranks for it today.
• Forms, embeds and third party widgets on the page.
• Dynamic parts: loops, conditions, custom fields, shortcodes.
• Internal links in and out.
• Decision: rebuild, simplify, merge, redirect or retire.
• Owner, status and the date it was checked on staging.

Rank by value, then decide what not to move

Sort the sheet by what each page does for the business. The top of the list deserves the most careful rebuild and the closest review. Old campaign pages, thin posts and unused templates do not need to move at all. Retiring them shrinks the project, and each retired URL can be redirected to its closest living page. Many migrations finish faster simply because the team stopped rebuilding pages nobody visits.

Record the design system in words

Write down colors, fonts, spacing, button styles and breakpoints as they exist today. The target needs them defined once, before the first page, so that every page draws on the same values. Teams that skip this step end up with a rebuilt site that is as inconsistent as the old one.

What is the 10-step runbook for a page builder migration?

The same ten steps work for every pair. Adjust the details to your builder, but keep the order, because each step protects the next.

1. Back up and snapshot. Take a full backup, store a copy off the server, and test that you can restore it. Nothing else starts until this is done.
2. Create staging. Copy the site to a staging environment with search engines blocked. Work only there.
3. Run the inventory. Fill in the template above, rank pages by value and decide what to retire.
4. Capture the baseline. Crawl the live site, export titles, headings, canonicals and internal links, and save screenshots of the key pages at desktop and mobile widths.
5. Install the target beside the old builder. Keep both active on staging so the old pages stay viewable as the reference.
6. Set up the design system. Define colors, type, spacing and buttons once, in the target.
7. Rebuild the templates. Header, footer, single post and archive templates come first, because every page depends on them.
8. Rebuild pages as drafts, in value order. Match the reference, then check mobile, forms, links and metadata before marking each page done.
9. Review and test. Compare a new crawl to the baseline, test every form, click every key link and check the pages with the people who edit them.
10. Switch, redirect and watch. Move the site over in a quiet period, publish the redirect map, remove the old builder only after a final backup, and monitor Search Console and your crawl for the following weeks.

Resist the urge to skip the baseline in step four. Without it you cannot prove that the migration preserved anything, and you will argue from memory when a page drops.

How do you keep your URLs and rankings through a switch?

Rankings follow content, URLs and links, not the builder that drew the page. A migration protects them by changing as little of those as possible. Treat the following as a checklist for every page you move.

Keep slugs and structure identical

The easiest redirect is the one you never need. Keep every slug exactly as it was, keep the same parent and child relationships and keep the permalink structure. A rebuilt page at the same address has no redirect to maintain and no equity to lose.

Redirect what you change or retire

When a URL has to change or a page is retired, write a 301 redirect to the closest equivalent page, not to the home page. Keep the map in the inventory sheet so it is reviewed with the page, then test it with a crawler after launch. Avoid redirect chains by pointing old addresses straight at the final target.

Copy metadata, canonicals and headings

• Title tags and meta descriptions stay in your SEO plugin, but confirm they still print on the rebuilt pages.
• Each page keeps one H1 and a logical order of H2 and H3 headings. Builders sometimes hide the H1 in a theme template, so check the rendered page.
• Canonical tags point to the page itself unless you chose otherwise.
• Structured data from your SEO plugin still appears, and any schema typed into the old builder is recreated.
• Image alt text and file names survive, because media files are not touched.

Protect internal links and the sitemap

Links inside old content may point at addresses you changed. Search and replace them after launch, and make sure menus and footers link to live pages only. Confirm the XML sitemap lists the final URLs, then resubmit it in Search Console. Watch the coverage and performance reports for the next few weeks and fix any page that falls out of the index.

Mind speed and layout shift

A new builder can load more or less than the old one. Run the same speed check on the baseline and on the rebuilt pages, and look at images, fonts and layout shift. A migration that makes pages slower will undo the reason for the move.

How should staging and rollback work?

Staging is where mistakes are cheap. Rollback is what turns a risky launch into a reversible one. Plan both before the first page is touched.

A sound staging setup

• A full copy of the site with search engines blocked and outgoing email disabled.
• The old builder and the target both active, so you can compare side by side.
• A rule that nothing is edited on live while the rebuild runs, or a way to replay changes later.
• A low privilege WordPress user for any agent or contractor, never an administrator login shared around.

Write the rollback plan first

Decide in advance how you would undo the switch. Keep the pre migration backup within reach, note how long a restore takes, and agree who makes the call to roll back and by when. Switch during a quiet window, run your checks straight away and stay available for a few hours. If something serious shows up, restoring beats improvising.

Keep the old pages until you are sure

Leave the old builder installed and the old content intact until the new pages are live and checked. Deactivating a shortcode based builder too early can fill pages with raw markup. Once you are confident, take a final backup, then remove what you no longer need.

Where does an AI agent help, and where must a person decide?

A rebuild is full of repetitive work: reading every page, listing widgets, recreating similar sections, comparing screenshots, checking links. That is where an AI agent earns its keep. It is also where unchecked automation does damage, so the line between assistant and decision maker needs to be clear.

Where an agent helps

• Reading the site and drafting the inventory table for you to correct.
• Rebuilding sections from a description or reference, one draft page at a time.
• Listing the widgets and add-ons used on each page.
• Comparing headings, links and metadata before and after.
• Producing a status report of what is done and what is left.

Where a person decides

• What to keep, merge or retire.
• Which features to drop when the target has no equivalent.
• Whether a rebuilt page matches the intent of the old one.
• Every publish. Agents save drafts, people press the button.
• Any step that touches redirects, templates or live data.

NibWP is a WordPress plugin that turns a site into an MCP server so that AI clients such as Claude, ChatGPT and Cursor can build and manage it, and it offers Pro Skills for specific builders, including Etch. The MCP switch is off by default and locked to the site’s domain, and each AI client gets its own application password. Check the Pro Skill list on its site before assuming support for any other builder. Whatever you use, our post on how to let an AI agent work on WordPress safely covers the habits that apply: a copy first, a dedicated user, a revocable credential, a log you read and a person who approves publishing.

What does each route look like in practice?

The routes differ in detail, so here is what each one tends to involve. Treat these as orientation, then open the guide for your pair.

Elementor to Bricks, Etch or Gutenberg

Elementor sites usually carry the most accumulated extras: theme builder templates, popups, saved templates and add-on widgets. The inventory is long, so ranking by value matters most here. Read the Elementor to Bricks guide, the Elementor to Etch guide or the Elementor to Gutenberg guide depending on where you are heading. The Gutenberg route gives up the most effects and gains the least dependency.

Bricks to Etch

A Bricks site is often tidy, with global classes and theme styles that already describe a design system. That structure becomes the map for the rebuild. Query loops and interactions need the most attention. The Bricks to Etch guide explains what moves and what is rebuilt.

Oxygen to Bricks or Etch

Oxygen projects centre on templates and reusable parts, so build those first and the pages follow. Custom code blocks and PHP in templates deserve a careful human read before anything is reused. See the Oxygen to Bricks guide and the Oxygen to Etch guide.

Divi or WPBakery to Elementor or Gutenberg

Shortcode based builders leave raw markup behind when deactivated, so cleanup of old content is part of the job, along with a check of every page for leftover tags. Sliders, portfolios and scroll effects have no core block equivalent, so decide what to simplify. Start with the Divi to Elementor guide, the Divi to Gutenberg guide or the WPBakery to Gutenberg guide.

A note on timing and budgets

Resist promising a date before the pilot. One finished page, with its template work and review, is the best unit for estimating the rest. Add a margin for templates, forms and the unexpected, and count the review time as real work, because it is.

When should you stay put?

Not every migration is worth doing. Staying put is a legitimate outcome, and often the wise one. Consider it seriously if any of these are true.

• The site works, the team can edit it and the only complaint is that the tooling feels dated.
• The pain is speed, and a few fixes to images, caching and plugins would solve it without a rebuild.
• The site depends heavily on builder specific features that the target cannot match, such as complex animations, popups or dynamic layouts.
• The business cannot spare the review time, or a major launch is close.
• There is no one who can own the project, check the pages and make the calls.
• The pilot page took far longer than expected and the budget cannot absorb that across the whole site.

If you stay, you can still reduce lock in over time. Keep content in the post editor where you can, document your global styles, avoid piling on add-ons and make new pages in a way that is easy to rebuild later. That keeps the option open without paying for it today.

If you do go ahead, go with open eyes: a backup, a staging copy, an inventory, a baseline, a pilot, a redirect map and a rollback plan. With those in place, a page builder migration stops being a leap and becomes a series of small, reversible steps. When you are ready to pick your pair, open the migrations directory and start with the guide that matches your site.

Questions

Can I migrate a page builder in one click?

Not reliably. Each builder stores layouts in its own format, and the new builder cannot read it. Plan a rebuild, page by page, with the old site as the visual reference and a backup behind you.

How long does a page builder migration take?

It depends on page count and how much custom behavior the site has. The inventory tells you more than any average. Count templates, reusable parts and key pages first, then time one finished page and multiply with a margin.

Will switching page builders hurt my SEO?

It can if URLs, titles, headings and internal links change by accident. Keep slugs, copy the metadata, redirect anything retired, and compare a crawl before and after. Content and URLs matter more than the builder.

Do I need to keep the old builder installed?

Keep it active on staging until every page is rebuilt and checked. On the live site, remove it only after a full backup and a pass through the pages, because leftover builder markup can appear as raw text.

Is Gutenberg or Etch a better target than another builder?

It depends on who edits the site and what the design needs. Native blocks suit editors who want little tooling. A builder suits complex layouts. Choose with a one page pilot, not with a feature list.

Can an AI agent do the whole migration for me?

It can do much of the repetitive rebuilding and checking, but a person decides what to keep, reviews every page and approves each publish. Treat the agent as a fast assistant with limited permissions, not as an autopilot.