Divi to Astro: a practical migration guide

You can move a Divi website to Astro without throwing away its content or redesigning the business. WordPress can remain the place your team edits, while Astro supplies the public layouts and interactive features.

Astro is a framework for building websites from components, HTML, CSS, and the JavaScript individual features need. Moving to it is a frontend rebuild. The Divi-specific question is which content and dependencies you’re rebuilding from: Divi 4, native Divi 5, or a site containing both newer layouts and legacy modules.

Get that distinction right first. It affects how you recover content, preserve shared designs, estimate replacements, and decide whether an upgrade would solve the problem with less work.

Identify the Divi version and the content behind each page

Record the active theme, any child theme, the Divi Builder plugin if installed separately, and the versions of module add-ons. Check Appearance > Themes and Plugins > Installed Plugins, then inspect representative pages in the editor. A version number alone doesn’t describe every saved layout.

Divi 4 stored layouts using shortcodes. Divi 5 introduced a different storage format. Elegant Themes describes the change in its explanation of Divi 5 content storage. Advice about stripping Divi shortcodes cannot be applied indiscriminately to native Divi 5 content.

Keep a complete database and file backup and a working source copy. Include Divi Library items, Theme Builder templates, media, and custom module code in the investigation. Recovering only the visible page text misses shared items and the rules that determine which layout visitors see.

If the site already uses the Divi 5 Migrator, review its compatibility report. The vendor’s migration instructions place it at Divi > Divi 5 Migrator and describe a scan covering content and shared design resources. Use the report to identify dependencies. Running a Divi upgrade is not a prerequisite for planning Astro.

Divi 5 or Astro: decide which workflow you want

A Divi upgrade keeps the site within Divi’s visual building system. An Astro rebuild creates a new public implementation and connects it to an agreed editing workflow. These projects may address different problems.

Improving Divi is worth evaluating when the team likes its visual editor and regularly creates new layouts. Astro becomes more attractive when the team wants established templates, clearer content controls, and a public site maintained separately from the builder.

The potential benefits are specific: reusable components, deliberate control over page assets, and editing fields named around the business. A prebuilt Astro deployment can serve published pages without generating each request through WordPress. The developer still has to implement those choices well.

Compare the current site, a reasonable Divi improvement, and the proposed rebuild using the same important page. Include the form, fonts, images, tracking, and third-party services. Check the editor’s work separately from visitor performance. A better page score doesn’t show whether creating a campaign became easier.

For a loading or editing conflict, check Divi > Support Center > Safe Mode where available in the installed version. Elegant Themes’ plugin-conflict instructions describe a diagnostic mode that disables plugins and customizations for your logged-in session without changing the site for visitors. Record which symptom disappears, then investigate the responsible dependency on staging. A successful Safe Mode session helps narrow a repair; it is not a visitor-performance benchmark.

Include support costs too. Retiring builder dependencies may remove subscriptions or maintenance work, but the WordPress installation, Astro code, hosting, and publishing connection still need someone responsible for them.

Understand what a legacy-module warning means

Divi 5’s backward compatibility can keep unsupported older modules running through the Divi 4 framework. The vendor’s compatibility guidance explains that these pages retain legacy dependencies and don’t receive the full performance benefit of a native Divi 5 page.

Treat the warning as a starting point for an inventory. Record the module name, provider, installed version, affected URLs, and its purpose. Check the provider’s current support information before assuming a warning from an older release still applies.

For an Astro migration, the useful question is what the module does. A project filter may select records by service, paginate results, and display an empty message. A form may send an email and register a lead elsewhere. Those behaviors need replacements whether the source module is native or legacy.

Group repeated use: one custom filter on twenty pages might need one reusable implementation. Several unrelated modules can require separate work. If a feature has no clear owner, retain its source and investigate it before agreeing to retire it.

There is no need to label a functioning legacy module a disaster. It may be an acceptable temporary dependency while an upgrade or rebuild is planned.

Move Divi content into fields your team understands

For Divi 4 pages, inspect the shortcode structure rather than removing every bracketed string. Content may be nested inside sections, rows, and modules, with useful values stored in attributes. Keep links, image references, and relationships alongside the visible prose.

For Divi 5, inspect the actual saved data and export from the installed version. Its storage change does not turn a Divi export into an Astro component. Divi Library and Theme Builder exports are useful source material and recovery aids, but the new templates need their own implementation.

Map modules by purpose. The following is a proposed content model, not the result of an automated conversion:

Imagine a page with three Blurb modules linking to services. Copying them as three anonymous blocks preserves today’s page. Giving each service a name, summary, image, and URL also lets the team reuse that information in navigation or other listings. Choose the structure around the next edit, not only the initial copy.

Use bulk conversion only after reviewing representative examples. Unknown modules should produce a review item, not disappear from the output. Reconcile text, media, links, and section order against the source, then check that the mapped content remains editable.

Keep the Divi design, including shared templates

You can preserve the visual design while replacing its implementation. Write a short brief identifying what should match and any deliberate changes. Include typography, content widths, spacing, imagery, animation, mobile navigation, and responsive behavior.

Check Divi > Theme Builder as well as individual pages. Headers, bodies, footers, and template assignments can determine the final result. Elegant Themes’ Theme Builder documentation describes template management and assignments. Capture the actual inclusions, exclusions, and global items in your installation.

A global header should become a maintained site layout. A campaign-specific header needs its own selection rule. A Post Content area should render the page’s content once, without accidentally duplicating a heading already supplied by the new template.

Distinguish shared design from shared content. A preset can describe how a button looks; a global contact section may also share its text and destination. Decide what should update everywhere and where editors need local values. Recreating the screenshots while losing those relationships makes later editing harder.

Compare the old and new page at the same width with the same content. Check open menus, expanded accordions, focus states, form errors, and reduced-motion behavior where animations are used. Long titles, missing images, and extra list items help reveal whether the new components work beyond one carefully chosen screenshot.

Rebuild the behavior behind forms and interactive modules

Divi’s Contact Form module has settings beyond visible fields, including destination email and success behavior. Use the relevant module documentation alongside the installed form when preparing its replacement.

Record every field, required value, spam check, notification recipient, and connected service. If the page embeds a separate forms plugin, identify that plugin and its processing rather than treating the entire form as a Divi feature.

The Astro implementation needs a receiving endpoint and server-side validation. Test valid and invalid submissions, delivery failure, and where the inquiry is stored. A success message should correspond to the agreed handling of the submission. Check the notification reaches the person who responds to leads.

For an Email Optin module, preserve the intended mailing list and confirmation flow. For a portfolio filter, preserve categories, selection rules, and empty results. For accounts, checkout, bookings, or protected content, scope the full visitor journey and authentication requirements. Static copies of the initial screens won’t complete those jobs.

Use the site’s actual features to decide what remains in WordPress and what moves. A plugin with a supported API may keep its backend role. A feature that only works through Divi rendering remains a dependency until its replacement is working.

Connect WordPress editing, preview, and publication

WordPress can provide content to Astro through its REST API or an added GraphQL integration. The Astro WordPress guide documents those options. Expose the fields the new templates need and keep private content and credentials out of public responses.

Choose a page containing shared content and a real business feature for the first working example. Let an editor change a service description, replace an image, select a permitted layout, preview a draft, publish it, and correct it. Try the same template on a second page with different content.

Agree which layout decisions editors can make. Astro doesn’t supply Divi’s visual builder. Fixed templates, reorderable sections, and entirely new page designs involve different amounts of implementation and ongoing developer involvement.

Publishing is part of the project. With prebuilt pages, WordPress changes need to trigger a successful build and deployment. Other rendering approaches need clear caching rules. Test scheduled content, deleted pages, changed slugs, and failed builds, and make sure the editor knows whether a change is live.

A familiar dashboard is useful only if the normal tasks work. The next-edit guide can help you review that handover.

What happens when you remove Divi?

Switching off Divi doesn’t convert its saved layouts into a new theme or an Astro site. The content format and the code that renders it are separate responsibilities. A Divi 4 shortcode layout, a native Divi 5 layout, and a page containing legacy modules can need different handling.

Keep the source intact until content, templates, and functional dependencies have been checked. Test removal on staging, including API responses and any WordPress-rendered pages still in use. If the new site asks WordPress to render Divi content, it still relies on Divi for that part of the request.

Review the child theme before replacing it. It may contain custom post types, shortcodes, or integration code that the backend still needs. Move required functionality to an appropriate maintained location rather than removing it along with styling.

Launch with the important URLs and workflows intact

Use the SEO migration inventory to track retained addresses, relevant replacements and intentional removals. Include the template or Divi module behind important pages, so URL checks do not hide unfinished functionality.

Keep public URLs where practical and redirect changed paths to relevant destinations. Check the new site’s titles, descriptions, canonicals, social images, structured data, sitemap, and internal links. WordPress SEO settings need to be carried into Astro’s output deliberately.

Before cutover, complete the final content sync and verify representative pages, forms, mobile behavior, keyboard navigation, and publishing. Compare performance under consistent conditions with production features included. Keep a recoverable copy of the previous site and document when and how to roll back.

After launch, confirm that an actual content update reaches the public site and that enquiries reach their destination. Remove Divi dependencies only once those checks establish that their work has been replaced. Keeping content and URLs supports continuity but doesn’t guarantee search rankings.

Our WordPress-to-Astro service covers the rebuild and publishing connection. To discuss your Divi site, send us the URL, what you want to preserve, and a page with an important or unusual module. If you have a compatibility report, its findings can help define the scope too.

Before comparing proposals, put those requirements into the rebuild project brief. The cost guide explains how templates, integrations and ongoing ownership affect the estimate.