Divi 5 Migration Prompt Pack

You are a senior WordPress technical lead and Divi specialist.

I am planning a migration from Divi 4 to Divi 5 for this site. I need a concise, practical readiness audit that a web agency or technical site owner can use to plan the migration and communicate risk to stakeholders.

1) SITE CONTEXT
- WordPress version:
- PHP version:
- Hosting type (shared/managed/VPS/other) and caching stack:
- Current Divi version and whether Divi 5 is already installed:
- Does the site use a child theme? If yes, describe what it customizes:
- Any known performance, SEO, or accessibility constraints that must not regress:

2) DIVI USAGE
- Approximate number of Divi-built pages:
- Use of Divi Theme Builder (headers, footers, templates, archive templates, etc.):
- Use of global modules and global presets:
- Use of dynamic content (ACF, Toolset, custom fields, etc.):
- Any usage of Divi’s legacy or deprecated modules:
- Any third-party Divi add-ons or modules:

3) CUSTOMIZATIONS
- Custom PHP (functions.php, mu-plugins, snippets) that touch Divi output:
- Custom JavaScript related to layout, animations, or interactions:
- Custom CSS frameworks or utility classes used alongside Divi:
- Any custom post types with Divi layouts:
- Any custom integrations that rely on specific HTML structure or classes:

4) BUSINESS CONSTRAINTS
- Allowed maintenance window(s):
- Recovery time objective (how long the site can be partially broken):
- Stakeholders who must approve the migration (roles, not names):

Using only the information provided, produce:

A. HIGH-LEVEL SUMMARY
- 3–5 bullet summary of overall migration risk (low/medium/high) and why.

B. RISK CATEGORIES
List risks under these headings. For each, give:
- Risk description
- Why it matters in a Divi 4 → Divi 5 migration
- How to confirm whether it is a real issue
- Recommended mitigation

Categories:
- Theme and child theme risks
- Plugin and Divi add-on risks
- Custom code risks (PHP, JS, CSS)
- Layout and UX risks
- Performance, SEO, and accessibility risks
- Operational/process risks (backups, staging, approvals)

C. PRIORITIZED MIGRATION ORDER
- Suggest an order in which to migrate sections or entire sites, based on risk and business impact.
- Call out any sections that should be delayed until later (and why).

D. STAKEHOLDER BRIEFING
Write a short, non-technical summary I can paste into an email or ticket to stakeholders, covering:
- Why we are migrating to Divi 5 now
- The main risks you identified (in plain language)
- How we will reduce those risks (staging, backups, QA)
- What stakeholders should expect during the migration window.

You are a senior WordPress DevOps engineer and Divi specialist.

I am preparing to migrate a site from Divi 4 to Divi 5 using Divi’s Migrator. I need a concrete, low-drama staging and backup plan that a small team or agency can actually follow.

1) BACKUP SETUP
- Current backup plugin(s) in use:
- Hosting-level backups available (yes/no, details):
- Backup frequency and retention:
- Date of last successful restore test and how it was tested:

2) STAGING / ENVIRONMENTS
- Do we have an existing staging site? If yes, how is it kept in sync with production?
- Is there a local development copy? If yes, how up to date is it?
- Any differences between staging and production (domains, caching, CDN, object cache, PHP settings, etc.):

3) ACCESS & ROLES
- Who can:
  - Trigger backups:
  - Restore backups:
  - Create or refresh staging:
  - Run Divi’s Migrator:
  - Approve changes (client, PM, etc.):

4) CHANGE WINDOW
- Preferred migration window (day/time and timezone):
- Any blackout periods where changes are not allowed:
- Expected traffic levels during the migration window (low/medium/high):

Using this information, produce:

A. STAGING STRATEGY
- Recommend whether to:
  - Create a new staging site, or
  - Reuse and refresh an existing staging site, or
  - Work locally first, then stage.
- Explain why this strategy fits the inputs above.
- Give a numbered checklist for setting up/refreshing staging before the migration.

B. BACKUP & ROLLBACK PLAN
- Describe exactly which backups to take and when, in relation to the migration (database + files).
- Provide a clear, step-by-step rollback plan that:
  - Restores the site to its pre-migration state.
  - Includes sanity checks after restore (front-end, forms, key funnels).
- Call out any gaps or risks in the current backup setup.

C. MIGRATION RUNBOOK
Create a concise, reusable runbook with:
- Pre-migration checklist (what to verify the day before and hour before).
- During-migration steps (what to do in staging and production).
- Post-migration checklist (what to verify before calling the migration complete).

D. TEAM COMMUNICATION NOTES
Write a short note I can share with the team that covers:
- Where we will run Divi’s Migrator (staging vs production).
- How we will back up and how to roll back.
- Who is on point during the migration window.
- What to do and who to contact if unexpected issues appear.

You are a senior Divi implementer experienced with Divi 5 and Compatibility Mode trade-offs.

I have a site that has been migrated to Divi 5 using Divi’s Migrator. Many layouts still rely on Compatibility Mode. I want a practical plan to reduce that dependency without breaking important pages.

1) COMPATIBILITY MODE STATUS
- Is Compatibility Mode currently enabled globally?
- Are there any per-page overrides or exceptions?
- Any attempts so far to disable or restrict Compatibility Mode? What happened?

2) LAYOUT INVENTORY
Describe, at a high level:
- Types of layouts in use (landing pages, blog posts, shop pages, archives, etc.).
- Examples of layouts that clearly break when Compatibility Mode is disabled (what breaks?).
- Examples of layouts that still look fine without Compatibility Mode.
- Any third-party Divi modules or add-ons that seem to depend on legacy behavior.

3) CUSTOM CODE & INTEGRATIONS
- Custom CSS that targets Divi-specific classes or markup:
- JavaScript that relies on specific Divi DOM structure or events:
- Any integrations (forms, tracking scripts, A/B testing) that may rely on legacy markup:

4) CONSTRAINTS
- Time available for cleanup per site (e.g. 2 hours, 1 day, multiple days):
- How strictly do layouts need to match existing designs (pixel-perfect vs “close enough”):
- Any pages or flows that are business-critical and must be handled with extra care:

Using this information, produce:

A. CLEANUP STRATEGY OVERVIEW
- Explain the recommended approach to reducing Compatibility Mode usage for this site.
- Call out which categories of pages should stay in Compatibility Mode for now, and which are candidates for early cleanup.

B. CLASSIFICATION FRAMEWORK
Provide a simple framework I can use to classify pages into:
- “Safe without Compatibility Mode”
- “Needs partial refactor”
- “Leave in Compatibility Mode for now”
For each category, describe:
- Typical symptoms
- How to test quickly
- Recommended action

C. PHASED CLEANUP PLAN
Propose a phased plan with concrete steps:
- Phase 1: Quick wins and low-risk pages.
- Phase 2: Medium complexity pages.
- Phase 3: High-risk or business-critical flows.
For each phase, include:
- Entry criteria (which pages to tackle).
- A numbered checklist for what to do on each page.
- Exit criteria (how I know the phase is complete).

D. TESTING CHECKLIST
Create a repeatable checklist I can use when toggling Compatibility Mode for a page or group of pages, covering:
- Visual layout checks
- Functional checks (forms, navigation, CTAs)
- Responsive checks (mobile/tablet/desktop)
- Performance and Core Web Vitals considerations (at a high level).

E. COMMUNICATION NOTES
Write a short note I can share with stakeholders that:
- Explains what Compatibility Mode is in plain language.
- Describes why we are trying to reduce reliance on it.
- Sets expectations about which pages may change slightly and why.

You are a senior QA lead for WordPress and Divi-based sites.

I have migrated a site from Divi 4 to Divi 5 using Divi’s Migrator. I need a focused, high-value QA checklist tailored to this site so we catch critical issues before we push to production.

1) SITE PRIORITIES
- List the primary conversion paths (e.g. lead forms, checkout, bookings, contact forms):
- List the top 10–20 pages by importance (home, key landing pages, pricing, product pages, etc.):
- Any pages that are especially brand-sensitive (must look perfect):

2) TECHNICAL DETAILS
- Custom post types that use Divi layouts:
- Use of Divi Theme Builder (headers, footers, templates, archives):
- Third-party integrations (forms, CRMs, payments, booking tools, marketing scripts, A/B testing tools):
- Any known structured data / schema requirements:

3) FRAGILE AREAS
- Pages with heavy animations, motion effects, or complex layouts:
- Known issues from previous theme/builder updates:
- Known performance or Core Web Vitals problems:

4) ENVIRONMENT
- Where QA will be done (staging vs local vs production shadow):
- Devices/browsers we care most about (e.g. iPhone Safari, Chrome desktop, etc.):

Using this information, produce:

A. PRIORITIZED QA CHECKLIST
Organize checks into these sections:
- Business-critical flows
- High-traffic and brand-critical pages
- Templates and global elements (headers, footers, theme builder templates)
- Forms, integrations, and tracking
- Performance and UX sanity checks

For each section:
- Provide a numbered checklist of specific things to verify.
- Include clear pass/fail criteria where possible.

B. QUICK SMOKE TEST
Design a very short (10–15 minute) smoke test I can run immediately after migration to catch show-stopper issues fast.

C. DETAILED PASS TEMPLATE
Provide a simple template I can copy into a ticket or doc to record:
- What was tested
- Who tested
- Date/time
- Findings and severity
- Go/no-go recommendation

D. CLIENT/STAKHOLDER SUMMARY
Write a short, non-technical paragraph summarizing:
- What we checked after the Divi 5 migration
- Whether we saw any major issues
- What will happen next (fixes, sign-off, deployment).

You are a senior Divi layout architect focused on maintainable, performant Divi 5 builds.

I have a specific layout that was migrated from Divi 4 to Divi 5 using Divi’s Migrator. I want to refactor this layout to use native Divi 5 modules and patterns, reduce reliance on Compatibility Mode, and improve maintainability without blowing up the design.

1) LAYOUT BASICS
- URL or clear description of the layout:
- Type of layout (landing page, long-form content page, product page, archive template, etc.):
- Business role of this page (lead-gen, sales, education, support, etc.):

2) CURRENT STATE
- Whether Compatibility Mode is currently required for this layout (yes/no/unknown, with details):
- Legacy or third-party modules used on this layout:
- Custom CSS applied (global vs page-specific, and what it targets):
- Custom JavaScript applied (animations, interactions, tracking workarounds, etc.):
- Any known quirks or bugs already present in this layout:

3) CONSTRAINTS
- How closely the refactored layout needs to match the current design (pixel-perfect vs “close enough”):
- Time budget for this refactor:
- Any performance, accessibility, or Core Web Vitals targets:

Using this information, produce:

A. MODERNIZATION STRATEGY
- Explain the overall approach to modernizing this specific layout.
- Call out which parts should stay as they are, which should be rebuilt with native Divi 5 modules, and which hacks or workarounds should be removed.

B. MODULE-BY-MODULE PLAN
Create a structured plan that:
- Lists major sections of the page.
- For each section, describes:
  - Current implementation (in plain language).
  - Recommended Divi 5-native implementation (modules, structure, patterns).
  - Any CSS/JS that can be simplified or removed.

C. IMPLEMENTATION CHECKLIST
Provide a numbered checklist I can follow when rebuilding this layout, including:
- Duplicating the layout safely (in staging or a draft).
- Rebuilding section by section.
- Keeping Compatibility Mode enabled or disabled at the right times.
- Sanity checks after each major change.

D. PAGE-SPECIFIC QA LIST
Create a short QA list tailored to this layout type, covering:
- Visual consistency (key above-the-fold elements, typography, spacing).
- Functional checks (forms, buttons, navigation elements).
- Responsive behavior (mobile, tablet, desktop).
- Performance and Core Web Vitals sanity checks, at a high level.

E. CLIENT/STAKEHOLDER NOTES
Write a brief summary I can share with a client explaining:
- What we changed and why.
- How the new layout will be easier to maintain.
- Any small visual differences they might notice and why those are acceptable or beneficial.