Migrations

Migrate a site from one page builder to another without breaking layouts

A rebuild plan for moving pages off one page builder onto another that accounts for leftover shortcode debris, builder-specific serialized meta, and SEO meta that must survive the rebuild.

Works with Claude / GPT95 uses 3.8

The prompt

migrations-page-builder-switch-without-breaking-layouts
I'm moving a 60-page WordPress site off [Divi] and rebuilding it in [Bricks Builder],
because the client wants better performance and the old builder is being phased out.
The pages have years of nested sections, custom CSS classes tied to Divi's own module
IDs, and Yoast SEO metadata that must not change.

Plan this rebuild so it's methodical instead of ad hoc, addressing the failure modes a
generic "switch page builders" article doesn't mention:

1. Content audit before touching anything: how to find and catalog every page that
   uses builder-specific shortcodes or module markup stored directly in the post
   content (Divi wraps content in [et_pb_section] style shortcodes that will render as
   literal text if left behind after the builder is deactivated), so nothing gets
   silently orphaned.
2. Rebuild order and URL preservation: how to sequence rebuilding pages in the new
   builder while keeping the exact same URL/slug so internal links, backlinks, and
   Yoast's existing meta title/description/canonical settings carry over untouched
   even though the page content itself changes.
3. Custom CSS and responsive settings: Divi stores per-breakpoint responsive settings
   and custom CSS scoped to its own module class names, which won't translate
   automatically. Explain how to identify pages relying on custom CSS tied to those
   class names so styling doesn't silently break the moment Divi is deactivated.
4. Cutover strategy: whether to rebuild in place on production page by page (risking a
   half-migrated site being visible) versus rebuild on staging and swap per-page, and
   the tradeoffs of each given a small team doing this alongside normal client work.
5. Verification: the specific check for confirming no leftover shortcode text or broken
   module markup is visible on any live page after each page's cutover, since this is
   the single most common visible failure in builder migrations.

Give me a page-by-page migration order and a verification step for each page, not just
a general strategy.

The classic page-builder-migration failure is leftover shortcode text rendering in plain sight on a live page because the old builder got deactivated before every page was rebuilt. Sequencing the cutover per page, with old-builder shortcodes still active until each page’s replacement is verified, avoids that entirely.