The WordPress Plugin Audit You Should Do Before Moving

Ask a WordPress site owner how many plugins they run and the answer is often a guess. Ask what each one does and the guess gets less confident. That gap matters, because when you move a website away from WordPress, plugins do not come with you. Their behavior has to be understood and then deliberately recreated, replaced or dropped.

Start with a plain list

From the Plugins screen in the WordPress dashboard, record every plugin, active or inactive, with its name and version. Inactive plugins still deserve a line, because someone may have deactivated a feature that the business still expects to exist. Add must-use plugins and any code in the theme's functions file that behaves like a plugin, since those do not always appear in the main list.

Classify by what the plugin actually does

For each entry, write one sentence describing the visible or operational effect. Then place it into a category:

• Content structure: custom post types, custom fields, relationships between content.
• Presentation: page builders, sliders, galleries, shortcodes, layout blocks.
• Forms and data capture: contact forms, quote requests, newsletter sign-ups.
• Commerce: carts, payments, subscriptions, memberships, coupons.
• SEO and metadata: titles, descriptions, sitemaps, canonical tags, redirects.
• Operations: caching, backups, security hardening, image optimisation, email delivery.
• Integrations: CRM sync, analytics, chat widgets, booking tools.

This classification is useful because each group migrates differently.

Decide the fate of each plugin

Once classified, give every plugin one of four outcomes.

Rebuild applies when the plugin defines how content is structured or displayed. Custom post types and fields become the content model in the new system. Layout blocks become reusable components.

Replace with a service applies when a dedicated tool does the job well, such as a hosted form provider or an established booking platform. The website then connects to that service rather than reimplementing it.

Absorb into the platform applies to things modern frameworks and hosting handle natively, such as sitemaps, image resizing or page caching.

Retire applies to plugins nobody can explain, duplicate functionality or features the business no longer uses. Retiring is a legitimate outcome, but confirm it with whoever owns that part of the business before deciding.

Pay special attention to shortcodes

Shortcodes are text tokens inside post content that a plugin expands into something else on the page. When the plugin disappears, the token shows up as raw text. Search the database export or use a search plugin to find every shortcode in use, count how many pages use each one, and plan how those pages will render after the move.

Capture the settings, not just the names

Some plugins hold important configuration: redirect rules, form notification recipients, tax settings or schema markup choices. Export or screenshot those settings now. They are easy to lose and tedious to reconstruct from memory.

Watch for data that lives only in plugins

Form entries, membership records and order histories may be stored in plugin-specific tables. Decide whether that data needs to move, be archived, or be exported for records, and involve whoever is responsible for privacy and retention before anything is copied.

What you end up with

A finished audit is a short spreadsheet with a name, a purpose, a category, an outcome and an owner for every plugin. It turns a vague worry about losing features into a list of decisions. It also makes any quote you receive more accurate, because the people scoping the work can see exactly what the site does today.