1. Assessing Your WordPress Site

Why this gate matters

Most failed migrations start with a weak audit. If you do not know exactly what WordPress is doing today, you cannot design a reliable replacement.

1.1 Inventory your current site

Create a migration spreadsheet and capture:

• Content types: posts, pages, CPTs, landing pages
• Taxonomies and tag systems
• Media footprint: total files, total size, hot paths
• Authentication requirements and user roles
• Form inventory: destination systems, spam controls, retention needs
• Search behavior: what fields are searchable, what relevance means
• Email flows: transactional, marketing, webhook triggers
• Editorial workflows: drafts, approvals, scheduling, preview paths
• Editor technology: Gutenberg blocks, classic editor, or page builder
• Custom field systems: ACF, Meta Box, Pods, custom post meta
• Navigation system: classic menus, block theme navigation, custom nav tables
• SEO system: which plugin owns metadata and canonicals, where it is stored

Gutenberg and page builder triage

Before you decide on a migration approach, determine which of these describes the majority of your pages:

• Gutenberg blocks: content is mostly portable, because blocks are stored in post_content and can be parsed and transformed.
• Classic editor: content is usually HTML with shortcodes and is portable with cleanup.
• Page builder: content and layout are often bound together. Expect higher migration cost, partial portability, or a manual rebuild.

If a page builder dominates the site, you should also identify:

• How much content is truly editorial text vs layout instructions
• Whether the builder stores critical content in custom meta keys
• Whether pages render acceptably if you disable the builder

SQL examples for inventory

-- Post counts by type and status
SELECT post_type, post_status, COUNT(*)
FROM wp_posts
GROUP BY post_type, post_status
ORDER BY post_type, post_status;

-- Taxonomy usage
SELECT t.taxonomy, COUNT(*) AS relationship_count
FROM wp_term_taxonomy t
GROUP BY t.taxonomy
ORDER BY relationship_count DESC;

-- How many menu items exist (classic menu system)
SELECT post_type, post_status, COUNT(*)
FROM wp_posts
WHERE post_type = 'nav_menu_item'
GROUP BY post_type, post_status;

1.2 Plugin audit

Classify every plugin into one of three buckets:

• Core functionality: auth, forms, SEO, caching, content
• Nice-to-have: small UX enhancements
• WordPress-specific crutch: shortcode builders, page builders, meta-box hacks

Flag risk conditions:

• Plugins that execute arbitrary or dynamic PHP
• Plugins not updated recently
• Plugins with known vulnerability history
• Single-vendor lock-in where data is stored in proprietary formats
• Plugins that own content rendering (page builders, block packs, custom shortcodes)
• Plugins that change URLs or rewrite content output (SEO, caching, multilingual)

Plugin scoring model

Score each plugin from 1 to 5 on:

• Business criticality
• Replacement difficulty
• Security risk
• Data portability

High criticality plus high replacement difficulty becomes a discovery spike before migration commitments.

1.3 Is migration worth it?

Use a simple decision gate:

• Mostly content with predictable features: proceed
• Site behaves like an app stitched from plugins: proceed with caution and phased delivery
• Heavy WooCommerce or complex membership billing logic: run a separate commerce-first migration plan

Red flags that require architecture review

• Multiple plugins writing to the same custom fields
• Heavy shortcode content with nested shortcode blocks
• Custom PHP theme logic that mixes presentation and business rules
• Cron jobs with side effects and no observability
• Page builder pages where the primary content lives inside builder meta fields
• SEO metadata scattered across multiple plugins or custom theme code

Deliverables before leaving this section

• Full inventory sheet with owners and replacement targets
• Plugin risk matrix
• URL and SEO baseline export
• Go or no-go decision with scope boundaries

When to stop and ask for help

If your audit shows heavy reliance on a page builder, complex multilingual logic, custom commerce, or deep theme PHP behavior that affects business workflows, you should involve a migration partner early.

For complex migrations where content and layout are tightly coupled, BeyondWP can handle planning and execution.