The Short Version
- Every site had something. Six months, six migrations, and not one of them came through with nothing to fix. Most were small. One stopped the site from loading at all.
- Old plugins are still the number one problem. A senior care site went white the moment Divi 5 installed. Two outdated pieces were behind it, and turning them off fixed it in minutes.
- Faster is not automatic. One site jumped from a GTmetrix F to a C with no caching at all. Another got slower on launch night and needed its caching sorted out afterward.
- The fix for almost all of it is doing it on a copy first. Every issue below except one showed up on a staging site, where nobody but me saw it.
Divi 5 came out in February. I published my first migration notes in March after the first few, and I have been doing them steadily since. Six months in, I have enough real Divi 5 migration issues on the board to tell you what actually goes wrong, instead of what might.
Here's the thing. The upgrade itself is a button. You click Migrate and you wait. What makes this hard is not the button, it is everything your site has collected over the years sitting behind it, and you do not find that out until the button is pressed.
Every one of these was something a person could see. A page that looked wrong. A site that would not load. A menu that stopped working. None of it needed a developer to find. All of it needed someone to look.
Every Site Had Something, and That Has Not Changed
I said this in March and it has held up since. Every single site I have upgraded has had at least one thing that needed attention. Not one has been clean.
That sounds worse than it is. Usually it is a module that behaves slightly differently, a header sitting a few pixels off, or a plugin that needs an update. The sites range from a computer repair shop to an online store with 443 products to a senior care company, and they all landed somewhere on that scale.
Plan around "at least one thing." Expect a clean upgrade and the first problem feels like a disaster. Expect to fix two or three, and it is just Tuesday.
The Migration That Took the Whole Site Down
The worst of the Divi 5 migration issues I have run into happened in June, on a senior care company's site. I installed Divi 5 on the staging copy and the site showed a critical error. Not a broken page. The whole thing, gone, would not load.
Two old pieces were responsible. One was a plugin called Divi Team Members that was not compatible with Divi 5, and which had also been running without an active license for who knows how long. The other was a small custom script someone had added years earlier to clear the site's cache. I turned both off and Divi 5 installed and ran cleanly.
Total damage: about twenty minutes, on a copy of the site that no customer could see. Had that been the live site on a weekday morning, it would have been a very different phone call. It is the best argument for staging I can give you, and it is why my migration process puts the staging copy before anything else.
Most people don't realize how much old, unmaintained stuff is sitting in a site that has been running for five or six years. Nobody thinks about the plugin they installed in 2019 to do one small thing on one page. Divi 5 thinks about it.
Plugins Are Still the Biggest Category, by a Lot
Most problems worth writing down trace back to a plugin, in one of two flavors. The first is the one above: the plugin is genuinely incompatible and it breaks something, loudly. Those you find fast, because the site tells you.
The second is quieter and it catches more people. The plugin works fine, nothing looks broken, but it has not been updated for Divi 5 yet. Pages using it keep running the old way. They still work, they just do not get any of the speed improvement you upgraded for. You can live with that if it is one page. If it is your whole product catalog, you need a different plugin, and that is a real decision with real cost.
The good news, and it is the biggest change since March, is that the third-party plugin developers have largely caught up. Back in the spring, waiting on an add-on was a real reason to delay a migration. It mostly is not anymore. The popup, module pack, social sharing and table of contents plugins I see on most client sites all ship Divi 5 versions now, and the ones I watched hold sites back in March have shipped since. Small one-developer plugins are still a coin flip, and anything abandoned is a no.
When the Header Disappears From Half Your Pages
In April I migrated an online store with a few hundred products. Six pages into testing, three of them looked wrong in exactly the same way: the header had collapsed, the hero banner was gone, and the breadcrumbs had vanished. On one page the icons had given up entirely, so the search button showed the letter U and the little dropdown arrows in the menu showed the number 3.
The pattern told the story. The three good pages each had their own layout, built section by section. The three bad ones were all driven by Theme Builder templates, which is Divi's way of designing one header or one archive layout and applying it across many pages at once.
The fix was mercifully boring. Open each of those templates, change something trivial, save it again. The pages come back. Two minutes of work once you know that is the answer, and a bad afternoon if you do not.
What I want you to take from this is not the fix, it is the shape of the problem. Templates are the part of a site you almost never open. If a migration knocks one loose, you will not notice it on your home page. You will notice it when a customer tells you your shop page looks broken.
My Own Menus Quit, Twice
I upgraded my own site at the end of June and my dropdown menus stopped working. Hover over Services, nothing. Hover over Products, nothing. The menu items were all still there in the editor and they simply would not appear on the site.
It turned out the menu was never broken at all. It was opening correctly every time, just underneath the page content instead of on top of it, so nobody could see it. One setting in the header, changed, done. Finding it took me two afternoons, and I wrote up the whole hunt for anyone chasing the same thing.
The part that matters here is what happened four days later. The menus went out again, same cause, on a site I had already fixed. Something in a Divi update put the setting back. I set it a second time, more firmly, and it has held ever since.
I'd let one occurrence rest. Two says check your site again a week after the migration, and again after the next Divi update. This was also the only one of these Divi 5 migration issues that reached a live site, and it reached mine because I was the client.
Faster Is Not Automatic, and One Site Got Slower
The speed story is real. On the computer repair shop's site, which had no page caching at all, GTmetrix went from an F at 21 percent to a C at 72 percent, and Google's PageSpeed desktop score went from 22 to 85. That was the Divi 5 upgrade by itself, nothing else changed. We added caching afterward and pushed it further.
Now the honest half. On the senior care site, the numbers went the wrong way on launch night. GTmetrix dropped from a B at 80 percent to a C at 60 percent, and the PageSpeed mobile score fell from 37 to 27. I measured it, I did not like it, and I said so to the client that evening rather than sending a cheerful summary.
That site's caching was the likely cause. A migration invalidates everything a caching plugin has stored, so the first measurements after a cutover are taken on a site that is effectively cold, and a caching setup tuned for the old version may need revisiting for the new one. The lesson I took is to measure before, measure right after, and then measure again a few days later once the site has settled. One reading on launch night is not an answer.
Whatever the marketing says, treat the speed gain as likely rather than guaranteed, and make somebody responsible for checking it. If nobody checks, a site that got slower stays slower.
The Migration Also Finds Problems That Were Already There
This surprised clients more than anything else. When I test every page of a site, I turn up things that have been broken for years and have nothing to do with Divi.
On one home services site, 17 images across three pages were loading from an old web address that no longer answers. Team photos, partner logos, certification badges, all of them pointing at a website that was replaced long before I got there. They had never been copied into the site itself. Divi 5 did not do that, but the migration test is what found it.
Elsewhere I found images with no alternative text, which matters for accessibility and for search. On my own site I found placeholder photos from a design template I imported years ago and never swapped out. Slightly embarrassing, quickly fixed.
What struck me going through these is that a migration ends up being a site audit whether you wanted one or not. You come out with a cleaner site than you went in with, which is worth something on its own.
Day One Is Not the Finish Line
Every site I have migrated went live in Divi's backward compatibility mode, which is the safety net that keeps existing pages rendering the way they always did. That is the right call on launch day and I would not do it differently.
It also means the full benefit of Divi 5 arrives later, when those pages are rebuilt to use the new system. That is a separate project with its own budget and its own schedule. Anyone telling you the migration alone modernizes the whole site is skipping a step, and it is worth knowing that before you sign off on one.
What This Adds Up To
All six sites are on Divi 5. None went back. I still think the upgrade is worth doing, and none of these Divi 5 migration issues would change that recommendation.
But look at where these problems landed. One site would not load. One had three pages visibly broken. One got measurably slower on launch night. Every one of those was found and dealt with on a copy of the site, before a customer ever saw it, because the process I follow tests on staging first and never touches the live site until the copy is clean.
If you are comfortable making a full backup, standing up a staging copy, working through every page of your site, reading what the compatibility check tells you, and rolling the whole thing back if it goes sideways, then you can absolutely do this yourself. My migration checklist lays out the steps and I give it away.
If any part of that sentence made you uneasy, that is the honest signal to hand it to somebody. It is not that the migration is hard. It is that the recovery is hard, and you only need recovery on the day you skipped the staging copy.
I run these as a flat rate, with the testing and the fixes included. If you would rather work out where you stand first, the Divi 5 upgrade assessment will tell you whether a do-it-yourself migration is reasonable for your site. Either way, do not press Migrate on your live site to see what happens. That is the one mistake on this list that costs real money.




0 Comments