What You Should Know Before Changing Web Hosts!

1) Introduction
So, the time has finally come! You are unhappy with your current web hosting service for whatever reason and are looking for a new home for your web site(s)

Maybe your web site seems to be "down" just a little too often? Does your site seem to be running slower and slower lately? Is customer support hard to get hold of and unhelpful and condescending when you do? Have you been with your current host so long that their $29.95 a month plan (which was compettive when you signed up 5 years ago) is not looking so hot now? Perhaps your site has just become too popular for its own good, and your budget shared plan is no longer up to the task? You need more features and flexibility than your current host offers?

Changing web hosts does not have to be a long, complicated or painful experience, as long as you do your homework first, make a note of all the steps you will need to perform, and execute them carefully and methodically!

2) Do You Really Need To Move Hosts?
If you are happy with your current host, but have simply outgrown your current plan; for example:

You need more bandwidth than your current hosting plan offers. You need more hard drive space than is provided. You just need a more powerful system to cope with traffic.

Before automatically assuming that your current provider is not up to scratch, it might be worthwhile to see if they can "upgrade" your plan to something better able to accommodate your needs.
However, bear in mind that sometimes, hosting companies are a bit sneaky and offer very cheap "budget" plans, which are generally only suitable for static HTML sites, knowing full well that and as soon as users try doing something a little more dynamic, they can "hard sell" an upgraded plan that is not such a great deal.
This tactic is thankfully very rare amongst reputable hosting providers.
Our advice is to not always look for the "easiest" solution, but to the solution that will benefit you most in the long term, and the one that you are happiest with.

3) How Busy Is Your Site? Will You Need To Warn Customers / Visitors Of The Impending Move?
Even the best executed move can sometimes have unexpected side effects.
If your site is moderately busy, it is often good practice to warn your visitors of the move, and that some disruption may be encountered.
This warning need be nothing more extravagant than a simpe line or two of text at the top of your homepage.
If your site has few visitors, then you may well feel justified in not bothering with this step at all!

4)The Actual Steps To Moving Your Site!
1) Firstly, if you are moving because of a problem with your host, please resist the urge to Email/Phone/Write them telling them where to go! Whilst this may give you short term satisfaction, your account may be instantly terminated, leaving your website dead in the water!
This is especially true if there are files on the host machine that you need to retrive (and there probably will be, especially if your site is database-driven).
This leads us to:

Step 1): GET ALL YOUR WEB FILES ONTO YOUR LOCAL PC

For a lot of people, this will be a non-issue, as they religiously keep local copies of all web files anyway.
If this doesn't sound like you, then the first step is to make sure you obtain a "snapshot" of all the web files currently on your host stored locally on your PC's Hard Drive.
This includes all files, both those stored in your public_html directory on the webserver and those you may have uploaded to directories not publicly accessible (generally to folders above the web root).
The best way to do this is to access your web account using SSH (Secure SHell) access to create an archive of your entire home directory, then download this archive using an FTP (File Transfer Protocol) client.
However, most shared accounts do not allow the user to have SSH access for security reasons, so using FTP to download file by file is the next best thing.
There are many good FTP clients, from free ones including FileZilla , to commercial clients including CuteFTP and Ipswitch WS_FTP Pro.
If you are unsure how to effectively use your FTP client, there are numerous tutorials to help you out.

Step 2): BACKUP YOUR DATABASE(S) IF APPLICABLE

Use the universally available phpMyAdmin (if you are running php) or an appropriate tool for SQL Server, Oracle etc.
Note: Transferring databases is not quite as simple as transferring static web files, since until your site is fully transferred, you may have to deal with database updates both to your existing database and the database on your "new" host.
The exact steps you will need to take to backup your database are beyond the scope of this article, but generally one option is to use the tool to create what is known as a "backup script" file.
This file is generally a plain-text file, and contains a series of "database instructions" that when executed in the appropriate context, allows your database to be restored in all its glory!

Step 3): UPLOAD YOUR FILES AND DATABASE TO YOUR NEW HOST

Using your FTP client, this process is the reverse of download, and simply involves selecting the files you downloaded in step 1, and uploading them to your new host.
It is assumed that you have already selected your new host at this point, and that (obviously), if you are moving from a Windows-based host, your new host is also Windows-based, and similarly if your old host is Linux-based.
Uploading your database is a bit trickier, since depending on your configuration, you will probably have to manually create the database (remember to name it the same as it was previously), and also create the same user accounts, and give them the same permissions as your old system.
Generally, most web-based database driven systems use a simple one-user account database, and all web connections use this same account, so this step should be pretty straightforward.
Also, your "backup script" that you created in step 2 may or may not contain commands to actually create the database (as well as insert all your data).
In our experience, we feel it is better to create your new (blank) database manually and use the scripts purely for database data "population".
In the cases where your database is extremely large (over 100MB for example), you will often find it is impossible to restore the data effectively using web-based programs like phpMyAdmin.
In cases like these, the best solution is to use your database itself to create a single "dump" file. This will need to be copied to your new host and used via the database to recreate your new database.
This method is a lot more efficient and reliable, but requires SSH access, something you are unlikely to have with shared accounts.
In some cases, your new host may offer to help out.
Just don't expect your 500MB database to run very fast on a shared server, however!

Step 4): CREATE ALL YOUR E-MAIL ACCOUNTS AT YOUR NEW HOST

The last thing you'll want (especially if your site relies on E-mail heavily) is E-mails going astray, or irate customers calling you demanding why you are ignoring their E-mails.
Take the time to make a note of all the accounts you have set up at your old host (examples might be: webmaster@yourdomain.com, sales@yourdomain.com, customerservice@yourdomain.com, etc.)
It should only take a matter of minutes to set up identical E-mail accounts at your new host.

Step 4): TEST YOUR NEW WEBSITE

At this point, your web address will still be pointing to your old hosting space, so you will not be able to test your site using the www.yoursite.com style address.
However, with most accounts, you can access your webfiles using an alternative syntax that looks like the following: http://www.yourhostsaddress~yourusername
You will need to contact your host to find out what address you need to use for this to work. In some cases, you will need to use an IP address instead.
There can be certain complications if you are using advanced features in your web site like apache redirects, since these often cannot be tested until your domain name is fully propagated to the new address.
These cases are beyond the scope of this article, and we would advise you seek professional assistance if you are not confident enough to do this yourself.
If you have password-protected areas of your site, don't forget to check that these are working as expected too, since password files are stored outside your public web area and are often overlooked when transferring files.