You migrated your WordPress site. The pages load, the admin works, and everything looks fine. Then you notice your forms stopped sending emails. Or your firewall plugin crashes the site. Or your translation editor refuses to load.
This happens because many WordPress plugins store domain names, server paths, API tokens, or license keys that are tied to a specific environment. When the site moves to a new host or domain, those stored values become invalid. The migration itself was successful, but the plugins need to be told about their new home.
This guide covers 30+ popular plugins across 11 categories that commonly need attention after migration. Each entry explains what breaks, why it breaks, and the exact steps to fix it. If you are still planning your migration, a tool like All-in-One WP Migration handles database serialization and URL replacement automatically, which prevents many of these issues. But some plugins store configuration outside the database or rely on external services that need manual reconnection regardless of which migration method you use.
Before you start working through this list, do these three things first. They resolve the majority of post-migration plugin issues:
- Verify your site URL. Go to Settings > General and confirm both WordPress Address and Site Address show the correct URL.
- Flush permalinks. Go to Settings > Permalinks and click Save Changes. You do not need to change anything. Just saving regenerates the rewrite rules, which fixes sitemap 404s and many routing issues.
- Purge all caches. Clear your caching plugin, server-level cache, CDN cache, and browser cache. Stale cached pages cause phantom issues that waste hours of debugging.
Security Plugins
Security plugins are the most likely category to cause critical failures after migration. They write server-specific paths into configuration files and use IP-based rules that do not transfer between environments.
Wordfence
What breaks: Wordfence writes an auto_prepend_file directive into .user.ini (or .htaccess) containing the absolute server path to its firewall file. After migration, this path is wrong on the new server, which causes a PHP fatal error that takes the entire site down. Additionally, any IP whitelists, blocklists, or country blocking rules tied to the old server become irrelevant.
How to fix it:
If the site is down with a fatal error, connect via FTP or SFTP. Open .user.ini in the WordPress root directory and remove or update the auto_prepend_file line. If you are not sure what the correct path should be, create a temporary PHP file with <?php echo __DIR__; ?> to find it.
Once the site loads, go to Wordfence > Firewall > Manage WAF and re-run the firewall optimization wizard. Then review all firewall rules, IP lists, and login security settings. If your domain changed, premium licenses need a new key generated from your Wordfence account.
Pro tip: Before taking your final backup, go to Wordfence > Firewall > Manage WAF and click “Remove Extended Protection.” This cleans up the .user.ini and .htaccess entries so they do not cause problems on the new server.
Sucuri Security
What breaks: Sucuri’s cloud WAF uses DNS-level proxying. After migration, the origin server IP changes, so the WAF proxy still points traffic to the old server. If the domain changed, the API key also needs regeneration.
How to fix it: Log into the Sucuri dashboard and update the origin IP to your new server’s IP address. If DNS changed, update those settings as well. Regenerate the API key if the domain changed (Settings > API Key). Clear Sucuri’s cache from their dashboard.
Solid Security (iThemes Security)
What breaks: Two-factor authentication codes become undecryptable because the encryption key is site-specific. Admins may see “Mobile App Two-Factor is temporarily unavailable.” IP-based lockout tables also reference the old server, potentially locking you out.
How to fix it: If locked out due to 2FA, use backup codes or email-based 2FA to log in, then go to your profile and click “Generate New Secret” to re-setup the mobile app. Clear the lockout tables (wp_itsec_lockouts, wp_itsec_temp) via phpMyAdmin or WP-CLI. Re-run the security onboarding wizard and rebuild the file change detection baseline.
All In One WP Security (AIOS)
What breaks: If “Rename Login Page” or “Cookie-Based Brute Force Prevention” was enabled, you get redirected to 127.0.0.1 when trying to log in. The cookie from the old domain is invalid on the new one. IP whitelists also block your new IP.
How to fix it: If locked out, add this to wp-config.php:
define('AIOS_DISABLE_COOKIE_BRUTE_FORCE_PREVENTION', true);
define('AIOS_DISABLE_LOGIN_WHITELIST', true);
Then connect via FTP and remove everything between # BEGIN All In One WP Security and # END All In One WP Security in .htaccess. After regaining access, reconfigure the firewall rules and update your IP whitelist. Remove the wp-config.php constants once settings are fixed.
Caching Plugins
Caching plugins store hardcoded paths and domain-specific configuration files. After migration, they almost always need a full cache purge and, in some cases, complete reconfiguration.
WP Rocket
What breaks: WP Rocket licenses are domain-bound. It also stores configuration files in wp-content/wp-rocket-config/ with domain-specific filenames, and writes cache rules to .htaccess with paths that may not match the new server.
How to fix it: WP Rocket usually detects the domain change and shows an admin notice saying “Regenerate WP Rocket configuration files now.” Click that button. For the license, go to your WP Rocket account > Websites tab, remove the old domain, then deactivate and reactivate the plugin. Clear all cache and verify .htaccess rules were regenerated correctly.
W3 Total Cache
What breaks: W3TC is the most common cause of white-screen errors after migration. It writes extensive .htaccess rules and creates multiple configuration files with hardcoded paths. Its aggressive caching can also mask other migration issues.
How to fix it: If you see a white screen, connect via FTP and rename wp-content/plugins/w3-total-cache/ to disable it. Delete the residual files: wp-content/w3tc-config/, wp-content/cache/, wp-content/db.php, and wp-content/object-cache.php. Clean .htaccess of all W3TC-generated rules. Reactivate and reconfigure from scratch on the new server.
LiteSpeed Cache
What breaks: Object cache connections (Redis or Memcached) use server-specific host, port, and socket path settings that change between servers. QUIC.cloud CDN configuration also needs updating.
How to fix it: Purge all cache from LiteSpeed Cache > Toolbox > Purge All. If using object cache, go to LiteSpeed Cache > Cache > Object and update the host and port for Redis or Memcached on the new server. Update QUIC.cloud CDN domain settings if applicable.
WP Super Cache
What breaks: The supercache directory path is hardcoded in .htaccess mod_rewrite rules. If PHP runs as a different user than the web server on the new host, cache files may not be readable.
How to fix it: Delete all cache files in wp-content/cache/supercache/. Go to WP Super Cache settings and click “Delete Cache.” Verify .htaccess rules have correct paths and check that wp-content/cache/ has 0755 permissions.
Page Builders
Page builders generate and cache CSS files with hardcoded URLs. Standard database search-and-replace catches most references, but generated asset files often need separate attention.
Elementor
What breaks: Elementor generates CSS files with hardcoded absolute URLs for background images and assets. These files live outside the database, so database search-and-replace does not catch them. Background images may appear broken and layouts can look wrong.
How to fix it: Go to Elementor > Tools > Replace URL. Enter the old site URL and the new one, then click Replace. This catches URLs that database-level tools miss. After that, go to Elementor > Tools > Clear Files & Data > Regenerate Files to rebuild all cached CSS. Clear all server and browser caches.
Oxygen Builder
What breaks: Oxygen uses cryptographic signatures on shortcodes. After migration, the signatures are invalid because they were generated using site-specific keys. This causes broken layouts and missing content.
How to fix it: Go to Oxygen > Settings > Security tab and click “Re-sign All Shortcodes.” Select all relevant post types and run the process. Then clear the CSS cache from Oxygen > Settings.
Divi
What breaks: Divi requires an Elegant Themes username and API key for updates and layout packs. After a domain change, the license association needs updating. Static CSS files may also contain old domain references.
How to fix it: Go to Divi > Theme Options > Updates and re-enter your credentials. Then go to Divi > Theme Options > Builder > Advanced > Static CSS File Generation and click “Clear” to regenerate. Note that Elegant Themes may charge a 30% fee for domain changes on licenses, though this is usually waived for same-domain host migrations.
SEO Plugins
Yoast SEO, Rank Math, and All in One SEO
All three major SEO plugins share the same core issues after migration:
Sitemaps return 404. This is the most common issue and is almost always fixed by flushing permalinks (Settings > Permalinks > Save Changes). No settings need to change. Just re-saving regenerates the rewrite rules that make sitemap URLs work.
Open Graph tags reference the old domain. Social sharing previews may show the old URL. Yoast and Rank Math update these automatically once the site URL is correct in Settings > General. Use the Facebook Sharing Debugger to force a re-scrape of your pages.
Google Search Console disconnection. If Rank Math or Site Kit was connected to Search Console via OAuth, the token is domain-bound and needs reconnection. For Rank Math, go to General Settings > Webmaster Tools > click “Reconnect.” For domain changes, add the new domain as a property in Search Console and resubmit your sitemap.
Schema markup with stale URLs. Structured data may still reference the old domain in URLs. Verify using Google’s Rich Results Test after migration.
Multilingual Plugins
WPML
What breaks: WPML licenses are registered per domain. After a domain change, the site key is invalid, which blocks updates and Translation Management features. WPML also detects URL changes and shows a migration wizard. If this is dismissed or missed, translations and the Advanced Translation Editor can break. Menu location assignments for translated menus may also be lost.
How to fix it: When WPML detects the URL change, it shows a Migration Wizard on the dashboard. Click “Start Migration” and follow the prompts. Then re-register your site key: go to wpml.org/account/websites, enter the new site URL, generate a new key, and enter it in WPML > Registration. Flush permalinks, clear WPML caches from WPML > Support > Troubleshooting, and verify menu locations for all languages.
Polylang
What breaks: Posts may lose their language assignments, and translation relationships stored as serialized data can break if the migration tool did not handle serialization correctly. Language-specific URL structures (subdirectories or subdomains) also need reconfiguration for a new domain.
How to fix it: Flush permalinks. Go to Languages > Settings and verify your URL modification settings. If posts lost their language assignment, use Languages > bulk assign to reassign them. Verify all translation connections are intact.
TranslatePress
What breaks: TranslatePress stores translations in custom wp_trp_* tables. Translation strings that contain URLs will still reference the old domain. API connections to Google Translate or DeepL may also need re-verification.
How to fix it: Run a search-and-replace on the wp_trp_* tables for old domain references. Verify automatic translation API connections. Reactivate the license if the domain changed.
eCommerce
WooCommerce
What breaks: Payment gateway webhook URLs still point to the old domain. This is critical because missed webhooks mean missed payment confirmations. Stripe, PayPal, and Square all store webhook endpoints that need manual updating in their respective dashboards. If you use WooCommerce Subscriptions, it automatically disables all renewal payments when it detects a domain change as a safety measure. Checkout pages may also 404 if page IDs changed.
How to fix it:
- Flush permalinks immediately.
- Log into each payment provider’s dashboard and update webhook URLs. For Stripe: go to WooCommerce > Settings > Payments > Stripe > “Reconfigure webhooks.” For PayPal: update the IPN URL in your PayPal account. For Square: disconnect and reconnect via WooCommerce > Settings > Payments > Square.
- For WooCommerce Subscriptions: go to WooCommerce > Status > Tools and use the “Update Site Address” tool. This tells Subscriptions the new URL is legitimate and re-enables automatic payments.
- Go to WooCommerce > Settings > Advanced and confirm Shop, Cart, Checkout, and My Account pages are correctly assigned.
- Run a full test checkout in sandbox mode before going live.
Easy Digital Downloads
What breaks: If you sell software with EDD’s licensing system, customer license activations are tied to your site’s “home” URL. Domain changes can invalidate all issued licenses. Payment gateway webhooks also need updating.
How to fix it: Verify all EDD custom tables (wp_edd_*) migrated correctly. Update payment gateway webhook URLs. Check that the site URL in wp_options is correct. Test the full purchase flow end-to-end.
Form Plugins
Gravity Forms
What breaks: If your migration tool did not handle PHP serialized data correctly, all form configurations become unreadable. Forms appear to be “missing” even though the data is in the database. This happens because serialized strings include length values, and if a domain replacement changes the string length without updating the serialized format, PHP cannot decode the data.
How to fix it: Use a serialization-aware tool for any follow-up search-and-replace. All-in-One WP Migration handles serialized data automatically during migration, recalculating string lengths after every replacement. If forms are missing after using a different tool, run WP-CLI search-replace with the --precise flag or Better Search Replace with “Handle serialized data” checked. Then update reCAPTCHA keys (they are domain-specific) and review notification email settings.
WPForms and Contact Form 7
What breaks: Google reCAPTCHA keys are registered to specific domains. After a domain change, form submissions fail silently or show error messages like “There was an error trying to send your message.” Email delivery may also fail if the new server lacks proper mail configuration.
How to fix it: Go to google.com/recaptcha and register your new domain, then update the keys in your form plugin’s settings. For Contact Form 7: Contact > Integration > reCAPTCHA. For WPForms: WPForms > Settings > CAPTCHA. Test every form by submitting and verifying that emails arrive.
CDN and Performance
Cloudflare
What breaks: Cloudflare’s DNS A records still point to the old server IP. Page rules reference old URL patterns. The SSL/TLS mode may not match the new server’s configuration, causing redirect loops.
How to fix it: Update A/AAAA records in Cloudflare DNS to the new server’s IP. Purge the entire Cloudflare cache (Caching > Purge Everything). Verify the SSL/TLS mode matches your new server (use “Full Strict” if the new server has a valid SSL certificate). Update any page rules with new URL patterns. During migration, consider pausing Cloudflare or switching DNS records to DNS-only (unproxied) temporarily.
Jetpack
What breaks: Jetpack connects to WordPress.com via a token tied to the site URL. A domain change triggers an “Identity Crisis” where Jetpack thinks it is a different site. This breaks stats, backups, image CDN, social sharing, and all cloud-connected features.
How to fix it: Ideally, deactivate Jetpack on the old server before DNS propagation. After migration, go to Jetpack > My Jetpack and look for “Restore Connection” or follow the Identity Crisis prompts. If reconnection fails, fully delete Jetpack, reinstall, and reconnect from scratch. Re-authorize social media connections and update the downtime monitoring URL.
Google-Connected Plugins
Site Kit by Google
What breaks: Site Kit registers your URL with Google’s services during setup. After a domain change, it cannot find the site in its records. All connected modules (Analytics, Search Console, AdSense, PageSpeed Insights) disconnect.
How to fix it: Go to Tools > Available Tools > Reset Site Kit (or Site Kit > Settings > Reset). Reconnect all modules through the setup wizard. In Google Analytics, update the property’s default URL to the new domain. Add the new domain as a property in Google Search Console.
MonsterInsights and ExactMetrics
What breaks: OAuth tokens for Google Analytics are domain-bound. After domain change, the analytics connection breaks.
How to fix it: Go to the plugin settings and reconnect Google Analytics authentication. Verify the correct GA property is selected and test that pageviews are being recorded.
Email and SMTP Plugins
WP Mail SMTP and FluentSMTP
What breaks: SMTP credentials may be different on the new host. OAuth connections for Gmail and Office 365 include the redirect URI (your domain), so domain changes break authentication. The “From” email address may reference the old domain. SPF, DKIM, and DMARC DNS records are domain-specific.
How to fix it: Go to the plugin settings and verify or update SMTP connection settings (host, port, username, password). For OAuth-based connections (Gmail, Office 365), disconnect and reconnect. You may need to create a new OAuth app with the new domain as a redirect URI. Update the “From Email” address to match the new domain. Set up SPF, DKIM, and DMARC DNS records for the new domain. Send a test email from the plugin’s tools page.
License-Bound Plugins
Most premium WordPress plugins use domain-bound licensing. After a domain change, the site URL no longer matches the registered domain, and the plugin shows “Invalid license,” disables updates, and may disable premium features.
The fix is the same for almost every plugin:
- Before migration (ideal): Go to the plugin’s settings page and click “Deactivate License.”
- If the old site is gone: Log into the plugin vendor’s website and manually remove the old domain from your license.
- On the new site: Enter the license key and click “Activate.”
- If you hit the activation limit: Contact the vendor’s support to release an activation slot.
Here are the most common plugins that require license reactivation:
| Plugin | Where to manage |
|---|---|
| WP Rocket | Account > Websites tab |
| Elementor Pro | Account > Websites > Manage |
| Divi | Account > API Key (30% fee for domain changes) |
| Gravity Forms | Account > Manage Sites |
| WPForms Pro | Account > Manage Sites |
| Beaver Builder | Account > Domain Manager |
| ACF Pro | Simple reactivation in settings |
| WPML | wpml.org/account > Generate new key |
| Rank Math Pro | Account dashboard |
| WooCommerce extensions | Each extension has its own license |
| Wordfence Premium | Generate new key if domain changed |
| UpdraftPlus Premium | Account dashboard |
Quick-Reference Checklist
Use this checklist after every migration to make sure nothing falls through the cracks.
Do these first:
- Verify site URL in Settings > General
- Flush permalinks (Settings > Permalinks > Save Changes)
- Purge all caches (server, plugin, CDN, browser)
- Check
.htaccessand.user.inifor hardcoded server paths
Then work through each category that applies to your site:
- Security: fix firewall paths, clear lockout tables, update IP lists
- Caching: purge everything, regenerate configuration files
- Page builders: run URL replacement tools, regenerate CSS
- SEO: verify sitemaps load, resubmit to Search Console, check Open Graph
- Multilingual: complete migration wizards, re-register site keys
- eCommerce: update payment webhook URLs, fix Subscriptions, test checkout
- Forms: update reCAPTCHA keys, test submissions and email delivery
- CDN: update origin IP, purge edge cache, verify SSL mode
- Google plugins: reset and reconnect all modules
- Email: verify SMTP settings, reconnect OAuth, set up DNS records
- Licenses: reactivate all premium plugin licenses
Not every plugin on this list will apply to your site. Focus on the ones you actually use, starting with security and caching since those are most likely to cause visible failures.
If you are planning a migration and want to avoid as many of these issues as possible, All-in-One WP Migration handles the database transfer with full serialization support, which prevents the data corruption issues that affect plugins like Gravity Forms and Polylang. For the plugins that rely on external services, API tokens, or domain-bound licenses, the steps above are necessary regardless of which migration tool you use.