How to Migrate a Website to a New Hosting Service Without any Downtime

I recently migrated one of my websites to a different hosting service. If you have a blog or website that you want to move, you can follow the same process to do so without any downtime for your visitors.

Over the past couple of years, I’ve built several websites hosted on No Monthly Fees, Siteground, IX Web Hosting and HostGator. I finally settled on HostGator because they have the best deal on multiple site hosting I could find, and I use Go Daddy for the domain registrations. This is the most cost-effective solution for hosting multiple sites that I’ve come across.

Back when my hosting account at SiteGround was due for renewal, I decided to migrate the site I had there to IX Web Hosting. This saved me the cost of renewing on SiteGround, with the only additional cost being the domain transfer to Go Daddy. If your new hosting provider also offers a good deal on domain name registrations, you can use them as your new domain registrar and simplify the process a little.

Note that there are potentially four entities involved here:

• The old hosting provider
• The old domain name registrar
• The new hosting provider
• The new domain name registrar

I don’t like having downtime on my sites, and the combination of different hosts, different registrars and DNS propagation delays don’t help. Things can go wrong in the process, creating unexpected delays. You need to work with each of these entities in turn if you want to migrate a site without having any downtime for visitors.

These instructions are for a Joomla!-based site, although the basic process should work for any database-based content management system, like WordPress or Drupal.

So here’s how to do it:

Check Your Domain Administrative Contact Email Address

For the domain name transfer process to work, you need your correct email address registered as the administrative contact for the domain in the public DNS records. Various parties will use this address to send you information during the transfer; if your address isn’t correct, you won’t get the mail they send you. If your administrative contact address is associated with the site you’re attempting to migrate, things are likely to get tricky. One solution is to use the email address associated with your Internet Service Provider account, since that won’t change when you change hosting providers for any of your websites. The down side is that it will change if you change ISP’s.

So check with the current registrar for the domain you wish to transfer, to make sure that the administrative contact email address in the DNS records for your domain is correct.

Create The New Domain/Site

Your new hosting provider will have a mechanism for creating a new domain/site. Invoke it to create an empty site, or whatever they generate by default. It will typically say something like “under construction”. Don’t create a reference to the site in the DNS system yet though; we’ll do that later when the content has been fully migrated. The new site will only be accessible by IP address at this point.

Backup The Old Site

Back up the database and file contents on the old site. You need both a dump of the database, and all of the files on the site. If your site consists of static pages with no database, then you just need the files and can skip all the future steps referring to a database.

If it’s a Joomla!-based site, I recommend using the Akeeba Backup Core plugin, previously known as JoomlaPack. I already had JoomlaPack installed and I knew it worked so I stuck with it, but if you’ve not used it before use the newer Akeeba. This tool creates a backup of all the files on your site, along with the database contents, all packaged with an installer similar to the original Joomla! Installer. It’s the easiest way I know of to backup and/or migrate a Joomla! Site.

Even if you don’t plan to migrate a Joomla! site in the future, I recommend you use Akeeba to back your site up. Otherwise, you’re at the mercy of hackers and your hosting provider’s backup system. Many providers offer a free backup service, but charge you for restoring anything. My experience of most backup systems is that you discover that they don’t work properly only when you need to restore something. Ouch.

Create An Empty Database On The New Provider

You need an empty MySQL database on the new hosting provider. Create one using whatever tools the new hosting service provides. There may be constraints on what you can use as your database name, so the new database name may have to be different from the old one; we can handle that. Create a new user to access the database, with a hard-to-guess name and password. Take care not to get confused between your old and new database server, name, user and passwords. Keep them in two separate files.

Pay attention to the new database server name: lower cost hosting providers often share a single database server across multiple customer sites, in which case you need to use this name in place of “localhost”, which is really just means “the same server as the web server is on” and is typically the default database server setting in Joomla!.

Check the default MySQL connection collation on the phpMyAdmin home page, and the default collation encoding at the bottom of the Operations page for the new database. You want them both set to utf8_unicode_ci. If these aren’t set correctly, characters in your articles may mutate mysteriously.

Upload And Extract The Archive

Upload and extract the file archive to the new hosting service, in the directory you created for the new domain/site. One thing that bugs me about IX Web Hosting is that their Webshell times out on large file extractions; and it doesn’t tell you about it. If the server load is high, the extraction terminates with only part of the files extracted. I really wish they’d fix this. It took me two attempts to fully extract the archive, and I had to check it manually. Yech.

Akeeba Kickstart looks like a handy tool for extracting your archive once uploaded, and isn’t Joomla!-specific. Can’t say how well it works though as I haven’t tried it.

Run The Installer Using The Site IP Address

If you’re using Joomla!, run the Akeeba installer by pointing your web browser to the new hosting site using its IP address, and answer the installation questions. The pre-installation check initially failed for me, indicating that IX Web Hosting’s default PHP settings weren’t appropriate for Joomla! Bit annoying, but fortunately they have a 24 hour online helpdesk via chat, so I could get it resolved immediately without having to submit a support ticket and wait till the next day… Even though it was a Saturday. And I’m on the other side of the planet.

Enter the database name and user for the new database you created earlier. Note that you don’t want to point to the old hosting provider’s database server, or your site will appear to work for a while, then break when your old account expires.

If the site you’re migrating isn’t based on Joomla!, then you make have to edit a configuration file to change your database server, name and user. Or run some sort of installer or configuration script again. Double check the database settings because if you leave the new installation pointing at the old hosting service’s database server, your new installation may appear to be working correctly… until your old hosting account expires and everything suddenly breaks.

Test The Site By IP Address

At this point your newly migrated site should be live, but won’t be accessible by the site’s domain name yet, because the DNS still points to your old hosting provider. So find out the IP address of the new site from your new hosting service, and go to access the site via IP address. If it’s on a shared IP address, you may need to dig a little in your new hosting service’s control panel or documentation to find out how to access the site without going via the DNS. Poke around, log in, and check that everything on the new site still works.

Under Joomla!, you need to delete the installation directory at the end of the install process before you can test that you can access and log in to the new site using its IP address. Make sure that you really are looking at the new site, since they will look identical. I found some occasions while accessing the Joomla! backend where the web browser would suddenly jump to accessing the site by domain name, meaning I was suddenly seeing the old site instead of the new. I suspect this is due to some buglets in Joomla! or its extensions that show up with the $live_site setting in configuration.php doesn’t match the real site address. Keep an eye on the address in the web browser address bar.

I found that JoomlaPack wouldn’t work on the new site; the “backup now” button did nothing unless I hacked the $live_site setting to match new IP address. But you don’t actually want to do that, because changing the DNS records to point to the new IP address will make everything kosher again.

Create A New Email Box On The New Hosting Service

If you’re migrating websites, you probably need to migrate any email boxes associated with the domain too; unless you’re planning something tricky with MX records; which you’re probably not. Create the new email box now, but leave your email client pointing to the old email box on the old hosting provider so that you don’t lose any email during the transition.

Unlock The Domain Name With The Old Registrar

Domain names can be locked to prevent spurious or malicious transfer requests from succeeding. You need to unlock the domain name on the old registrar before you can request the transfer to the new one.

For some top-level domains, you need a transfer code to authenticate you as the true owner of the domain with your new registrar. Your old registrar will have a way to request this transfer code if it’s necessary for the domain you want to transfer.

Create A Domain Transfer Request

Log into your new domain registrar and create a domain transfer request. Enter the transfer code obtained from the old registrar to prove that you really own the domain. You’ll need to pay the new registrar for this service; it cost me $15 for two years transferring GreatEngineering.net to Go Daddy. Bargain.

When creating the request, inform the new registrar of the name servers on the new hosting provider. This information is on the Edit Domain page for the relevant domain on IX Web Hosting.

Next you need to wait for the new registrar to contact the old registrar behind the scenes. The old registrar will contact you to ask you to confirm the transfer. Keep an eye on your administrative contact email address for the domain (the one you checked right at the start).

Wait for the transfer to be completed.

Check The New Name Server Settings

Once the domain transfer is complete, log into your account on the new registrar and check that the name server setting is set to the name servers specified by the new hosting provider. If you got this right during the transfer request, they should be set correctly; if not, set them now and DNS propagation delays will mean that your visitors still won’t see any downtime provided you do this quickly.

Try Accessing The Site By Domain Name

At this point there will be a window while the new name server settings propagate, during which attempts to access the site by name may leave you on either site. Try it and see which one you get. You can check which one your machine is resolving to using the nslookup command, but note that other people may be visiting either site until the information propagates to them. So wait 48 hours before actually modifying the site on the new hosting provider if you plan to announce it to the world.

Point Your Email Client To The New Site

After waiting the suggested 48 hours, all visitors should be directed to the new site, as should all email addressed to users at the domain in question. So you can now point your email client to the mailbox on the new site. If you used the same name and password for the new email box you created earlier, then you don’t need to do anything to make this happen as the change in the DNS makes it transparent. In my case, SiteGround and IX Web Hosting’s email servers are sufficiently different that the mailbox name has to be different: IX Web Hosting include the domain name in the user name for the mailbox as their email server, like their database server, is shared between sites.

That’s It!

I managed to do the whole transfer process within 24 hours, having never done one this complex before. Simple, huh? Well, not really; if it all sounds too hard, I recommend you contact someone who does this kind of thing for a living.