The Pitfalls Of Site Transfer

This entry was posted in General Musings by Cleave on

It is good to finally be back and blogging again about all my nutty ideas and topics. For any of you that have been following my blog you will have noticed that the blog has not been updated in a few days and it was even off line for at least 2 days. 2 days might not seem a lot of time but when you are doing things online that can seem like an eternity as you are just itching to take and get going again. It is so good to have the blog up and running again.

A few days ago I found that it would be beneficial and better to have my site and the blogs as well as the phpBBS hosted on another server. In this case it is actually on a cloud server that is provided by Web Hosting Period They have some really good deals and so far the site is running faster and better then it was on the old server. Speed and reliability was the reason for the switch and so far I am really pleased at the results.

As to the pitfalls I started the title about. Most people just do not realize what goes into a server hosting switch. First you have to sign up for an account with another hosting company and most people think that is all there is to it. After you sign up you then have to get your site ready for the move. While it is true that I could have moved all the site myself as it was not all that extensive, I had the hosting company move it as site to site or rather server to server transfer is always quicker then what you can do on your own without root access. For those that don’t know what root access is, it is base level OS access to the server. With root access you can do anything on that server just like you are able to on your own computer, if you know how. And it is almost or mostly done on the command line. Anything not done on the command line is usually just an interface that sends the complicated commands for you to the command line. Now, enough of that confusion, I was talking about getting a site ready for a transfer.

To get your site ready for the move you have to make sure that everything is running as it should and that no extra stuff is running that might interrupt the transfer. In a really busy or large site you might see them actually put up a maintenance page till everything is moved and is ready to go back online. Since my site was small enough, under 300mb, I just made sure not to have any blog stuff going on so that the databases would not get corrupted. Another thing that you should always do before a move is to make sure that you back everything up, that way if anything goes wrong you will not be up the creak without a backup. The backup would be anything that is in your home directory. That is the directory that you log into when ever you are using either a webdisk interface or ftp to manage your site. You will also want to make sure that you back up each one of the databases individually in a format that could be used to either replace an existing one or to create the database from scratch from the information in the back up. Another thing that some will forget is to backup any and all email boxes that have been setup as well as any forwards or aliases. Once you have done all that and checked to make sure that the information saved is complete, that is when you request the transfer.

So, You sign up for the hosting account
Then you back up your site
Then you request the transfer
Once you receive confirmation that the site is transferred you go on to the next step.

Now not all hosting companies are going to have the same pathing or file structure but most UNIX – Linux based systems will be very similar. I bring this up because when you have scripts running on your site they have to know where to get the information from. It doesn’t just come from the databases that you had setup, they also use configuration files. With my transfer the pathing was only one letter different so I had to go through each one of the scripts and make sure that they were set to read the correct directories. If they don’t read the correct pathing for the directories they they will not function as intended and most times will not even function at all. That is why when a site is moved you might see errors pop up all over it, it is because someone did not go and check all the pathing in the scripts.

Once you have all your scripts set correctly in their configurations, then you will take and go to the registrar of your domain name and change the NS information for your site. In my case it was Go Daddy So I logged into my account and then removed the NS information that was there and put in the new NS information that was supplied to me when my new hosting account was setup. Now comes the hard part, you wait. And you wait, and wait and OMG oh my gods, you wait. Are we done waiting? Nope, not yet, you have to wait a minimum of 4 hours for the new DNS and NS information to start to kick in and even then it can in some extreme cases take 3 days for the world to know about the switch. That means that you can not make changes to either the old site or the new site till you KNOW that everything is set to the new NS and DNS information. You want to make sure that everyone is seeing the same thing at all times. In my case the NS information kicked in after only about 45 minutes, but not so with the sub domains.

The sub domains were the real issue. Both blogs and the BBS forum are on sub domains and with the DNS not routing for those they became totally invisible to the Net as a whole. With the way that NS and DNS work you have to wait a minimum amount of time before you can actually do anything about the problem. So I had to wait 2 days, 2 nail biting days, before I could get someone to fix the problem. You might be thinking that I should have done it after only a couple of hours but there are policies in place that require the wait time as it might not even be the new hosting companies fault at all. It could be the registrar where the information was stored. It could be the fault of a router that went out halfway across the world. It could literally be any number of things that might cause the problem. So you have to wait.

So, here we are 48 hours later and I am writing my blog again. For some reason the DNS did not refresh between the registar and the hosting company and the needed A entries for the subdomains were not passed along into the main DNS records. They were on the server, but they didn’t get put into the main record. When this happens it is not oversight, it is because a glitch might have happened when the record was being made. If the server or any server in the process pauses or skipps a beat, so to speak, it can cause everything on both sides to report that everything is ok, even though it didn’t complete. It was stuck in cache limbo. So a quick support ticket to my host along with a trace route for my sub domains and they cleared the cache and made sure that the changes went in proper.

Its just the waiting that is the hardest thing to do. :)