WordPress migration failed? What to check and what to do

A WordPress migration means moving a website to a new server, a new hosting provider or a new domain. When it fails, the website can end up in an uncomfortable middle ground: partly on the old server, partly on the new one, and not fully working on either.

You may notice that:

the new website shows errors or a blank page
pages load, but images are missing
links or the login page send you back to the old domain
the browser shows a "not secure" warning
some visitors see the old website and others see the new one
the database import stopped with an error
the dashboard is not accessible

A failed migration can be stressful, especially if the website is part of your business. However, as long as the original website and a backup still exist, the situation can almost always be recovered.

The most important rule is simple: do not delete the old website until the new one has been fully checked.

This guide explains what usually goes wrong during a migration, what you can check safely, what to avoid and when it is better to ask for technical support.

What does a failed migration usually mean?

A WordPress website is made of two main parts:

the files: WordPress itself, themes, plugins and uploaded media
the database: pages, posts, settings, users, orders and much more

A migration copies both parts to the new location, connects them, and then points the domain to the new server.

A migration fails when one of these steps is incomplete or incorrect. For example:

some files were not copied
the database was only partly imported
the website settings still refer to the old address
the domain still points to the old server
the new server is configured differently

The good news is that each of these problems can be checked separately.

What may have gone wrong?

The site is only half migrated

Large websites can time out during the transfer. A migration plugin or a manual upload may stop without a clear error, leaving some files or database tables behind.

Typical signs are missing images, missing plugins, a theme that looks broken or pages that do not exist on the new site.

Links and images point to the old domain

WordPress stores the website address in its settings and inside the content: in links, image paths and some plugin settings. If the domain changed and these references were not updated, the new site may load images from the old server, or send visitors back to it.

Everything may seem fine as long as the old site is online, and then break the moment it is switched off.

Mixed content warnings

If the new site uses HTTPS but some content is still loaded over HTTP, browsers may show a "not secure" warning or block parts of the page. This often happens after moving to a new domain or enabling an SSL certificate during the migration.

DNS has not propagated yet

When the domain is pointed to a new server, the change is not visible everywhere at once. For a while, some visitors may reach the old server and others the new one. This is normal, but it can be confusing during testing.

The old site is still live and receiving orders

This is the most important risk for ecommerce and membership websites.

If customers keep placing orders, registering or submitting forms on the old site after the database was copied, that new data exists only on the old server. If the old site is then deleted, the data can be lost. If both sites stay live, your data ends up split between two places.

Database import errors

The database import can fail because:

the file is too large for the upload limit
the import times out
the new database server uses a different version
a character set or collation is not supported
the table prefix does not match wp-config.php

A partly imported database can produce errors, missing content or the message "Error establishing a database connection".

File permissions and server configuration

On the new server, files may belong to the wrong user or have the wrong permissions. This can prevent WordPress from uploading media, installing updates or even loading. Differences in PHP version or server rules can also cause errors that did not exist before.

Do not delete the old website

Until the new site has been fully tested, the old website is your safety net.

Keep:

the old hosting account active
the old files and database
a full backup made before the migration started

If the old site is still receiving orders or registrations, ask a developer how to handle it. Depending on the situation, it may be better to put it in maintenance mode, redirect it or plan a final data sync. Avoid making this decision in a hurry, because it affects where your data ends up.

First, understand where the migration stopped

Try to answer these questions:

Which method was used: a migration plugin, a hosting tool, a manual copy?
Did the domain change, or only the server?
Was the domain already pointed to the new server?
Did the process show any error message?
When was the database copied?
Has anyone placed orders or edited content since then?
Is the old website still online?

Write down what you know. Even a partial timeline is very useful.

What can you safely check?

Check which server you are actually seeing

Because of DNS propagation and caching, you may be looking at the old site without realizing it. Ask your hosting provider how to preview the new site, or check where the domain points (see the hands-on section).

Compare the old and new sites

Open the same pages on both versions and compare:

the homepage and a few internal pages
images and downloads
forms and search
the login page and dashboard
the shop, cart and checkout, if you have one

Note which pages are different or broken.

Check the website address settings

If you can access the dashboard on the new site, go to Settings > General and look at the WordPress Address and Site Address. They should show the new address.

Do not change them unless you are sure, because a wrong value can lock you out of the dashboard.

Contact the hosting provider

The new hosting provider can often confirm whether the files and database were imported completely, provide error logs and check permissions or PHP settings. Many providers also offer migration help.

What should you avoid doing?

Avoid:

deleting the old site, its database or its hosting account
running the migration again over a partly working site without a backup
doing a find and replace on the database with a text editor or a plain SQL query
changing the DNS back and forth repeatedly
leaving both the old and new sites open for orders
changing file permissions to the most open setting to "make it work"
editing wp-config.php without keeping a copy of the original

Plain find and replace is especially risky. Some WordPress data is stored in a serialized format, which records the length of each text. Changing the text without updating the length can break plugin settings, widgets and theme options. Tools designed for WordPress handle this correctly.

When should you ask for technical support?

Technical support is recommended when:

the website is an online shop, membership site or booking system
orders or registrations may have been placed on the old site after the copy
the database import failed or you are not sure it is complete
the domain changed and links still point to the old one
you cannot access the dashboard on the new site
the old site has already been deleted
you do not have a verified backup
the migration was done by someone who is no longer available

You do not need to understand exactly where the migration failed. A description of what you see on the old and new sites is enough to start.

What information should you collect?

Useful details include:

the old and new domain, if different
the old and new hosting providers
the migration method or plugin used
the date and time of the migration
any error messages, with screenshots
whether the domain has been pointed to the new server
whether the old site is still online
whether new orders, users or content were added after the copy
where backups are stored and when they were made

Do not send passwords or hosting credentials by ordinary email. D4Hub can explain how to share access safely.

How D4Hub can help

The goal is to finish the move without losing data and to make sure the new website works as well as the old one.

Depending on the situation, D4Hub can help with:

checking whether files and database were copied completely
fixing database import errors
updating old addresses safely, including serialized data
solving mixed content and SSL problems
checking DNS records and planning the switch
protecting orders and registrations received on the old site during the move
fixing file permissions and server configuration
comparing the old and new sites page by page
coordinating with the old and new hosting providers
testing forms, login, checkout and other important functions
deciding when it is safe to retire the old site

You can ask for support at any stage of the process.

For example, D4Hub can:

review the plan before you try again
take over a migration that stopped halfway
complete the full move and testing
check the new site after you have finished

Open a support ticket

For hands-on users: technical checks after a failed migration

The following checks are for users who are comfortable with a terminal, SFTP and WP-CLI.

Before changing anything, make a fresh backup of the new site's files and database, and make sure the old site and its backup are still available. Change one thing at a time.

In the examples, replace example.com, old-domain.com and new-domain.com with your own domains.

Check where the domain points

dig example.com A +short
dig www.example.com +short

Compare the result with the IP address of the old and new server. To see what a public DNS resolver currently returns, you can query it directly:

dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short

If different resolvers return different addresses, the change is still propagating. If you use a CDN with the proxy enabled, you will see the CDN addresses instead of your server.

Check the address WordPress uses

On the new server, from the WordPress folder:

wp option get siteurl
wp option get home

Both should show the new address, including https:// if the site uses SSL. If WP_HOME or WP_SITEURL are defined in wp-config.php, they override the database values, so check that file too.

Replace the old domain safely

First, make a backup of the database:

wp db export before-search-replace.sql

Then run a dry run. It shows how many replacements would be made, without changing anything:

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --dry-run

wp search-replace handles serialized data correctly, which a plain SQL replace does not. Review the result carefully: check that the old value is exact, including https:// and www if used, so you do not replace unrelated text.

Many developers add --skip-columns=guid, so that the internal identifiers of posts are not changed. Only run the command without --dry-run once you are satisfied with the preview and have the backup.

After the replacement, clear any cache and check a few pages and images.

Look for mixed content

Open a page in the browser, open the developer tools and check the Console tab. Mixed content warnings list resources loaded over http://. They often come from old addresses in content, theme settings or page builder data.

Compare file and table counts

On both the old and new server, count the files in wp-content:

find wp-content -type f | wc -l

And the database tables:

wp db tables --all-tables | wc -l

The numbers do not need to match exactly, for example because of cache files, but a large difference suggests an incomplete copy. You can also compare the size of the uploads folder:

du -sh wp-content/uploads

Also check that the $table_prefix value in wp-config.php matches the prefix of the imported tables.

Check the database

wp db check

This checks the tables for errors. If the import failed with a collation or character set error, the new database server may be older or configured differently. Ask the hosting provider which versions are in use before trying again.

Check file permissions

A common setup is 755 for folders and 644 for files, with wp-config.php often more restrictive. The correct values and file owner depend on the server, so check with your hosting provider before changing them. Never set files or folders to 777.

D4Hub can help you interpret the results and plan the next safe step.

FAQFrequently asked questions

Not if it has not been deleted. Most migrations copy data rather than move it, so the original site normally remains on the old server until someone removes it. Keep it until the new site has been fully checked.

It depends on the DNS settings and on how long resolvers keep the old information. It can be quick or take longer. During this time some visitors may still reach the old server, so plan the switch with that in mind.

Sometimes, but first make sure you understand why it failed, and back up the new site in its current state. Running the same process again may hit the same problem, or overwrite changes made since the first attempt.

Do not delete the old site. Those orders exist only in the old database and need to be moved or recorded manually. This is delicate work, especially for shops with stock management and subscriptions, and is a good moment to ask for help.

Image addresses are stored in the content and in some settings. If the domain changed, they need to be updated with a tool that handles WordPress serialized data, such as wp search-replace. They may work now only because the old site is still online.

Yes. Share what you know about how the migration was done and what you see now. D4Hub can review both sites and work out the safest way to complete the move.

My WordPress migration failed: what should I do?