White Screen of Death

Let’s start with the most jarring error, which also happens to be one of the easiest to fix, the ominous sounding white screen of death. This error typically surfaces on the target site immediately after migration.

You just migrated your content and then you go to the target site and open it and you see this, a completely white screen with absolutely no content. There are no error messages, it’s just white. This white screen of death is typically caused by one of two things. Either, one, the site is set to use a theme that is not currently available, or two, there is a code error somewhere. In the case of migration, the reason is almost always number one, the theme WordPress wants to use is not available.And, if so, the problem is relatively easy to fix. The reason why this would occur is simply that you forgot to add the theme that’s currently being used, to the site before you migrated.

To fix it, you can do one of two things. Either, navigate to the back end so WP-admin. This should still be available to you if the error is just that you’re missing the theme, and if it is, you can simply go to Appearance, and here under Appearance you’ll get the message, the active theme is broken, reverting to the default theme.

The other way of solving it would be to go in through FTP, go to the WP content and themes folder for your local site and then make sure that the list of themes matches across your local and remote sites. And here you can see that the Popper theme is missing. So I could, if I wanted to, simply grab the Popper folder, pull it over into the themes folder for my target site and then everything would just work again without having to reset the theme.

 

Manual Database Import Fail

An error you may come across when using the free WP Migrate DB plugin is the phpMyAdmin returns an error when you try to import the exported database file. That error typically looks like this. SQL query, MySQL said, 1064, you might have an error in your SQL syntax, and then, some sort of explanation of what that error might be. What's happening here is phpMyAdmin is having a hard time understanding the gzipped export file. You'll remember that when we export a file using WP Migrate DB, you can choose to compress the file with gzip.

There could be a lot of reasons for this error, but rather than trying to figure out the exact reason and syntax error, you can usually get around the problem by simply exporting the database again. Only this time, unchecking this, so you get the full, uncompressed version of the file. This will mean that the file you get exported is a lot bigger.

it should bypass the problem, and you should be able to upload it. So, try unchecking Compress file with gzip, so you get an uncompressed version of the database dump.

Then, import that uncompressed version into your database through phpMyAdmin, and you should see everything working properly.

 

WP Migrate DB ate the Posts

The third error occurs when you have posts on the Target site already, and then, when you perform migration, you realize that all those old posts are gone. It pains me to say this, but this is not an error in the plugin, but user error. Remember how I kept saying the migration process replaces the Target site database? Well, that's what's happening here. You're doing a migration, not merging two databases. If you want to preserve the original posts from the Target site, use the Export/Import function in WordPress to import the posts into the Origin site first, and then, migrate the whole site with the new posts from the Origin site to the Target site.

Simply leaving posts on the Target site and then trying to migrate other content over will not work. And this also applies to custom post types. If you have custom post types on your Target site, and you want them to stay on the Target site during a migration, it's not enough to ignore custom post types in the plugin. You have to export them from the Target site into the Origin site first, and then, migrate the entire Origin site with those custom post types up to the Target site. The simple rule of thumb here is: migration means overwriting the database on the Target site.

Everything on the Target site will be lost.

 

Media Files are not working

There's a good chance that at some point, you'll migrate a site, and discover that the media files are not working. By now, you can probably figure out what's wrong here, but lets hash it out together. You go to the site, and see a bunch of errors like what you're seeing here. And if you go to the back end, and go to the Media Library, you'll see that the Media Library is full of broken links, seeing as some of these images are not present where they're supposed to be. This is because when we perform a migration with either the free or the premium version of WP Migrate DB, we're only migrating the database.

That includes any references to the media files. However, unless you either migrate the media files themselves manually, or use the media files add on, the media files themselves will not be present on the Target server. By far, the easiest way to fix this problem is to simply go to your FDP application, open your Origin site, and the Target site, and navigate to the Uploads folders. Then make sure that everything matches, and as you can see here, I'm missing the entire 2016 folder.

So I'm simply going to grab that and pull it over. And when the transfer is done, we can go back and reload the Media Library. And all the media items automatically appear. Same with the front end. Now, all the images within our post work the way they're supposed to. To avoid this problem in the future, here's a very simple rule to follow. Either if you're using the free plugin or you have the personal package, migrate your media files before you do the database migration.

If you have the pro version of the plugin and access to the add ons, always use the Media Files add on and make sure you are comparing and uploading or comparing and uploading and then removing, so that the media files on the Target site always match the media files on your Origin site.

 

Migration failed

Fifth and finally the error that frustrates people the most. They perform the migration using the free plugin only to discover it didn't work at all. The old site is still there, just like you can see here. This always has the same reason and the same answer. The database table prefixes don't match between the two sites. You'll remember I brought this up previously, but it bears repeating. For migration to work the table prefix setting in the target site wp config.php file must match that of the origin site.

To make sure simply open the wp config.php file from the origin site, the one you can see right here, and the same file from the target site, and scroll down to the table_prefix variable. Here you can see the table_prefix for my origin site is wp_, but if I go to the target site and scroll down the table_prefix is isma_. So because these two table prefixes don't match WordPress is looking for the wrong tables in the database and that's why things are not working.

To fix this problem simply correct the table_prefix variable in wp config.php for the target site, so I'll put this wp, and save it. Then grab the file and upload it into the target site, and once uploaded we can simply reload the target site and we are now looking at the correct table. Now if what you saw in my browser is happening to you, meaning you started with a stock install of WordPress, or the old site, and then after uploading the file we switched to the new site, it means that you have a ton of unused tables in your database.

To check if that's the case go to phpMyAdmin and check to see if you have extraneous database tables, and you can see here I have a ton of them. All the ones that say isma. So I'm simply going to check all of these tables, scroll down and make sure I don't have any stray tables, then I'll use this drop down to select Drop, make sure I'm only dropping the tables that say isma as the prefix, click Yes. The tables are cleared out and as you can see it makes no difference for the site, because we are now running the new tables.

So the golden rule is anytime you migrate content from one site to another make sure that the table prefixes always match. The table prefix for the target site must always match the table prefix from the origin site.