Web Hosting migration FAQ

This FAQ is to provide answers to those frequently asked questions for customers previewing their site in advance of our web hosting migration.

What is happening?

At the start of September, we’ll be moving your website to an upgraded platform in our new UK data centre and providing you with a whole host of new features.

What do I need to do?

To help us ensure we’ve got everything just right, we ask that you preview your site on the new platform. Please let us know straight away if anything is amiss. We also strongly advise that you take a copy of your updated site as soon as the upgrade has completed.

You can preview your site now, using the link sent to you by email.

Please Note: If, when visiting the link in your email, you were redirected to your normal site domain, or something didn’t display or work as expected, it’s likely that your site doesn’t allow access via an alternative domain. So, before reporting an issue you will need to temporarily point your live domain (for your machine only) to its new location, this article for How to edit your hosts file will guide you through doing this. You will need to use the IP when you make this change. Once you’ve updated your hosts file, you need to visit your website in the normal way, i.e. www.yourdomain.com, rather than the preview link we’ve provided.

Something’s not right, what can I do?

Although we’ve spent considerable time trying to ensure our new systems behave just the same as before, we know from experience there are likely some edge-cases we’ve missed. We will need you to let us know about the issues you are experiencing, please get in touch by raising a ticket, here.

Will my FTP details change?

Your default FTP details will be copied over to the new platform. However, if you had additional FTP users set up you will need to recreate them once the migration completes. You will be able to find instructions for how to do this in our support centre after the switch over.

My DNS is hosted elsewhere, will I need to make changes?

Eventually, we will need you to make some changes to your DNS, but we will be in touch when we need you to do that. For now, the important thing is to make sure that your site is displaying as it should when looking at the preview link or when your hosts file has been updated.

Taking a new local copy of your site.

Once you receive confirmation from us that the migration has completed, it is important that you take a new local copy of your site as your local copy needs to be totally up to date. You will be able to find instructions for how to back up your site, here.

I’m technical, please give me exact details of what you’re doing!

For the last several weeks, we’ve been replicating your site storage (in real-time and via a secure VPN) to a secondary storage device in the new data centre in Reading. From here, we’ve copied your site to the new storage platform (a redundant NetApp cluster) and applied the changes described above. We’ve also been checking several times per day (using rsync) for any updated files and repeating this process as necessary.

At the same time, we’ve been securely replicating all customer databases to several powerful new MySQL servers. More on this in a moment…

When you visit the site preview link, our load balancers rewrite the host header and URL of the request to mimic access via the default domain. However, depending on how the application is written, it may still detect that we’re faking it. This is why we suggest updating your hosts file as the most thorough form of testing.

We’ve audited all-important server settings, such as available PHP modules, htaccess directives, default character sets, paths to 3rd-party applications etc, to try to ensure full compatibility. We’ve also manually examined a large sample of sites, compared status headers of hundreds of thousands of URLs and automatically (as far as possible), compared the source HTML of the homepage of each site on both the old and new platforms. As a result of these tests, we’re pretty confident the vast majority of users won’t experience any issues – but quite honestly, we’d still be amazed if we thought of everything, which is why we still ask users to perform their own checks. For example, we’re unable to test sites that require a username and password to access.

On migration day, we’ll have to take your site temporarily offline while we make the following changes:

  • Perform a final replication and rsync of site content
  • Reverse replication of the MySQL servers
  • Update host files on new servers to point all database connections to the new MySQL servers
  • Configure the existing platform to proxy requests to the new platform

From this moment, your site will be served from the new platform, and all databases queries will be served by the new MySQL servers.

In the hours following this move, we’ll be performing a batch update of DNS settings to point sites directly at the new platform, without the need for the proxy. Once this has completed, we’ll be monitoring the logs, and auditing public DNS, to find those sites using 3rd-party nameservers, or external services such as CloudFlare. We will then be contacting those customers with additional instructions.

Prior to this move, we will have copied your existing default FTP user to the new platform, so this should continue to work as before. In reality, the new username will be the same as your domain (but prefixed with “fp_” if the domain starts with a number). But our FTP servers will automatically map your old username (eg ftp_yourdomain_com) to the new username (eg yourdomain.com). Unfortunately, we can’t do the same for any additional FTP users you’ve created, due to namespace clashes. You’ll be able to create as many FTP users as you need via your new Account, however.

Have questions?

If you need more information or have any questions, please do get in touch.

Was this article helpful?

Check out some of our related guides

Need a hand? Search over a hundred step-by-step support guides