In part 1 of this series I narrated how to shift static sites (i.e. sites without a database) to a new server. In part 2, I wrote about how to get left-over emails after the hosting is shifted. This is the 3rd article in the series which is about shifting dynamic sites (with a database) from one server to another. For the sake of convenience, I have divided this 3rd article in sub-parts and therefore call this one as part 3(1).
There are various types of dynamic sites with databases. The database content is changed by the administrator/owner of the site or the the visitors or both. These are the 4 categories of sites with databases:
- The first category of the site is one without any content management system, but having some sections like newsletter subscription or user registration which uses a database in the back-end.
- The second category of the site is one with a CMS (Content Management System) like Mambo, Joomla, phpNuke, ModX, etc. where there is a back-end database but content change is mainly by the site administrator and not by the visitors of the site. Any change in the database content by the visitors (e.g. newsletter signup, registration, etc.) is not critical to the existence of the site.
- The next category covers blogs and similar sites where the content change is mainly by the administrator but there are frequent changes by the visitors in the form of comments. Although comments are an integral part of a blog, they do not make up the actual content of the site and therefore are not too critical.
- The last category covers sites like forums where database content is changed more frequently by the visitors of the site than the owner/administrator of the site. Here all the changes are critical to the site as visitors’ posts make up the content.
Lets first talk about transferring the sites of the first two categories.
It is relatively easier to move these type of sites without any complete downtime and process is almost similar to static sites. However, sites of the other two types have to be shut down, at least partially and for some time, if the content loss is to be avoided. Please note that there are various ways of accomplishing this task. There are no fixed sure-shot steps to transfer these types of sites and the steps may vary from person to person.
- Check versions: Most important thing is to check the versions of various things installed at the new server. For example, if the old server has MySQL 4.1 and new server has MySQL 4.0, then the database has to be exported for version 4.0. Generally, all softwares are backward compatible. That means that a database working under version 4.0 will work in version 4.1 without any problem, the reverse however, is not true.
- Stop changes: Stop changing the site contents (through CMS or otherwise). Suspend user registrations, newsletter signups, etc. It will be somewhat unusual to suspend user registrations without any message specifying the reasons. So leave an appropriate message on the appropriate page (e.g. â€œThank you for your interest in our newsletter. The site is being transferred to a better server and therefore registrations have been temporarily suspended. We expect the process to take about 48 hours. Please click here and leave your email address and we shall inform you as soon as new sign-ups are resumedâ€).
- Transfer static files: Transfer all static files. Static files mean all .html, .htm, .php, .css, .asp, etc. files alongwith all style sheets and images.
- Transfer database: Since the database updates are stopped, the database can be safely exported and transferred to the new server (I will write later about how to export and import a MySQL database using phpMyAdmin).
- Check transferred site: Check if everything is working properly. If the new server is cPanel, then even before the DNS propogation, you can check your site with http://www.new-hosting.com/~username.
- Change DNS: Now the DNS can be changed. It takes upto 48 hours for DNS propogation to take effect. Additionally, ISPs (Internet Service Providers) have their cache which is not updated too frequently. If you are on good terms with the old hosting provider, request him to lower TTL (Time To Live) which will request the ISPs to refresh cache more frequently. Ideally TTL should be changed at least a week before the actual site transfer commences.
- Resume activities: Keep checking if the request resolves to new server. Once it resolves properly, resume user registration. (As soon as I get some time, I will write some small PHP application which will send an email as soon as the new server starts receiving hits. I will offer this application for free downloading. But no promises as time is the real crunch these days.)
Although it is not critical, it is a wise practice to show at least a holding message or a warning on the main page of the site as soon as site transfer starts till the complete DNS propogation. Here’s a sample message on the main page somewhere in the header (e.g. â€œThis site is under maintenance. Some parts may not work as expected till 10th November 2007, 1530 hrs GMTâ€).
The next part will be about transferring blogs and forums where updation to the site contents are done more regularly by the site visitors.