WordPress
Audit WordPress plugins before moving hosts
Inventory plugin purpose, support, data, cron and runtime requirements before a WordPress migration.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
Plugins that own data, scheduled tasks, caches, mail, security rules or external integrations deserve explicit testing. Remove abandoned and duplicate plugins before migration, but do not delete data-owning plugins until you understand their uninstall behaviour.
What this means in plain English
Plugins can own database tables, uploaded files, scheduled jobs, email settings and connections to outside services. Make a list before moving so each important feature has an owner and a test on the new host.
Remove abandoned or duplicate plugins carefully, but do not click delete until you understand its uninstall behaviour. Some plugins remove their own data when deleted. Test PHP compatibility and updates on a staging copy.
Which plugins create migration risk?
| Compatibility | PHP and WordPress version support |
|---|---|
| State | Custom tables, uploads, cron and external credentials |
| Criticality | Checkout, forms, login, SEO and backups |
A simple example
A booking plugin stores appointments in custom tables and sends reminders through WP-Cron. Copying only pages and uploads would miss the schedule. The migration plan identifies its tables, cron events, mail credentials and a real test booking.
What to do, step by step
1. Export a complete plugin inventory.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on compatibility: php and wordpress version support. Write the result down so you can compare it later.
2. Mark owner, purpose and last maintained version.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Test on a staging copy at the target runtime.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Verify every critical integration after cutover.
Finish by checking the result against criticality: checkout, forms, login, seo and backups. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
Record the exact working plugin versions before the move. Updating every plugin at the same time makes a migration failure much harder to trace.
Common mistakes and how to avoid them
Updating all plugins during DNS cutover.
This gives a misleading or unsafe result because it leaves out compatibility. A better approach is to export a complete plugin inventory, then check the result before making the change permanent.
Deleting a plugin that drops its tables.
This gives a misleading or unsafe result because it leaves out state. A better approach is to mark owner, purpose and last maintained version, then check the result before making the change permanent.
Assuming disabled plugins have no security or file impact.
This gives a misleading or unsafe result because it leaves out criticality. A better approach is to test on a staging copy at the target runtime, then check the result before making the change permanent.
Words explained
- WordPress
- A content management system that lets people edit pages and posts through an administration screen.
- plugin
- An add-on that gives WordPress extra features. Every plugin also adds code that must be updated and checked.
- cache
- A saved copy of work or a page that can be reused instead of generating it again.
- staging
- A private copy of a website used to test updates before changing the live site.
Quick checklist
- Export a complete plugin inventory.
- Mark owner, purpose and last maintained version.
- Test on a staging copy at the target runtime.
- Verify every critical integration after cutover.
Common questions
What is the simple answer?
Plugins that own data, scheduled tasks, caches, mail, security rules or external integrations deserve explicit testing. Remove abandoned and duplicate plugins before migration, but do not delete data-owning plugins until you understand their uninstall behaviour.
What should I check first?
Start with compatibility: php and wordpress version support. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Export a complete plugin inventory. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Updating all plugins during DNS cutover. Avoiding that one mistake makes the rest of the comparison much more trustworthy.