Most Divi 5 migrations that go wrong don’t go wrong during the migration. They go wrong before it, when someone skips the preparation, or after it, when nobody checks the right things. The Migrator itself is reliable. The damage comes from the steps on either side of it that feel optional until the moment they aren’t. So this is the actual checklist — the sequence we run on every Divi 4 site we move, in the order we run it, with the reasons each step matters.
One thing to understand before anything else: migrating to Divi 5 is a one-way door. Rollback exists, and it works cleanly right after migration, but the longer you run Divi 5 and edit content, the harder a clean rollback becomes. That single fact is why the preparation phase is not negotiable. Your best and sometimes only clean exit is the backup you take before you start.
Phase 1: Before you touch anything
This phase is entirely about making the migration reversible and giving it the best possible conditions to succeed. None of it is glamorous, and all of it is the difference between a routine upgrade and a bad week.
- Audit your plugins first. List every Divi-dependent plugin and third-party module pack you use, and check each one’s current Divi 5 compatibility status. You’re sorting them into three buckets: confirmed Divi 5-native, runs-in-compatibility-mode-only, and abandoned. This list determines whether you migrate now or wait, so it comes before everything else.
- Update everything to its latest stable version. Update WordPress core, the Divi theme, and every plugin before you do anything else. Running the Migrator on outdated software is one of the most common causes of conflicts that have nothing to do with Divi 5 itself.
- Take a full, verified backup. Database, uploads directory, themes, and plugins — the whole site, not just the database. Use a tool you trust, and actually confirm the backup restores. An unverified backup is a guess, not a safety net.
- Note your performance baseline. Run your key pages through PageSpeed Insights or GTmetrix and save the numbers now, while you’re still on Divi 4. Without a before, you can’t prove the after, and you can’t tell whether a page is getting the gains or quietly stuck in compatibility mode.
Phase 2: Stage it, never live
The single rule that prevents most migration disasters: never run the migration on your live site first. Clone the site to a staging environment and do the entire process there. Every problem you hit on staging is a problem on a copy, discovered on your schedule, instead of a problem your customers find during business hours.
- Create a staging clone. Use your host’s one-click staging if you have it, or a staging plugin if you don’t. The staging site needs to be a real copy — same plugins, same content, same configuration — or the test doesn’t mean anything.
- Install Divi 5 on staging and run the Migrator. Critically, run the Migrator before you open or edit any pages, posts, or Theme Builder templates in the new builder. Editing content first converts it in a way that can’t be cleanly restored to Divi 4 format. Migrate first, explore second.
- Let the compatibility report tell you the truth. The Migrator flags which modules convert natively and which fall back to compatibility mode. This is the same plugin audit from Phase 1, now confirmed by the tool against your actual pages. Orange warnings don’t mean you can’t migrate — they mean you have decisions to make about which legacy modules to replace.
Phase 3: Test the things that actually break
Once the staging site is migrated, resist the urge to glance at the homepage and call it done. The failures that hurt are the ones hiding in functionality, not the obvious layout shifts. Work through these deliberately, highest-traffic and highest-stakes pages first.
- Forms and their destinations. Submit every form and confirm it not only sends but lands where it’s supposed to — the inbox, the CRM, the autoresponder. Form-to-CRM connections are exactly the kind of integration that can break silently in a migration, and a broken contact form is lost revenue you won’t notice until someone complains.
- Anything dynamic or interactive. Sliders, galleries, pop-ups, menus, filtered post grids, and any layout driven by custom fields. These lean hardest on module behavior and are where compatibility-mode quirks show up.
- Responsive behavior at every breakpoint. Divi 5 changed how layout works under the hood, so check phone, tablet, and desktop on real pages, not just the builder preview.
- Custom code and shortcodes. Any custom CSS, code modules, or shortcodes you relied on in Divi 4 need direct testing, since the storage format underneath them changed.
- Cross-browser and a second set of eyes. Check Chrome, Safari, Firefox, and Edge, then have someone who didn’t build it click through. Fresh eyes catch what familiarity skips over.
Phase 4: Don’t ignore security and hosting
Security is the part of a Divi migration people forget, because the theme switch feels separate from the rest of the stack. It isn’t. A migration is exactly the moment to confirm the protective layer of your site survived intact, and a good opportunity to tighten it.
- Verify your security plugin still functions natively. Security and firewall plugins are third-party software like any other, and they need to be confirmed working after the move — not assumed. If yours only runs in compatibility mode or hasn’t been updated, that’s a gap to close before launch, not after.
- Recheck caching at every layer. Plugin cache, server cache, and CDN all need clearing after migration, and your caching plugin needs to be confirmed compatible. Stale cache is the most common reason a migrated page “looks broken” when nothing is actually wrong.
- Treat removed plugins as a security win. Every Divi 4 add-on that Divi 5 now makes redundant — and there are several — is one fewer plugin to keep patched and one fewer potential entry point. Use the migration to retire what you no longer need rather than carrying it forward out of habit.
- Confirm backups and monitoring continue after launch. Make sure your automated backups, uptime monitoring, and update routine are running on the migrated site. The migration is not the end of the maintenance relationship; it’s a checkpoint in it.
Phase 5: The launch and the 48 hours after
When staging is clean and tested, the live migration is almost anticlimactic — which is the point. You’ve already found the problems. Now you’re repeating a known-good process on the production site.
- Pick a low-traffic window and take a fresh backup. Migrate the live site when the fewest people are on it, with a backup taken immediately beforehand. Even though you tested on staging, the live site gets its own current backup.
- Run the live migration and clear every cache. Repeat the staging process exactly, then flush plugin, server, and CDN caches so visitors see the migrated site, not a cached ghost of the old one.
- Re-test forms and core paths on production. Test the contact form, navigation, header and footer, and blog archive on the live site specifically. Staging and production differ in small ways that occasionally matter.
- Watch the logs and analytics for 48 hours. Monitor error logs, server logs, and traffic for two days. Most post-migration issues surface fast, and watching closely early means you catch them before they cost anything.
- Compare against your baseline. Re-run the pages you benchmarked in Phase 1. Native Divi 5 pages should show real improvement; anything that didn’t move is probably still carrying a legacy module worth converting.
Where the real judgment lives
A checklist gets you through the mechanics, but it can’t make the two calls that decide whether a migration is worth doing yet. The first is reading your plugin audit honestly — knowing which dependencies are genuinely Divi 5-ready, which are dragging you into compatibility mode, and which you should replace with Divi 5’s native features instead of carrying forward. The second is deciding the order of operations for a complex site, because a migration with custom code, CRM integrations, and a real plugin stack is rarely a single clean event. It’s a staged process you sequence to protect the pages that matter most.
That’s the part that’s hard to do well the first time and routine once you’ve done it across enough sites. We’ve been building and maintaining WordPress sites since 2014, through every version of Divi, including sites where downtime has real consequences. If you’d rather not learn the order of these steps on your own live site, send us what you’re running and we’ll tell you whether your site is a clean migration or one that needs a plan first.
