The one-click Divi 5 migration is real, and for a simple site it works exactly as advertised. You run the Migrator, your content converts, and the site comes out the other side looking the same and loading faster. The trouble is that most of the sites worth migrating aren’t simple, and the button doesn’t tell you that before you press it. The gap between “the migration succeeded” and “the migration did what I wanted” is where the actual work lives, and it’s almost entirely about plugins.
Here’s the part that surprises people: the biggest win in a Divi 5 migration often isn’t moving the site over. It’s the plugins you get to delete on the way. Divi 5 absorbed a lot of functionality that used to require third-party add-ons, and a clean migration is the best opportunity you’ll get to shed that weight. But the same plugin situation that creates that opportunity is also the thing most likely to cause problems if you ignore it.
How the migration actually works under the hood
Divi 4 stored your page content as shortcodes. Divi 5 stores it in a block-based format and renders it through a modern framework. When you run the Migrator, it converts every supported module from the old format to the new one, preserving your content, design settings, and configurations. Pages built entirely from converted native modules run on the new framework and get the full performance benefit.
Modules the Migrator can’t convert — primarily third-party extensions from the Divi Marketplace — don’t break. They get wrapped in a backward-compatibility layer that keeps running them on the old Divi 4 framework. This is the clever part of the design and also the trap. Your site keeps working, so nothing looks wrong. But any page containing even one legacy module loads the entire Divi 4 framework alongside Divi 5 to support it, which means that page gets little or none of the performance improvement you migrated for. The presence of one unconverted module is enough to drag a whole page back to Divi 4 speeds.
So “100% compatible” on the migration screen and “actually fast” are two different finish lines. A site can migrate cleanly and still be running half its pages in compatibility mode because of a couple of plugins nobody audited. That’s the single most common way a Divi 5 migration ends up disappointing the person who paid for it.
The plugins Divi 5 lets you remove
Before you migrate, it’s worth taking inventory of what your Divi 4 site uses plugins for, because Divi 5 now does several of those jobs natively. Every plugin you can remove is one less compatibility risk, one less thing to update, one less potential security hole, and one less drag on performance. This is the rare situation where the upgrade actively reduces your technical debt instead of adding to it.
The Loop Builder is the biggest one. If you’ve been running a third-party plugin to build custom post grids, portfolio layouts, dynamic blog feeds, or product listings, Divi 5 can likely do that natively now, pulling live content from your database and working directly with Advanced Custom Fields. The new Interactions system covers a lot of what people previously installed animation and scroll-effect plugins for. Native WooCommerce modules reduce the need for separate Divi WooCommerce extensions. And the preset system, global variables, and customizable breakpoints replace a whole category of small utility plugins people used to bolt on for design consistency and responsive control.
The discipline here is simple: before you renew or reinstall any Divi add-on after migrating, check whether Divi 5 already does the job. A lot of the time it does, and the plugin was solving a Divi 4 limitation that no longer exists. The goal isn’t to remove plugins for its own sake — it’s that fewer dependencies is genuinely better for a site’s speed, security, and stability, and the migration is your natural moment to act on it.
The plugins that will cause problems
The flip side is that some of your plugins haven’t been rebuilt for Divi 5 yet, and those are the ones that will sit in compatibility mode after migration. Every third-party Divi module built for Divi 4 has to be rebuilt from scratch by its developer to run natively in Divi 5 — the architecture changed too fundamentally for a simple update. Some developers moved fast and already have native versions out. Others are still working on it. A few may never get there.
This is why the audit has to happen before you migrate, not after. You need to know, for each Divi-dependent plugin you rely on, whether it has a confirmed Divi 5-native version, whether it merely runs in compatibility mode, or whether it’s been abandoned. The mix you find determines everything about how and when you should move. A site whose key plugins are all Divi 5-ready is a straightforward migration. A site leaning on two or three extensions that are still in compatibility mode is a site that should either wait, or plan to replace those plugins as part of the move.
There’s also a smaller category of friction worth knowing about: a few Divi 4 features and some third-party products aren’t fully supported yet, and a plugin author can even opt their product out of Divi 5 entirely, in which case activating it forces you back to Divi 4. None of this is a reason to avoid migrating. It’s a reason to know your stack before you start, so the migration is a decision rather than a surprise.
The process that keeps you safe
Whatever your plugin situation, the mechanics of a safe migration don’t change, and skipping any of these steps is how a routine upgrade turns into an emergency. Do them in order.
First, never migrate a live site directly. Clone it to a staging environment and run the whole process there. This one rule prevents the large majority of migration disasters, because it means every problem you hit is a problem on a copy, not on the site your customers are looking at. Second, before you run anything, update WordPress, Divi, and every plugin to its current version — running the Migrator on outdated software is a reliable way to create conflicts that have nothing to do with Divi 5 itself.
Third, take a full backup you’ve actually verified you can restore. Divi includes a rollback option that can revert your content to Divi 4, but treat that as an emergency brake, not a safety net. It doesn’t always restore complex customizations, child-theme PHP, or third-party plugin configurations cleanly, so it’s no substitute for a real backup and a staging test. Fourth, run the Migrator before you open any existing Divi 4 content in the new builder, and once it’s done, check your highest-traffic pages first — load them on the front end and compare them to how they looked before. Those are the pages where a problem costs you the most, so they’re the ones to verify first.
Migrate now, or wait?
There’s no single right answer, and anyone who gives you one without looking at your site is guessing. The decision comes down to your plugin stack. If your site is built mostly on native Divi modules and the few third-party plugins you use have confirmed Divi 5 versions, migrating now is worth it and the performance gains on native pages are real. If your site depends heavily on extensions that are still stuck in compatibility mode, the more sensible move is often to migrate in phases, or to wait until those developers ship native versions, while planning which plugins you’ll replace with Divi 5’s built-in features in the meantime.
What you shouldn’t do is treat it as all-or-nothing in either direction. You don’t have to rebuild your entire site overnight, and you don’t have to freeze on Divi 4 until every last plugin is ready. The backward-compatibility system exists precisely so you can migrate the site, run the parts that need legacy modules in compatibility mode for now, and convert them to native Divi 5 at your own pace as the ecosystem catches up. Done deliberately, it’s a gradual, low-drama transition rather than a single risky leap.
Where Lion Ridge fits
The auditing, staging, and phased rebuilding is exactly the kind of work that’s hard to do well the first time and routine once you’ve done it on enough sites. We’ve been building and maintaining WordPress sites since 2014, across every version of Divi, including sites with real traffic where downtime isn’t an option. We can take inventory of your plugin stack and tell you honestly which add-ons Divi 5 makes redundant, which ones will hold you in compatibility mode, and whether your site is a clean migration or one that needs a plan.
If you’re sitting on a Divi 4 site and trying to figure out the smart way to move — or whether to move yet — that’s a conversation worth having before you touch the Migrator. Tell us what you’re running and we’ll tell you what the migration actually involves for your site, plugins and all.
