WordPress Migration Problems and How to Avoid Them

Moving a WordPress site to a new host sounds mechanical: copy the files, copy the database, change the DNS. In practice it is where a lot of sites quietly break, and the damage often shows up days later — a form that stopped delivering, a theme that lost its settings, traffic that drifts away for no visible reason.

Here are the failures that actually happen, what causes each, and the preparation that prevents most of them.

What to do before you copy anything

Most migration disasters are decided before anything is copied. Fifteen minutes of preparation removes the majority of them.

Record what the current site runs on. PHP version, MySQL or MariaDB version, WordPress version, and the active theme and plugin list. Your hosting panel shows the first two. You are going to need this when something behaves differently on the new host and you need to know what actually changed.

Take a full backup you can restore, files and database both, stored off the server. Not the migration archive itself — a separate copy you could fall back to if the archive turns out to be incomplete.

Lower your DNS TTL a day ahead. If the TTL on your A record is 24 hours, visitors will keep landing on the old server for a day after you switch. Drop it to 300 seconds the day before, and the cutover happens in minutes instead.

Plan for a content freeze. Anything published, ordered or commented on the old site after you copy the database will be lost when you switch. For a shop, that means orders. Pick a quiet window and stop writing during it.

PHP version mismatches, the quiet breaker

This is the quiet one. A site built years ago on PHP 7.0 lands on a host running PHP 8.2, and functions that were deprecated for a decade are now simply gone. The result is anything from a warning at the top of the page to a completely white screen.

The reverse happens too. Some hosts no longer offer older PHP versions at all, so an old theme with no update path has nowhere to run.

What to do:

• Match the old PHP version first, if the new host allows it. Migrate, confirm the site works, then upgrade PHP as a separate step. Changing two variables at once makes diagnosis much harder.
• Update themes and plugins before migrating, not after. Updates are easier to roll back on a site that is still working.
• Check what is still supported. The PHP supported versions page shows which releases still get security fixes. Running an unsupported version to keep an old plugin alive is a short-term answer with a real risk attached.

If you get a white screen after the move, turn on logging rather than guessing. Set WP_DEBUG and WP_DEBUG_LOG as described in Debugging in WordPress, reload the page, and read wp-content/debug.log. A fatal error names the exact file and line.

Email and forms stop working

Contact forms that silently stop delivering are the most expensive migration failure, because nothing looks broken. The site works, the form says “thank you,” and the enquiries quietly go nowhere for weeks.

Two separate things cause it.

Mail is still routed to the old host. If your email lives with your hosting account, moving the site without moving the mailboxes leaves your MX records pointing at a server you no longer control. Decide before cutover whether email moves too, and copy the mailboxes if it does.

The new host blocks PHP mail. Many hosts now restrict or disable the mail() function that WordPress uses by default, because it is heavily abused by spam. The fix is to send through authenticated SMTP instead — an SMTP plugin configured against your real mailbox, Google Workspace, Microsoft 365 or a transactional provider.

Whichever applies, test properly: submit every form on the site and confirm the message arrives in the real inbox, not a spam folder. Also check the messages that are easy to forget — password resets, WooCommerce order confirmations and admin notifications.

Files and database that did not fully transfer

Migration tools fail quietly when they hit a size or timeout limit. The symptom is a site that looks nearly right: most pages work, some images are missing, one section is empty.

Check these in order:

• Compare file counts in wp-content/uploads between old and new. A partial media transfer is common on large sites and invisible until someone opens an old post.
• Compare the row count of wp_posts in phpMyAdmin on both sides. If the new one is smaller, the database import truncated.
• Confirm the hidden files came across. .htaccess is hidden by default in most FTP clients, and without it your permalinks break and custom redirects vanish.

If an import keeps failing part way, the usual limits are max_execution_time, upload_max_filesize and max_allowed_packet. Most hosts will raise them temporarily if you ask. For a large database, importing the SQL file over the command line is far more reliable than phpMyAdmin, which is working inside a web request and will time out.

Old URLs, broken settings and serialized data

If the domain is changing, or you built on a temporary URL, the old address is now written into your database in thousands of places: post content, widget settings, theme options, image references.

The trap here is serialized data. WordPress stores plugin and theme settings as serialized PHP strings that record the length of each value. A plain find-and-replace in a SQL file changes the text but not the recorded length, and the setting becomes unreadable. The usual result is a theme that loses its options or a plugin that resets to defaults, with no error to explain it.

Use a tool that understands serialization — WP-CLI’s search-replace, or one of the established search-and-replace scripts — rather than editing the SQL dump in a text editor. WordPress’s own guide to moving a site covers the supported approaches.

After the replace, check for mixed content: pages served over HTTPS that still pull an image or script over HTTP. Browsers block those and show a broken padlock. Your browser’s developer console lists every one.

Protecting your search rankings through the move

A host move does not need to cost you rankings. Three mistakes are what usually do.

Leaving the staging site indexable. If a copy of your site is live at a temporary address with search engines allowed, you have published a duplicate of your entire site. Keep staging behind a password or the “Discourage search engines” setting while you build.

Leaving that setting on after launch. The opposite failure, and more damaging. The site goes live with noindex still set, and over the following weeks it disappears from search. Check Settings → Reading immediately after cutover — this single checkbox is responsible for a large share of “we migrated and lost all our traffic” stories.

Dropping redirects. If any URL changed, every old address needs a 301 to its new equivalent. Crawl the old site before you switch so you have the full list of URLs to map.

After launch, confirm the live site returns 200 for key pages, check that robots.txt is not blocking anything important, and submit the sitemap in Search Console. Then watch coverage and impressions for a few weeks; a brief dip while the new server is recrawled is normal, a sustained decline is not.

Asked on ChatGPT, Gemini and Google

Questions people ask AI about WordPress migration

“Will migrating my WordPress site hurt my Google rankings?”

Not if the URLs stay the same and the site stays reachable. Most ranking losses after a migration come from the noindex setting being left on after launch, from missing 301 redirects when URLs changed, or from a site that was broken for days. Check Settings and Reading right after cutover.

“How long does a WordPress migration take?”

A small site is typically a couple of hours plus DNS propagation. A large or e-commerce site takes longer because of database size, order data and the need for a content freeze. Lowering your DNS TTL a day beforehand shortens the cutover from hours to minutes.

“Why did my contact form stop sending email after migrating?”

Either your mail is still routed to the old host, or the new host blocks the PHP mail function that WordPress uses by default. Sending through authenticated SMTP fixes the second case. Always test every form after a move, since a form that looks fine can be silently failing.

“Can I migrate a WordPress site myself?”

For a small site with a plugin like Duplicator or All-in-One WP Migration, often yes. It gets harder with a large database, a WooCommerce store with live orders, a domain change requiring serialized search-replace, or email that has to move with it.

“What causes a white screen after a migration?”

Usually a PHP version mismatch: the new host runs a newer PHP release and an old theme or plugin calls a function that no longer exists. Enabling WP_DEBUG_LOG and reading the debug log will name the exact file and line.

“Should I keep the old hosting after I migrate?”

Yes, for at least a couple of weeks. It is your fallback if something was missed, and the only place to retrieve content or orders created during the switch. Cancel once the new site has run cleanly for a full billing cycle.

Planning a move and unsure about something? Ask us in a free consultation

How WevTEC Fix Website Issues helps

We have moved and repaired websites since 2013, including sites where someone else’s migration went wrong. The work is mostly in the preparation and the verification: matching the environment, keeping a working fallback, handling serialized data properly, and checking the things that fail silently — forms, scheduled jobs, order emails and indexing — rather than just confirming the homepage loads.

Related reading

• How to update the PHP version in WordPress
• Error establishing a database connection: causes and fixes
• Cloudflare DNS problems and how to fix them
• HTTPS errors on WordPress sites

Sources

1. WordPress Documentation, Moving WordPress
2. PHP, Supported Versions
3. WordPress Documentation, Debugging in WordPress
4. Google Search Central, Site moves without URL changes