Step 1: Sign up with a good web host provider
You can do some research work or follow some references to find a good web host for yourself. I preferred by present web host (csoft.net), which I selected after research, and I also found that the readership of the site was growing beyond my expectation. A non-SEO friend of mine used pair.com. Let me refer to the example using IP addresses. If we 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 used for mapping websites to the IP address which a machine uses, like, say, 61.115.6.132.
Step 2: Create a backup of your website on the new web host
You are just in need of copying the whole file to the new web host with a static website. On the contrary, a blog engages MySQL for the purpose of storage of posts and it makes the process a bit difficult. It is quite possible to find some e-commerce sites where the database is always synced and if it happens, you are probably in need of setting up a copy of the database between the old and new location at the time of 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.
You have to remember that you not only have a username and password for both the web hosts, but different usernames and passwords for the database at every location. You might have the MySQL database stored on a unique location, the reason you should know the host option while database restoration. If the new host has a unique option for the database, you will need to edit the wp-config.php file, otherwise WordPress will not be able to access the database on your new host.
At two separate locations, you do have the same copies of your website. The issue of maintaining both the databases synchronized is only applicable to the vast and e-commerce based site. Whereas, someone altering your database at the transition period or a comment getting posted is nothing serious provided your blog is endowed with update of some comments regularly.
Step 3: Changing the DNS to point to the new web host
This is the main thing to achieve. Let me give some fair idea on DNS first. Whenever Googlebot or anybody attempts to reach your site, they look your IP address. They do their best make sure of the authenticity by rechecking the IP address after about 500 fetches, or even check whether certain number of hours have elapsed. Normally, 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.” Obviously, since if you tracked the IP address for all the content on each webpage of your site, the browser would move very slowly indeed.
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.
It elucidates the days of ‘Google Dance’. Staying nearly for a week and based on the data center that the user strikes, it served both the old and new results. Actually, it took many days to move the data to all the centers and having filled it with new data, each data center was overthrown and reinstated. The webmasters used to verify www2.google.com or www3.google.com in this course of time because they directed them to the latest data centers. Now, you can accomplish this entire process at the drop of a hat because of a perfect production system.
Step 4: The need to 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: 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!
. via
