WordPress Errors After Migration: What Broke and Why

The move looked finished. The files were copied, the database imported, the domain pointed at the new server. Then you opened the site and got a database error, or the home page loaded but every other link went to “Not Found”, or the images were all broken, or the site kept bouncing you back to the old address. A move that took an evening is now taking a weekend.

The reassuring part is that post-move errors are very predictable. A WordPress site is files plus a database, and the database is full of references to where the site used to live: its address, its file paths, its server settings. Almost every error after moving host or domain comes from one of those references not being updated, or from the new server being set up a little differently from the old one. Work through them in order and most sites come back without anything clever.

Before you change anything

Two quick checks save a lot of confusion.

Are you actually looking at the new server? After a DNS change, different networks pick up the new address at different times. You may be seeing the old host, or a mix of both, for a while. Your new host’s panel often gives a temporary or preview URL, and you can also point your own computer at the new server by editing its hosts file. If the site works on the new server and only looks broken through the domain, the problem may just be timing.

Do you still have the original? Keep the old hosting account and its files until the new site has been running without trouble for a while. Make a fresh copy of the new site’s files and database too, before you start fixing, so you can undo a fix that goes wrong.

The errors, roughly in the order people hit them

“Error establishing a database connection”

The most common first error. To find its database, WordPress uses the DB_HOST, DB_NAME, DB_USER and DB_PASSWORD lines in wp-config.php. After a move at least one of them is usually different. The database name may have a prefix the host adds, the user may not have been given permission on that database, or DB_HOST may need to be something other than localhost. Compare each value with what the new host’s panel shows. If they all match and it still fails, the user probably lacks privileges on the database, which is fixed in the host’s database tool. Our page on fixing database connection errors goes further if the basics check out.

The install screen appears instead of your site

If you see WordPress asking you to choose a language and run the installer, do not run it. This usually means WordPress connected to the database but could not find its tables, most often because $table_prefix in wp-config.php does not match the prefix of the imported tables. If the old site used wp7x_ and the new config says wp_, WordPress thinks it is a fresh install. Match the prefix to the table names and reload.

Home page works, every other page shows 404

Classic after a move. Pretty permalinks on Apache and LiteSpeed rely on rewrite rules in the .htaccess file, and that file starts with a dot, so many FTP clients and some archive tools skip it by default. Open Settings > Permalinks and simply press Save Changes as it is; WordPress then tries to rewrite the rules. If it cannot write the file, it shows you the rules to paste in by hand. On Nginx, the rules live in the server configuration and the host has to add them. The full set of causes is in why every page except the home page returns 404.

The site keeps sending you to the old address

WordPress stores its own address in two settings, Site Address and WordPress Address, under Settings > General. If the domain changed, those still hold the old one, and WordPress dutifully redirects every visit there. If you cannot reach the dashboard, these can also be set in wp-config.php with the WP_HOME and WP_SITEURL constants. Check, too, whether those constants were already in the config file from the old server, because they override what the dashboard says.

Too many redirects

If the browser says the page redirected you too many times, the usual cause after a move is a disagreement about https. The site addresses say https, but the new server has no certificate yet; or a CDN is set to connect to the server over plain http while WordPress insists on https; or a redirect rule copied in .htaccess from the old host fights with a new one. Our post on redirect loops in WordPress walks through each version.

Broken images, links and layouts pointing at the old domain

Changing the two address settings does not change the thousands of old URLs inside posts, pages, widgets and builder data. Those need a search-and-replace across the database, from the old address to the new one. The trap is that WordPress and many plugins store some settings as serialised data, which records the length of each piece of text. A plain find-and-replace in a SQL file breaks those lengths, and the settings silently reset or disappear. Use a tool that understands serialised data: WP-CLI’s wp search-replace command does, and its --dry-run option shows what would change without writing anything. Several well-known migration and search-replace plugins handle it too. Run it on your copy first.

If the page loads but some content shows the padlock warning or images will not show on https, there are still http:// references left. Our guide to mixed content after switching to HTTPS covers finding the stragglers.

A critical error or blank pages on the new host

The new server may run a different PHP version from the old one. A site that was fine on an older PHP can throw fatal errors on a newer one, because an old plugin or theme uses code that newer PHP no longer accepts. The reverse happens too: a recent plugin may need features the new server’s older PHP lacks. Check the PHP version in both hosting panels. If they differ, setting the new server to match the old one gets you running while you plan a proper upgrade. Turning on WP_DEBUG_LOG will show which file is failing.

Uploads fail, or plugins cannot write files

Files copied from one server to another can arrive with the wrong owner or permissions, so WordPress cannot write to wp-content/uploads, cannot update plugins, or asks for FTP details every time you install something. Folders are usually 755 and files 644 on typical Linux hosting, and the files should belong to the account the site runs as. There is a fuller explanation of those numbers in our guide to file permissions, including why 777 is not the fix.

Quieter problems that appear days later

• Emails stop arriving. The new host may block or limit outgoing mail, and your domain’s SPF record may not include the new server. Form and order emails go missing without any error on screen.
• Scheduled tasks stop running. If the old server used a real cron job and the new one does not, scheduled posts, backups and some store tasks stop quietly.
• File names that worked on one server fail on another. Linux servers treat Logo.png and logo.png as different files. A site moved from a Windows or local setup can lose images over a capital letter.
• Payment and API connections break. Some services check the domain or the server’s IP address, so webhooks, licence keys and payment callbacks may need updating with the new details.

A working order for the first hour

1. Confirm you are viewing the new server, using its preview URL or your hosts file.
2. Check wp-config.php: database name, user, password, host and table prefix.
3. Check the Site Address and WordPress Address, and any WP_HOME or WP_SITEURL lines.
4. Resave permalinks and confirm .htaccess exists, or ask the host to add Nginx rules.
5. Make sure the SSL certificate is active before forcing https anywhere.
6. Run a dry-run search-replace for the old domain, review it, then run it for real on a copy.
7. Match the PHP version to the old server and check the debug log for anything that still fails.
8. Test the things that do work rather than just display: forms, checkout, login, scheduled tasks and outgoing email.

For the full range of WordPress errors beyond moving day, including the ones listed here, our errors and fixes guide groups them by symptom.

Making the next move smoother

Most of the pain above comes from moving straight onto the live domain. A gentler pattern: copy the site to the new host, test it fully on a temporary address, fix everything there, and only then switch DNS during a quiet period. Lower the DNS record’s TTL a day or so in advance if your DNS provider allows it, so the switch spreads faster. Keep the old hosting live until you are happy. If you would rather not do the move yourself next time, we can handle the move to a new host using that staging-first approach.

When the site is down and the clock is running

If DNS has already switched, the old host is gone, and the site is showing an error to every visitor, the order of work changes: first get something working, then tidy up. That is exactly the situation our help for a site that is down right now is set up for. Tell us on WhatsApp or via the contact form what the screen says and which host the site came from and went to. We save what exists before touching it, then give you a straight account of what went wrong.

Next in this series: How to Report a Website Problem to a Developer