Going live and removing Elementor

The end of a migration is the moment you deactivate Elementor and nothing breaks. The engine tells you when it believes you’re there.

When the dashboard says it’s safe

Once every page is converted and nothing is waiting in the review queue, the migration progress card says:

All migrated and checked, it is now safe to remove Elementor and Elementor Pro.

That message is gated on both conditions, not just the first. A site with every page converted but items still needing your eyes will not show it. It reflects the state of your queue, so it’s exactly as meaningful as your reviewing was.

Check these before you deactivate

Converted pages are real Bricks pages and don’t depend on Elementor. A few things live outside the page content and are worth a look:

• Header, footer, and theme-builder templates. Confirm each converted template is the one actually being used, by loading a real page. Assignment and display conditions live outside the template itself, so a template can convert perfectly and still not be the one Bricks picks for a given page.
• Any page you rebuilt by hand. If you replaced a section in Bricks rather than converting it, that page’s Elementor original may no longer match, you’re keeping the Bricks version, which is fine, just don’t be surprised by the difference.
• Placeholder cards. Third-party add-on widgets became labelled placeholders. Those add-ons are separate plugins, deactivating Elementor won’t remove them, but the placeholders mark the spots you still need to rebuild. JetEngine listing grids are the exception: they convert to native Bricks query loops, so a site whose dynamic listings were built with them has nothing to rebuild there.
• Forms. Elementor forms carry their layout, not their submissions or integrations. Point converted forms at whatever you use for handling entries before the old ones stop running.
• Code execution, if any page needs it. A few Elementor widgets have no Bricks element at all and are converted into a Bricks Code element instead, a Lottie animation is the common one. Bricks renders code elements only when Bricks → Settings → Custom code → Code execution is enabled, and it asks for that consent per site. The engine never enables it for you. If it’s off, those elements render nothing, the dashboard warns you when a converted page depends on it.
• A phone width. One more pass at mobile, on the pages that matter most.

Removing Elementor

Deactivate Elementor Pro first, then Elementor. Load your key pages. If something looks wrong, reactivate, your Elementor data is still there, and any page you haven’t rolled back still has both versions.

Keep the Elementor plugins installed-but-deactivated for a little while rather than deleting them immediately. Deleting is the one step that isn’t quickly reversible.

What happens to the Migration Engine

Converted pages don’t need it. It writes standard Bricks page data, so once you’re happy you can deactivate the engine too and everything keeps rendering, including the Code elements mentioned above, whose signatures Bricks validates against your own site, not against this plugin.

Worth keeping it installed while you still have Elementor data around: it’s what gives you the review queue, the preview switcher, and rollback.

If you’re not done

There’s no requirement to finish in one sitting. A site can run half-converted indefinitely, each page renders from whichever builder owns it, and the dashboard keeps telling you what’s left.