So this week saw the migration of my employer’s website from one server to another. Luckily it all went (relatively) smoothly, despite over-running by a few days due to an unresolved (critical) issue before the Christmas break. Never the less, it went well with only a couple of issues. Here’s a breakdown of what we encountered during the migration.

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.