Clients call asking if I can “migrate” their Divi site to Gutenberg. Technically, yes. But I don’t. Here’s why rebuilding from scratch is faster, cheaper, and gets better results.
The Divi Problem
Divi has been around for years and powers millions of WordPress sites. It’s popular for a reason—it gave people design flexibility when WordPress couldn’t. But that flexibility comes with serious technical debt.
Divi stores content in a proprietary format. Your content isn’t stored as standard WordPress content. It’s wrapped in Divi shortcodes and stored in a custom format that only Divi understands. This means you’re locked into using Divi forever, or you face a painful extraction process.
Performance issues are baked into the architecture. Divi loads a lot of CSS and JavaScript on every page, whether you need it or not. Even with caching and optimization, Divi sites tend to be slower than they should be. This isn’t just about load time—it affects SEO, user experience, and conversion rates.
The structure reflects old decisions. Most Divi sites were built years ago using approaches that made sense then but don’t anymore. Mobile-first design wasn’t standard. Accessibility wasn’t a priority. Performance wasn’t measured the same way. The site reflects those old assumptions in ways that are hard to fix without starting over.
Why “Migration” Doesn’t Work
When people say “migrate my Divi site,” they usually mean “convert my Divi content to Gutenberg blocks while keeping everything else the same.” This sounds reasonable, but it creates more problems than it solves.
You can’t just convert Divi shortcodes to Gutenberg blocks. There’s no clean one-to-one mapping. Divi’s structure is fundamentally different from Gutenberg’s. Even if you use a migration plugin to convert sections to blocks, you end up with messy, non-standard blocks that don’t work like native Gutenberg.
You’d still need to rebuild the layouts anyway. The conversion gives you content wrapped in blocks, but those blocks don’t behave like proper Gutenberg blocks. You can’t use the responsive controls. The spacing is wrong. The structure doesn’t make sense. You end up rebuilding the layouts manually, which is most of the work.
Migration maintains the bad structure. The biggest problem with Divi sites often isn’t Divi itself—it’s the decisions made when building the site years ago. Migration preserves those decisions. You’re bringing forward the technical debt, the structural problems, and the outdated approaches. You get a site that’s technically “on Gutenberg” but still fundamentally broken.
It’s still slow. Even after migration, you’re working around legacy structure and dealing with converted content that wasn’t designed for modern WordPress. The performance problems don’t magically disappear—they’re just harder to fix because you’re constrained by the migrated structure.
You waste time trying to preserve the wrong things. Migration projects spend weeks trying to preserve layouts, spacing, and styling that should be redesigned anyway. Time that should be spent solving user problems gets spent reverse-engineering old Divi configurations.
Why Rebuild Is Better
Clean slate means better decisions. When you rebuild, you start by asking what the site actually needs to do. What are users looking for? What actions should they take? What content matters? You’re not constrained by what Divi did five years ago—you’re building for what works now.
Modern structure from day one. You build with mobile-first responsive design. You use semantic HTML. You think about accessibility. You optimize for performance. You make decisions based on current best practices, not historical constraints.
Better performance automatically. A properly built Gutenberg site is faster than a Divi site, period. You’re only loading what you need. The CSS is cleaner. The JavaScript is minimal. The HTML is semantic. These aren’t optimizations you add later—they’re baked into how you build.
Not limited by old decisions. You can reorganize content properly. You can simplify navigation. You can remove pages that don’t serve users. You can fix information architecture issues that were masked by Divi’s visual flexibility. You’re solving the actual problems, not just changing the technology.
Easier to maintain long-term. A clean Gutenberg build uses standard WordPress functionality. Your client can edit content without breaking things. Other developers can work on it without learning Divi. Updates don’t break the site. It’s just cleaner, simpler, and more maintainable.
The Real Timeline
Here’s what actually happens with each approach:
Divi “Migration” Attempt:
- Week 1-2: Research migration plugins, test approaches, realize none work well
- Week 3-4: Manual conversion of content, fighting with converted blocks
- Week 5-6: Rebuild layouts that didn’t convert properly (most of them)
- Week 7-8: Debug spacing, responsive issues, performance problems
- Result: 6-8 weeks of work, mediocre site that’s “technically” Gutenberg but feels wrong
Clean Rebuild:
- Week 1: Content audit, information architecture, decide what to keep
- Week 2: Build structure, create templates, set up responsive system
- Week 3: Add content, build pages, test and refine
- Week 4: Polish, performance optimization, launch
- Result: 3-4 weeks of work, better site built for today’s needs
The rebuild is faster AND produces better results. This seems counterintuitive, but it’s true. You’re not fighting against old structure—you’re building new structure correctly.
What Rebuilding Actually Means
Rebuilding doesn’t mean starting from zero or losing everything. Here’s what actually happens:
Content is preserved. Your blog posts, pages, and custom post types come with you. These are stored in the WordPress database and aren’t Divi-specific. You’re not rewriting content—you’re just presenting it better.
Good design patterns transfer. If your Divi site has a hero section that works, you build that in Gutenberg. If it has a testimonial layout that converts, you recreate that. You’re not throwing away what works—you’re implementing it properly.
Core pages get rethought. Your homepage, about page, and service pages probably need updating anyway. This is an opportunity to improve messaging, update positioning, and fix structural issues. You’re not just preserving old pages—you’re making them work better.
Navigation gets cleaned up. Most Divi sites have navigation that grew organically over years. Rebuilding is the chance to simplify, reorganize, and make it easier for users to find what they need.
The site becomes yours. After rebuild, the site isn’t “the Divi site, but now in Gutenberg.” It’s a properly built WordPress site that happens to use Gutenberg. You own the structure, understand the code, and can modify anything.
Case Study: Real Client Example
I recently worked with a client who had a Divi site that had been built and modified over three years. The site was slow, hard to update, and didn’t work well on mobile. They asked about migrating to Gutenberg.
Previous developer’s approach: Six months of trying to “fix” the Divi site with optimization plugins, caching, and code modifications. The site was marginally faster but still fundamentally the same. Cost: ongoing monthly retainer for six months.
My approach: Three weeks to rebuild from scratch. We kept all the blog content, simplified the service pages, improved the information architecture, and built it properly in Gutenberg. The new site loads in under 2 seconds (the old site was 6+ seconds), works beautifully on mobile, and the client can update it themselves.
Client quote: “I wish we’d done this two years ago instead of trying to fix the Divi site.”
When Rebuilding Doesn’t Make Sense
To be fair, there are situations where rebuilding might not be the best approach:
Tiny budget with zero flexibility. If you literally cannot afford more than $500 and need something done this week, then maybe a quick migration plugin is your only option. But understand you’re getting exactly what you pay for.
Site is barely used and doesn’t matter. If this is a legacy site that gets 10 visitors a month and just needs to exist, then sure, run a migration plugin and move on. Don’t invest in rebuilding something that doesn’t matter.
Extremely complex custom functionality. If your Divi site has thousands of dollars of custom development that’s deeply integrated with Divi’s structure, rebuilding might require rewriting all that custom code. In this case, you need to weigh the cost of recreating custom functionality against the benefit of a clean foundation.
But for most business sites—5 to 50 pages, standard functionality, needs to work well and be maintainable—rebuilding is the right answer.
The Honest Answer
When clients ask “Can you migrate my Divi site?” I could say yes and charge them for weeks of frustrating work that produces a mediocre result. Instead, I tell them the truth: migration is possible but rebuilding is better.
This isn’t about maximizing billable hours. A rebuild is actually less total time than a proper migration attempt. It’s about doing the work that actually solves the problem rather than just checking a box.
Your Divi site served its purpose. It gave you a website when you needed one, with the tools that were available then. But now you need something better—something faster, more maintainable, and built for how WordPress works today.
That’s not a migration. That’s a rebuild. And that’s okay.
Ready to rebuild your site the right way? Let’s talk about what your site actually needs and how long it really takes.