Moving a Website to a New Host
:: By Robert Wright ::
Problems with hosted websites often lead site owners to wonder how difficult it is to change Web hosts.
Their frustration may be related to a variety of issues associated with the website’s performance, availability or cost. The simple answer to this question may depend on how much forethought went into the original site and domain set-up, what technology the site uses and which Web host they wish to move their site to. A more useful answer, however involves a thorough analysis of their current situation, and some strategic planning to find and deploy the best solution for their online presence. To demonstrate a typical move, along with some of the considerations and issues involved, the blacklistmonitoring.com website was moved from MediaCatch to DreamHost.
Planning for the Transfer
Ideally, the first deployment of a website involves planning for its eventual move. There are so many potential reasons for moving to another hosting provider at some point in a site’s lifecycle, that to ignore this upfront is to take undue risk. New Web hosts are typically chosen after a reputation, pricing, features and services comparison. The technologies used in the site may also impact vendor (or package) selection. There are many existing resources available to help with the selection of a Web host, so this article assumes that a new host has already been chosen, and focuses on the actual transfer of a website.
The Site Transfer
Three of the most important considerations in moving a website (after host selection) are ensuring that site backups are available, identifying the technologies used/needed, and modifying the domain name servers to point to the new site location.
The need for backups is rather obvious, in that sites can get corrupted or hacked, servers can fail, etc. Most hosting providers keep backups for their clients. It is a best practice, however to also keep multiple local backups of all website files (including any databases) in case the hosting company loses them, corrupts them, or simply doesn’t wish to give them to you.
In the example, blacklistmonitoring.com had multiple local backups available, the latest of which was uploaded to DreamHost.
Ensuring that the new Web host has the platform (hardware, operating system, control panel), software, software versions, and other features required to run the site without issue is part of the due diligence required in selecting a new host. Greater similarity between host technologies usually results in fewer problems with a transition. It can sometimes be difficult, however to find a new host with the exact same configuration as the old host, and some differences may not become apparent until the site transfer begins.
Operation of the blacklistmonitoring.com website required basic Web server capabilities, Structured Query Language (SQL) support, and Hypertext Preprocessor (PHP) support. Most vendors provide these webhosting technologies, and DreamHost allowed the configuration of them per site requirements, so the website move appeared to be relatively straightforward.
The key difference that was apparent upfront between the old host (Mediacatch) and the new host (DreamHost) was the control panel. Mediacatch used the common third-party control panel “cpanel.” DreamHost used a proprietary control panel. So downloading and restoring a control panel backup of the entire website was not an option. Instead, the site files had to be uploaded to the DreamHost server. There were many tools available for this transfer (e.g. various FTP utilities). Since Dreamweaver was used for the design of the website, it was used to transfer the files.
The initial file upload failed, as the new host used a different folder structure than the old host. Although the file location was indicated in the welcome message for the new hosting account, the site profile in the FTP utility wasn’t updated before the first attempt. This was easily remedied and the files were uploaded to the correct folder on the second attempt.
Other software in the site included WordPress (for a blog) and a custom program for checking to see if a specific Internet address is on an e-mail blacklist. Both of these applications had SQL databases which needed to be transferred.
The databases created some trouble for the transfer. At DreamHost, a database transfer requires the creation of a database with the same name and login information as the old one before import. This wasn’t difficult, however the requirements for the database hostname and login differed between the new host and the old host, so modifications needed to be made to all of the databases prior to importing them.
Figure 1: DreamHost Database Creation Tool
The custom program files also had some issues in the transfer process. After some in-depth investigation, it was discovered that the Dreamweaver editor had put some extra control characters into a file that was updated to address the DreamHost database login requirements.
The remaining files for blacklistmonitoring.com were standard html files, image files, and style sheets. None of these presented an issue with the transfer.
Many hosting providers include “free” domain name registration with the purchase of a hosting account. The incentive for the webhost is that this makes it less likely that a client will move their site (due to the hassle involved with moving the site and the domain registration). This is not always in the best interest of the site owner, however, since a move will require the good graces of the old provider to point the domain to the new website server or to allow the domain registration to be moved. Although not always an issue, many providers have been reluctant to allow this in the past, and sometimes delay the process or add other impediments to discourage customers from moving their websites. In contrast, if a domain name is registered at a reputable registrar that isn’t hosting the site, changing the domain name to point to another hosting service is normally quite simple and fast.
The domain name shouldn’t be changed to point to the new location until after the successful transfer and test of the site. This ensures that a broken site doesn’t go live on the Internet. Some vendors, including DreamHost allow the creation of a temporary (mirror) website to see how the website looks before making it go live.
For the example site, the domain “blacklistmonitoring.com” was registered at enom.com, the old hosting provider was MediaCatch, and the new hosting provider was DreamHost. Pointing the domain to the new provider was therefore fast and simple, although it took almost a day before the changes propagated throughout the Internet (propagation delays are normal and not the fault of the hosting vendor). It was therefore necessary to keep the old site live for at least a day until the transition was complete.
Levels of Complexity
After completing the transfer of a relatively modest website, one can see that it is not necessarily a simple process. If the site doesn’t include any databases, special software or programming, then it might be straightforward. Otherwise, it can be a complicated, technical endeavor that requires professional involvement depending on the technical skills of the organization or individual that owns the site.
About the Author
Robert Wright is a Professor of Business at Okanagan College in Kelowna, BC, and President/CEO of Global eBusiness Solutions, Inc. Wright has a background of over 30 years in technology companies, including running multiple start-ups and company transformations.