Many people regularly pop up the question of moving to another web host or IP address without having any kind of hiccups in Google. I completed a successful test of moving mattcutts.com from one IP to another by changing the host, which I will share with you. if you have a static website or you can spare a day when your website can oscillate between 2 IP addresses, it would be easier, but if your website is a dynamic one, things will be a bit difficult for you, though the concept remains the same. Let's go through the steps involved in this.

Step 1: Sign up with a good web host provider

It's always wise to make an intensive research or follow some references in order to have a good web host. As far as I am concerned, I selected csoft.net after the research that did exhibit a brilliant readership, whereas, pair.com was the selection of my non-SEO friend. To clarify the fact, we can assume shifting from csoft.net to pair.com and the IP is going to change then from 63.x.x.x to 65.x.x.x. A machine makes use of DNS system (like 61.115.6.132 ) in order to map websites to the IP address.

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.

Having the new SQL database, you can copy the old one to the new one and the load the database. This is quite simple.

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.

TTL takes on an important role for DNS. Some websites like Yahoo!, Google, MSN, etc. have quite short DNS TTL setting of about 300-900 seconds. If you have several data centers, you will like to take one of them down to enable the data center mechanic to provide good data to the machines. If you have a short TTL, you will be able to pull the IP address of a data center out of the rotation in a few minutes.

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: Wait while the DNS change is propagated through the internet

Basically, this is a TTL function, and is based on whether you are actually switching to those name servers which are present in the DNS currently. Keep in mind that DNS is hierarchical, and it will take time for the DNS caches to be flushes as the TTL is exceeded. This switch, which cakes place at the root of DNS, would be quicker only if you use a smart registrar and a known set of the new name servers. The 'dig+trace domain' can be used in UNIX and Linux for verifying hat the new name server is present on the root server.

Step 5: If Googlebot is fetching from the new web host and the IP address, the process is almost over and one can shut down the previous website.

You can check your IP address by pinging your domain. The old visitors might be using the old IP address from their own DNS cache, but the new visitors should be getting the new one. Some people have a long TTL set, and they should be allowed two days. After that, you can deactivate hosting on the old location. You can check your logs for a fail-safe confirmation of this. When your log mentions no one visiting from the old location, your work is fully done.