Short answer up front. If your site runs mostly Divi's own modules and a reasonable amount of custom CSS, this is a migration, it should happen this year, and it belongs on staging rather than the live site. Three module packs and six years of layered CSS? Real project, real number on it, not an afternoon. And if you were already unhappy with the site, those hours are better spent on a rebuild. Not a coin flip you want to call blind, so here is how to sort your site.
The uncomfortable part is being asked to touch a site that currently works. Nobody enjoys that. So let's make it boring.
What actually changed in Divi 5?
Divi 4 saved your page layout as shortcodes. Divi 5 saves it as structured data, and the builder was rebuilt from scratch to render your edits in the browser instead of sending every change to the server and waiting on PHP. That is why the jump from 4 to 5 behaves like a conversion rather than an update.
Plain-English version, for anyone who has never thought about how WordPress stores a page. In Divi 4 your homepage lived in the database as a nested wall of
Which also means your content gets rewritten into a new format. Not copied. Rewritten. Back up like you mean it, and test the restore.
How long does Divi 4 actually have?
Divi 5 left beta on February 26, 2026 and became the default production version. Elegant Themes' launch-day announcement commits to supporting Divi 4 for at least 12 months after that, with security and WordPress-compatibility fixes through that window. That puts the floor around February 2027, after which the update paths converge and Divi 4 sites start getting the Divi 5 notification. "At least" is doing real work there, so check their current announcement before planning around a date.
So you have a year, not a month, which is why this gets done properly instead of in a scramble. Nothing detonates the day support ends. What you lose is the guarantee of patches, and an unpatched builder is fine right up until a host-mandated PHP bump lands on a Tuesday. The deadline is real. It just arrives slowly.
The ten-minute audit: what is your site actually running?
Four counts, and between them they make the decision. Write them down. They are the same numbers we ask for before quoting anybody.
1. Third-party module packs. Anything Divi-flavored on your Plugins page that did not come from Elegant Themes (the Supreme / Essential / Plus style bundles). Zero is easy mode. One is usually fine. Three or more and this is no longer a migration, it is coordinating other people's release schedules.
2. Custom CSS, and where it lives. Theme Options > Custom CSS, your child theme stylesheet, and the per-module Advanced tab. That third one is sneaky, because nobody remembers what they pasted in there in 2021. CSS targeting classes you named tends to survive. CSS written against Divi's generated .et_pb_ internals is where the hours go, because that markup changed.
3. Theme Builder templates. Every header, footer, and template is a separate item to convert and test. They break quietly too, because you never visit your own 404 page.
4. Custom PHP in your child theme that hooks Divi's API. The count that quietly costs money. A custom module built against the Divi 4 API gets rewritten by somebody who writes code. There is no setting for it.
High on 1 and 4? Path B. Low on both? Path A. Already resenting the site? Path C.
Path A: what a clean Divi 5 migration actually involves
The good case. Eight steps, listed so you can see what "done" includes before somebody calls this a quick update.
- Content freeze, in writing, to everyone who touches the site. The step people skip and the one that eats work. Staging runs four days, somebody publishes two posts on live meanwhile, staging gets pushed over the top, those posts are gone.
- Full backup. Files and database, stored somewhere outside the host. Yes, even though the Migrator keeps its own copy.
- Clone to staging. Plenty of hosts do this in one click (SiteGround does on GrowBig and up, where we park client sites). Plans without staging need one built by hand first.
- Update the Divi 4 side first. WordPress core, Divi to the latest 4.x, all plugins. Migrate from current, not from whatever 2023 left behind.
- Run the Migrator's compatibility scan before converting anything. It checks pages, posts, custom post types, Theme Builder templates, library items, and presets, then flags what lands in backward compatibility mode. That report is the honest preview of the project.
- Convert, then walk the site like a customer. Homepage, top five pages, every Theme Builder template, custom fonts, anything with tabs or sliders, and a real submission through every form, on a phone.
- Then open and re-save pages in the builder. A front end that looks perfect while the builder throws a fit is the failure mode that ships.
- Push live at a low-traffic hour and keep the backup for a month. Not a week. A month.
Now be honest about step 6. "Walk the site like a customer" took four seconds to type and it is nine hours on a thirty-page site with three forms. If you have known this needed doing for four months, what is standing between you and a migrated site is not knowledge. It is a free week you are never going to get, and every hour spent here is an hour off the work that pays you. Which is the whole reason we do this for people.
And if you already ran it and you are staring at a homepage that is almost right, spacing off by a hair, a section stacking wrong on mobile, the sticky header no longer sticky: that is not you being bad at this. The gap between "converted" and "right" is the job. It is reading generated markup against six years of CSS and knowing which of the two to change. Send us the URL and we will price closing it.
Path B: when is waiting the deliberate choice?
When your site leans on third-party modules whose developers have not shipped Divi 5 versions yet, or custom PHP nobody has budgeted to rewrite. The answer there is yes, eventually, but not this quarter. Forcing it early buys nothing.
Waiting is not passive though, and not free. A Divi 4 site still needs core and plugin updates, the latest 4.x, somebody reading vendor changelogs for that compatibility label, and backups somebody has tested. That line item never gets cut. Not while you wait, not while you migrate, not ever. An unmaintained site does not fail politely, and it usually fails on the page that takes money. A watched Divi 4 site is a fine place to sit for a few quarters. An unwatched one goes down the week your vendor finally ships. Our care plans start at $300 a month, no contract, and all of that lives inside them, including the calendar entry for revisiting this.
What is backward compatibility mode actually hiding?
It keeps legacy modules rendering by loading the Divi 4 framework alongside Divi 5 on the pages that need it, and flags them with a "Backward Compatibility Mode Enabled" notice in the admin bar. It is a bridge, and bridges are for crossing.
Before leaning on it: modules running that way miss Divi 5 capabilities like flexbox and nested modules, they get quirky in the builder, and those parts of the page never deliver the performance win you migrated for. So yes, a site stuffed with third-party modules technically works. You have also paid for a migration, kept the old rendering path, and given yourself two systems to maintain.
A deferred bill, not a solution. Fine as a temporary state with a date attached. Bad as a plan.
Path C: when is the migration budget really the rebuild budget?
When you did not like the site before any of this started.
Here is the math nobody does out loud. Rebuild the third-party modules by hand, redo the CSS, retest every template, and you are buying hours. Migration hours only ever surprise you upward. So ask what that money buys as a fresh build with a fixed number on it. Our Launch package is $2,400 flat: brand kit, custom design, full build, ten pages populated, on-page SEO, training. Sites with more moving parts start higher (booking from $5,500, stores from $8,500), and the calculator on our pricing page gets you a real number in a minute. Longer version: what a small business website actually includes.
I like Divi, for the record. We built on it for years and still maintain Divi sites (I wrote up how it compares with GeneratePress after a decade on it). But if your own description of your site is "it works, I guess," a migration pays to keep something you do not love. Spend it once, on something you do.
How we handle this on the Divi sites we maintain
If you would rather hand the whole thing to a Divi developer, that page covers what a repair, a migration, and a new Divi 5 build involve, and how each is priced.
Same sequence every time: audit, clone to staging, run the Migrator scan, send the owner the report in plain language, decide together which path the site is on. The path comes out of the report, not out of a preference. Pretending a site with three vendor packs is the same job as a clean one is how people get quoted two hours for a two-week project.
The audit, the scan, and the report are care plan work. The migration gets its own number once we have read the compatibility report, because quoting before that is guessing. And since your domain, hosting, and content stay in your name and the site runs on standard WordPress, "move off Divi entirely" stays a real option, not a hostage negotiation.
Divi 5 migration FAQ
Is Divi 5 stable enough for a real client site?
For sites built with Divi's own modules, yes, with one caveat. It still ships frequent point releases, which is what an actively patched young branch looks like. So we pin a version, test on staging, and never push live the same week a release lands. The stability question for your site is rarely the builder. It is your dependencies and custom code, which is what the scan is for.
Can I roll back to Divi 4 if the migration goes badly?
Yes, with a shelf life. The Migrator saves a copy of your Divi 4 content before converting, and it restores with Divi 4 reinstalled. But rollback gets messier the longer the site runs on Divi 5. Which is the argument for staging, where rolling back means deleting a copy instead of operating on a live site at 11pm.
How long does a Divi 4 to Divi 5 migration take?
The scan takes minutes. The cleanup after it is the entire variable, and anybody quoting a confident hour count before seeing your compatibility report is guessing at your expense. We scan first, then quote a number we stand behind. A fixed price on a job that likes to sprawl is part of what you are buying.
You make this call once, and you have months of runway to make it in. So use them. Send me your site URL, I will run the four counts, tell you which path it is on, and give you the number, whether that is a migration, a care plan while your vendors catch up, or a rebuild. Send it over here. Or if you already suspect Path C, run the calculator and bring me the result. Either way you stop wondering, which is worth more than the runway.