There may be multitudes of reasons why someone may need to switch hosts, but one thing that is common for everyone planning the switch, is a concern for server down time. However, with proper planning and execution, server down time of any significance can easily be avoided. In this article, we will discuss the steps that must be taken to avoid down time when switching hosts.

Choose the Right Host
Choosing the right web hosting company is one of the most important, if not the most important, aspects of minimizing the downtime when switching hosts. Below are some of the considerations that must be kept in mind when deciding on a host to switch to.

a. Compatible Infrastructure. Compatibility of hardware and software infrastructure with the requirements of your website are perhaps the most critical factors that must be researched in order to avoid any downtime while switching hosts.

If the site being transferred consists of nothing more than static pages, images and flash files, then compatibility of the server environment and hardware is not a major concern, as such sites do not require any server side processing to generate pages.

However, if a website uses a scripting language or a database backend, then it is of paramount importance that the server environment and script compatibility are checked. Software coded in scripting languages, such as PHP or ASP, needs to have certain software installed and running on the server, before they can operate properly.
Before you decide on the host, contact the hosting company to ensure that the server you will be hosted on has the required version and related modules of backend software and database software installed. Certain scripts require the scripting language to be compiled in a certain way, so that must also be ensured beforehand.

One of the biggest causes of downtime is the incompatibility between scripts running on your website and the web server. Having a clear checklist of requirements and ensuring that the web host supports them, can avoid surprises and downtime after the move.

b. Customer Support. A web host with a customer service department that responds quickly and has the technical know-how to solve problems when they arise, can be a critical factor in avoiding down time when switching hosts.

Even though there is no reason why a website should suffer down time if the host switch has been planned properly and executed according to the plan, if something does go wrong, a host with a fast customer support team can fix the problems quickly and help you minimize any down time that may occur.

It must be noted that usually different staff manages the pre-sales and customer support departments. Because of this, it is not feasible to be able to gauge the quality of customer service on the basis of the speed and quality of pre-sales responses. For this reason, it is best to research the reputation of the web host on independent forums and review sites, such as webhostingtalk.com.

c. Scalability Support. It is usually better to choose a web host which offers a choice of multiple hosting packages. A host that offers a selection of shared hosting, virtual private servers and dedicated servers can allow a website to scale-up in resources without any downtime, should the need arises for an upgrade.

Backup, Backup, Backup
Once the right host has been chosen, the next step is to backup all files and databases on the server. The complexity of taking backup of a website depends on if the site uses static files or if it consists of dynamic scripts to generate the pages.

If the site consists of static files, all that needs to be done to take the backup of the site is to log in to the server using FTP software and simply download all of the files on a local backup drive while maintaining the file structure. Since the site doesn’t need an external software environment to operate, there are no configuration or installation files to worry about.

However, if the site uses a dynamic content management system written in a language such as PHP, ASP, Ruby on Rails or Java, then simply copying files from the web server to a local disk may not be enough to take the complete backup of the site. It is necessary to refer to the original installation instructions of the software in order to ensure that all of the script dependencies and databases are available to take their backup.

Furthermore, the script running the backend of the site may use caching techniques and a database to manage the data. In such cases, it is also advisable to take a backup of the cache folders as the script may try to look for the cached data on the new server.

To take a backup of the database, one can use database management tools available in most hosting control panels like cPanel and Parallels. However, such tools work only if the database site is small and there is a possibility that they can fail on databases which contain a large amount of data in them. In such cases where database tools can’t be used to take the backup, one can use SSH to directly connect to the server to make a data dump, and then download that backup using FTP software.

Moving Files & Databases
Once everything has been backed up from the old server, it is time to move the files and databases to the new server. Since the changes to the name server have not yet been done and the objective is to avoid any downtime, the files will be moved by connecting to the FTP server using the IP address and accessing information provided by the new web host.

If the site uses static files, one simply needs to upload the files downloaded in the previous step to the new web host while maintaining the original directory structure. Since there is no special software involved here, no configuration changes may be needed.

However, if the site uses a dynamic content management system, then the complexity of moving files increases, as there may be slight changes in the server environment and the configuration files of the script may need to be modified for the site to operate properly.

When moving a dynamic site, the first step would be to simply upload all of the backed up files in the previous step to the new web host. After this, it is necessary to open the script configuration file and investigate to see if any of the variables need to be changed due to the change in server environment. If the configuration file has been changed, then it needs to be uploaded again on the new server.

If there are any databases being used to operate the site, one needs to login to the control panel of the new server and create a new database to be used. After the database has been created, database management tools can be used to restore information in the database using the backup taken in the previous step.

However, such database management tools can operate only if the database backup file is under a certain size limit, beyond which they could fail. If the database cannot be restored using an online database management tool, one can upload the database backup file on the new web server using FTP software and then restore the data from the backup file by using SSH.

Testing the Change
Once the files have been uploaded on the new server, the next step is to ensure that the website is working as expected. To test the website on the new server, one can usually access it using the IP address provided by the web host.

To access the website, open a web browser and enter the IP address of the server. Once the site opens, in case of a static web site, you should ensure that all the links on the pages are working properly, that all pages are accessible and all images and flash files are loading.

In the case of a dynamic website, one must not only ensure that the front end of the website is accessible and operating as required, but also access the backend administration system. If the site allows user registration or sends email, then it is advisable to also create a new user account for the sake of testing. It may also be a good idea to feed some content into the content management system, to ensure that the database connectivity is proper.

Modify Name Servers
Once the files have been moved from the old server to the new server and the site has been tested to be operating correctly, the next and final step is to modify the name servers. This step has to be accomplished at the website of the domain registrar, unless the domain uses a hosted DNS service.

The method to accomplish this is to log into the domain management control panel at the website of the registrar where the domain had been registered. Once inside the control panel, the next step is to navigate to the page where one is allowed to modify the name servers. Once on the name server modification page, the old name servers can be over-written with the name servers that have been provided by the new web host and the changes be saved.

Once this step has been accomplished, depending on the ISP, it can take up to 72 hours for the domain to be resolved to the new web host. To ensure that the domain is resolving to the new server, one can upload a unique file on the new server which doesn’t exist on the old server and try accessing it from the web browser. If it opens, then the domain has been resolved to the new server.

Cancel Old Account
Even though the domain may start resolving to the new server for you, there are chances that the domain still may be resolving to the old server in some instances. Because of this, it is best to wait at least 72 hours before canceling your old hosting account.

After 72 hours have passed and everything is working as it is supposed to be working, one can safely go ahead and cancel the account at the old hosting company. It is also advisable that all communication regarding cancellation with the hosting company is saved in case any disputes arise later.

Mission Accomplished
Making a switch without any glitches or downtime is just a matter of proper planning and execution. If the steps outlined in this article are implemented properly, then the site should have been moved from one web host to another successfully, without having any downtime.

Related posts brought to you by Yet Another Related Posts Plugin.