How to Move Your Website
Published on July 29th, 2008 by Matt Hedges in EcommerceOn Google, any people ask about moving to another web host or IP address without having any sort of glitches. If you have a static website or can spare one day when the site can move between two IP addresses, this would be helpful. However, if you have a dynamic site, the concept will remain the same, but will be slightly more difficult for you. The steps involved in the process are these:
Step 1: Sign up with a good web host provider
You can do a bit of research or follow some references to find a good web host for yourself. The web host you could use is csoft.net, and you may find that the readership of your site is growing even beyond your own expectations. You could also use pair.com. if you move from csoft.com to pair.com, the IP would change from 63.x.x.x to 65.x.x.x. DNS is a system which is used to map websites to the IP address which a machine uses, such as, say 61.115.6.132.
Step 2: Create a backup of your website on the new web host
Having a static website is good as it would just mean copying the whole file to the new web host - that’s it. But having a blog is a bit hard since it generally involves MySQL for storage of posts. Some e-Commerce sites are more difficult for this purpose as the database is always synced over there. In such a case, you might have to set up a replica of the database between the old and the new location during the transition.
Let us cite an example of a WordPress blog using MySQL database which can deal with being down for two hours without too much trouble. Assume that you have used the FTP or tar for copying the static files from one web host to another. You will then need to make a fresh MySQL database on the new host. Usually you can give the same username and database name. if that is not allowed, you can tweak the WordPress wp-config.php on the new location to update the username, database name, and other relevant matters.
You now have a new SQL database so you can get away with the old one, copy it to the new one, and then load the database there.
One has to bear in mind that it’s not only about a username and a password for both the web hosts but it’s about having dissimilar usernames and passwords for the database at every single location. I exhibited the host option while database reinstatement because you can be endowed with MySQL database stored on a distinctive location. In fact, WordPress can’t get into the database if notwithstanding the new host having a unique option for the database, you don’t edit wp-config.php file.
You have similar copies of your website at two different locations. If your blog is just updated with a few comments daily, it is not a big deal if a comment is posted or if someone changes your database during a time when the transition is taking place. However, if your site is huge and based on e-commerce, you will need to work hard to keep both databases synchronized.
Step 3: Changing the DNS to point to the new web host
This is the most important thing. When Googlebot or anyone tries to reach your site, they first look for your IP address. They do their best to ensure the genuineness by rechecking the IP address after about 500 fetches, or even check if certain number of hours have elapsed. Usually people using DNS-enabled browsers are affected by TTL [a setting - Time to Live], which is measured in seconds and says “The IP address you fetched will be safe for ‘x’ seconds; you can cache this IP address and not bother to look it up again for that many seconds.” The browser will move very slowly as you have tracked the IP address for all the content on each webpage of your website.
Sites like Google, Yahoo!, MSN, etc. possess a bit short DNS TTL setting (300-900 seconds) because you intend to have one of them in order to make the data center mechanics perfect for endowing the machines with good data provided you have several data centers. TTL is immensely important as a short TTL lets you drag the IP address of a data center out of the rotary motion very quickly.
This also explains the days of “Google Dance” that went by. It would last for a week or so, and based on the data center which the user hit, they would see the old as well as the new results. The main reason was that every data center was brought down and brought back, after loading it with new data. It required many days to switch the data to all the centers. During the period, webmasters checked out www2.google.com or www3.google.com since they led them to the latest data centers. Nowadays, the production system is properly equipped for switching these things around in lesser time.
Step 4: The need to wait while the DNS change is propagated through the Internet
Being mainly a TTL function, it banks upon the fact if you are really getting to the name servers present in the DNS at this time. Remember that DNS is hierarchical and the process of DNS caches getting into flushes is time-consuming as the TTL is exceeded. This switch gets faster with a smart registrar and a recognized set of the new name servers and it slabs place at the root of DNS. In order to be sure if the new name server is there on the root server, one can employ ‘dig+trace domain’ in UNIX and Linux.
Step 5: You are almost done with your task when you are sure that Googlebot is fetching from the new web host and the IP address. In such a case, the old website can be shut down.
You can check your IP address by pinging your domain. By doing this, you can see your progress. The old visitors, from their own DNS cache, may be using the old IP address, but be sure that the new visitors get the new one. It is considered good to allow a couple of days as a few people might have a long TTL set, even though most of them are for about a day or even less. So after a day has elapsed, it would actually be safe to de-activate hosting on the old location. You can check your logs for foolproof confirmation on this. If your log mentions no visitor visiting from the old location, then you are fully done with it!
Popularity: 5%
