Web Hosting Migrations: 10 Things You Need to Know

Quite often our customer’s websites (or their customers) outgrow their chosen web hosting package and require an upgrade. This could be a customer moving from Personal hosting to Professional website hosting, Professional hosting to Business hosting or even consolidating multiple single-domain hosting packages into Reseller hosting or a Plesk VPS package.

Since I started working for 34SP.com in June, I’ve performed hundreds of migrations for our customers, encountering all manner of curious challenges along the way. As simple and as seamless as I try to make it for our customers, moving a website, databases and emails from one physical machine to another involves some pre-planning on my behalf to ensure a fast and trouble free migration.

With hundreds of happy post-migration customers, this blog post is dedicated to the months of experience that I’ve accrued on the matter, in the hope that it will become increasingly useful towards the future, especially as more and more of our customers appear to be after upgrades. (Perhaps something to do with our current offer of  3-months of free Professional hosting to customers upgrading from Personal hosting accounts!)

1. PHP and MySQL have moved on.

A lot of websites are, quite amazingly, still written with PHP 4.x in mind. Some of the older 34SP.com servers do still come with PHP4 as standard, although most of these are gradually being retired, and you may well find some changes are required to your code to have them work seamlessly with PHP5.2.x, post-migration.

Similarly, the register_globals option is disabled by default on all new installations. This is in-line with the fact that it will be deprecated in PHP 5.3 and removed as of PHP6, so it’s already worth updating your code to ensure that it doesn’t rely on register_globals!

When migrating websites from MySQL 4.x to 5.x, there are rarely issues that appear. However it is important to be aware of this change, particularly when running some older shopping cart or CMS systems, such as legacy versions of osCommerce.

2. CentOS is the new FreeBSD!

With the launch of Professional hosting, our VPS products and indeed the continued support of Plesk on the CentOS Linux operating system by Parallels (and thankfully, AtomicCorp) 34SP.com is moving away from running FreeBSD on our servers.

This change in operating system has meant that the full path to your files has switched from /usr/local/psa/home/vhosts/DOMAIN/ to a much easier-to-type path of /var/www/vhosts/DOMAIN/. The downside to this is that anything relying upon hard-coded paths will require an edit. In general, this is only one or two files, but we’re happy to perform search and replace functions when the time to edit each individually would be too great.

3. Frontpage Extensions are gone.

The Frontpage Extensions (FPX or FPSE) for UNIX systems have been officially ‘End-of-Lifed‘ by RTR, the company employed by Microsoft to create and support their running upon UNIX-like systems. Amidst serious concerns over the design and security of the Frontpage Extensions, 34SP cannot (nor would we wish to) continue supporting these extensions on new hosting packages.

We are retaining one legacy server for Personal hosting customers whom absolutely must continue using Frontpage with its built-in publishing features, but we sincerely urge anyone relying on such software to find new, more secure methods of uploading files to their web hosting.

4. mod_security has changed (for the better!)

With the newer LAMP environment, also comes a newer implementation of mod_security, backed-up by the brilliant Atomic Secured Linux system that dynamically updates, reacts to and hardens mod_security-protected servers.

A downside is that any ‘SecFilterRemove’ statements present in an .htacess file, are no longer valid with newer versions of mod_security and will cause ‘Error 500’ messages when parsed.

Furthermore, its replacement (SecRemoveRuleByID) can only be added to the Apache vhost configuration files, meaning that we have to add these for you. However, given the large steps in which mod_security has improved in recent years, it is generally no longer necessary to maintain the exceptions. For the most part, customers that have previously used these do not always continue to require them.

5. DNS cache is the sworn enemy of server migrations.

The Domain Name System, or DNS system relies heavily on cached responses to reduce load upon individual name servers and to reduce network traffic across Internet backbones. For the most part, caching serves a worthy purpose – until, that is, you wish to move your website and emails to a new location. It is at this point that cache is evil.

For most migrations, we lower the ‘time to live’ (or TTL) value of the DNS cache to an hour – down from the standard 24hrs – so that disruption is kept largely to a minimum. However, some ISPs provide DNS services that ignore these TTL values and will cache records for as long as they deem necessary. This is of course, completely out of our control.

Similarly, a user’s computer (even just a single application) can hold DNS cache for an even longer period. We’ve noticed that there is a distinct correlation between the OSX-based Entourage and Mac Mail programs, in which it can sometimes take an annoyingly long time time to update DNS cache. This is of course, again, out of our control. However I hope that this blog post can go some way to explaining (and fore-warning) any potential customers of the problems DNS cache can cause during migrations. If in doubt, please just ask before your migration!

6. Maintaining consistent mailboxes isn’t easy.

In relation to the troubles of DNS cache, when performing migrations we have to be quite firm with the way that email is handled during the switch-over. No-one likes to ‘lose’ email, therefore the idea of it being delivered to their old server instead of the shiny new one, is quite a problem.

With this in mind, we generally turn ‘off’ mailbox access for the domain (or domains) being migrated, as soon as their content is copied to the target machine. At the same time, rules are added to the Qmail service on the source server, to implicitly forward any email bound for the migrated domains, over to the new server.

And for anything we miss in those few minutes, imapsync does an excellent job of copying missing emails from one mailbox to another. So that’s one less thing to worry about!

7. It takes some time to copy your data.

Whilst we try to maintain a fast internal network here at 34SP.com, the transfer of multiple ‘small’ files by Plesk’s migration manager takes time and as a result, gigabytes of data can rarely hit the peak transfer speeds possible and take literally hours to transfer across. Whilst sites this large are very rare, the temptation to update and adjust websites during migrations needs to be kept at bay, as otherwise you risk updating the wrong set of content… Or having your changes over-written!

8. The migration tools aren’t perfect.

Plesk will ‘forget’ to migrate any address books and calenders stored in the Horde webmail facility, which needs to be managed for a handful of our customers. Fret not, however, as Horde thankfully includes an export tool that allows you to backup and migrate your address books and calenders between instances of Horde on different servers, and between Horde and the Atmail email system used with Professional hosting. This isn’t scripted or automatic, therefore must be done retroactively and upon the user’s request – please do let us know before starting the migration, if you require this.

9. We need your help!

Robust client communication is critical to successful migrations. Whether or not you’re able to follow the exact process involved, it is imperative that any emails from a staff member are read and responded to. Not least of which is when the copying phase of the migration has completed and the DNS cache has refreshed. At this stage customers sometimes go quiet. This means we aren’t yet certain if you’re happy with your migration and we won’t close your older account until we hear back from you. Therefore it’s great to know that you’re satisified and if you have any feedback. You could also be losing out on valuable 34SPoints, if your account is in credit at the point of closure! 😉

10. If in doubt, your ‘welcome’ e-mail has the answers.

If you’re unsure of any of the connection or authentication details for your new hosting package (or server) then remember that the welcome email which follows any new purchase will include all the important details to get you hosting. For anything else, however, please don’t hesitate to reply back on the migration ticket with your queries.

And in the end…

Don’t be put off! Migrations are offered free of charge between Plesk-based hosting products so that you can take advantage of the right service for your hosting. Yes, there are some items to be aware of, but rest assured that there’s very little we haven’t already seen, don’t know how to fix, or can’t advise further upon. There’s really no reason to be afraid of moving onwards and upwards and compared with doing it yourself, we genuinely make it easy for you to switch between products.

Good luck with your migration to that fantastic new platform. We wish you great success!