So, we used a migration specialist, SEM Solutions, to aid with the process. They handled the database copying, which is always the tricky bit, and uploaded the entire file-structure (public_html in the case of the old server). This is really the first two points to be aware of.

1 – Exporting / Importing databases can be hard! Make sure you know what you’re doing before attempting this (I tried it once and ended up having to recover my articles via wayback-machine and Google Cache, although that was a few years ago!).

2 – Check your full URL paths. When linking directly to files, if you include the web root folder from the FTP be sure it’s the same on the new server. For example, on the new server is uses ‘http_docs’ rather than ‘public_html’ as the web root folder.

There’s another similar issue here; the server back-end UI. Be sure you inquire about which one comes with a server before making the switch.

3 – CPanel vs PLESK. Parallel PLESK is new to me, as I’ve always used old faithful CPanel. PLESK, despite looking less functional and more dated (in my opinion, at least) has similar sections in terms of functionality. It’s quite well documented too, as is CPanel, meaning a switch between the two shouldn’t be too much of an issue (it wasn’t for me, at least).

There was one final issue, which caused the delay in migration. It’s a site specific problem, but it can be applied to almost any website with a contact form.

4 – Mail Transfer Agent. The issue we encountered was the following: We have a contact form. It adds data to a database. It also emails the data to a range of email addresses and produces an XML (more to follow). The contact form was functioning, but it seemed sporadic in the emails (they always came through blank despite the data being added to the database. The solution, you ask? Well, after a few days of head-scratching we discovered it was in fact ‘\r\n’ in the functions file of the form being rendered differently by the new server’s MTA (QMail as apposed to EXIM). This produced an additional line break which ended the header section of the form.

As I said, site specific. But if your experiencing similar issues it’s worth checking the PHP functionality for unnecessary line breaks!

5 – Permissions. A final note – Check your permissions! The XML mentioned above was failing to be created (even temporarily) due to permissions! This is something a ‘live chat assistant’ can usually do over the chat-box.

However, after the plug-in was updated some time last week it started showing errors in Google’s Webmaster Tools. The error was the following.

“Paths don’t match we’ve detected that you submitted your Sitemap using a URL path that includes the www prefix (for instance, http://www.example.com/sitemap.xml). However, the URLs listed inside your Sitemap don’t use the www prefix (for instance, http://example.com/myfile.htm).”

To fix this is simple, but I had to search around quite a lot to get the fix. All you have to do is go to the General tab under Settings in WordPress and add the ‘www.’ prefix to both the WordPress address AND the Blog address, then rebuild and submit the sitemap.

If you are still getting errors (which I did) check that any additional URL’s mentioned in the XML-Sitemap tab of Settings have the ‘www.’ prefix, as mine reset automatically.

As I said; Simple! But it took quite a lot of re-building and re-submitting to find the answer!