Elementor to Bricks: A Rebuild Playbook

Moving an Elementor site into Bricks is not a one-click export. Teams that treat migration as paste the old HTML into a Code element recreate the same fragility with a new builder logo. Treat it as a rebuild with a content inventory and a design-token extraction step. You will ship faster, cleaner, and with templates you can actually reuse.

This playbook is the process we use on rebuilds: inventory, extract tokens, rebuild hierarchy with nestables, then verify with visual diffs. It assumes you care about long-term maintainability more than a weekend hack.

Inventory before you rebuild

Open the live Elementor site and list every template type you must replace: header, footer, blog archive, single post, service page template, and any popups or theme builder conditions. For each, note widgets that become Bricks components and third-party widgets with no clean equivalent.

• List every template type (header, footer, single, archive, search, 404)
• Note global widgets that should become Bricks components
• Capture spacing and type tokens from the live CSS
• Flag third-party widgets with no Bricks equivalent
• Export a content inventory: pages, URLs, SEO titles, redirects needed

// Pseudo checklist stored as post meta during migration
$checklist = [
  'header' => 'ported',
  'footer' => 'ported',
  'home_hero' => 'in_progress',
  'blog_single' => 'todo',
  'redirects' => 'todo',
];
update_post_meta($project_id, '_migration_checklist', $checklist);

Extract the design system first

Before rebuilding sections, pull colors, type, radii, and spacing into CSS variables. Elementor often hides the system across global styles, kit settings, and one-off widget controls. Your job is to collapse that into a named token set. If the brand already has a DESIGN.md or Figma tokens, map those names into :root and keep them.

Primary CTA color, body font, display font, and button radius are non-negotiable. Get those right before you obsess over a testimonial card shadow.

Rebuild hierarchy — do not dump HTML

Elementor section padding stacks rarely map 1:1. Rebuild with Bricks Section → Block → elements, then match visually. Dumping old HTML into a Code element just recreates the mess you left and blocks future componentization.

/* Prefer tokenized section spacing over one-off padding */
.section {
  padding-block: var(--space-3xl);
}
.section__inner {
  max-width: var(--content-max);
  margin-inline: auto;
  padding-inline: var(--space-lg);
}

Components over clones

Eyebrows, FAQ items, pricing tiers, related cards, and CTAs should be Bricks components with overridable text and icons. A new service page becomes instances with copy swapped — not a rebuilt markup tree. If you clone full pages, you will fix the same bug twelve times.

Content and SEO during cutover

Preserve slugs where they already rank. Map old Elementor widget content into fields or nestable text elements carefully so you do not lose H1 structure. Keep a redirect sheet for any URL changes. If SeoPress or similar is in play, migrate titles and descriptions deliberately rather than hoping a global fallback covers you.

Media libraries usually survive the builder switch. Featured images and attachment IDs stay. What does not survive is Elementor background image settings buried in widget JSON — reattach those as proper image elements or CSS backgrounds with clear class hooks.

Verification gates

Do not declare a page done because it looks close. Run local-to-live visual diffs where you have a static reference, or screenshot before/after pairs for pages that only exist in WordPress. Check mobile separately. Common mismatch sources after migration: font loading, letter-spacing, line-height, button radius, and section padding tokens.

• Desktop and mobile screenshots for every key template
• Keyboard focus order through header and forms
• Reduced-motion behavior for animations you kept
• Query loops with empty states, not just happy paths

What not to port literally

Mega padding values that only existed to fight Elementor’s nested columns. One-off gradient overlays used as atmosphere when your new system prefers flat canvas. Icon fonts when you already have an SVG sprite. Lottie files that add weight without clarifying hierarchy.

Also skip temporary Code elements that grow to multi-kilobyte page bodies. Temporary becomes permanent the moment the launch date moves up.

A realistic timeline mindset

Headers and footers take longer than people expect because every page inherits them. Blog templates are next because they unlock content velocity. Marketing pages follow, prioritized by traffic and revenue. Internal utility pages can wait if redirects keep old URLs alive.

Migrations succeed when the team agrees that rebuild quality beats paste speed. Bricks rewards structure. Elementor residue punished it. Leave the residue behind.