Moving Your webSite to a New Web Host
If you're like most webmasters, the thought of migrating your site to a new host doesn't exactly fill you with an overwhelming sense of joy. More likely, you worry, lose sleep, bite your nails, and generally dread the thought. But the truth is that it can be surprisingly easy and painless once you learn the proper procedure.
I should preface this article by stating that these steps are intended for those moving from one shared host to another, not for websites that own and control their own servers. Though the procedure is much the same for the latter as it is the former, the details can vary greatly.
The first and most often overlooked step begins long before you ever even contemplate migration: Owning your own code. Let me explain this in detail, as it is most often the newer webmasters who underestimate the importance of this critical step. The central repository for your website code must always be on your local machine, local server, or some other media under your immediate and direct control. The copy of your web pages that lives on your web server should be just that – a copy. The "Rosetta Stone" of information should live with you and be backed up frequently. Servers crash. It's a fact of life. Sometimes they lose data. You can control your own destiny much more easily if you update your master copy locally and then deploy to your site following proper backup procedures.
Ok, now you've listened to my lecture and taken it to heart. You no longer have to pull copies down from your web server to update your pages. Great. Now we can proceed to step 2 – procuring a new web host. If you haven’t found your new host yet, do it now (for tips on finding a new web host, read my web hosting reviews). Get your new account set up and make sure that it is working properly. Copy your site over from your existing web server (don't delete the files yet) and put them on the new one. If you use a database, snapshot what's on the existing server and copy that over as well. Make sure you have all file and DB permissions configured correctly, and that everything is working as it should. Test your new site thoroughly using the temporary URL or IP that your new host provides. Check your code to make sure you aren't pointing to an IP on your old server, and make sure you’ve properly configured all subdomains and email accounts.
When you are sure that everything is working as it should, you can now proceed to step 3 – DNS. This is where most problems occur. The most common mistake is to change your DNS servers and immediately cancel your old hosting account. You should wait a minimum of 48 hours for the new DNS settings to propagate before shutting down the old server, and I usually wait a week just to be safe. The next most common mistake is assuming that your new host has completely and correctly set up your DNS records in their name servers. It is always advisable to check. If your current host (or domain registrar) allows you the ability to edit your own DNS records on their servers and your new host has given you a dedicated IP, it’s sometimes safer to simply change the A record to point to your new IP. If for whatever reason it doesn’t work, you can quickly rollback without waiting for tech support. The method I use varies from site to site, but the critical part is that I never shut down the old host until at least 5 days of trouble-free traffic has been flowing across the new server.
The last step is to ensure that all of your local mail and database connections point to the new host. I run a lot of MSSQL DTS packages, so I usually do a lot of testing as I’m moving my code over. Make sure your mail is working, too – test all accounts.
Once you’ve completed these steps and run for 5 days on your makeshift redundant system, you can safely shut down the old hosting plan and collect any refunds. That's really all there is to it – a little work, a lot of planning, and a lot of testing, but no drama and no downtime are your sweetest rewards.
If you're like most webmasters, the thought of migrating your site to a new host doesn't exactly fill you with an overwhelming sense of joy. More likely, you worry, lose sleep, bite your nails, and generally dread the thought. But the truth is that it can be surprisingly easy and painless once you learn the proper procedure.
I should preface this article by stating that these steps are intended for those moving from one shared host to another, not for websites that own and control their own servers. Though the procedure is much the same for the latter as it is the former, the details can vary greatly.
The first and most often overlooked step begins long before you ever even contemplate migration: Owning your own code. Let me explain this in detail, as it is most often the newer webmasters who underestimate the importance of this critical step. The central repository for your website code must always be on your local machine, local server, or some other media under your immediate and direct control. The copy of your web pages that lives on your web server should be just that – a copy. The "Rosetta Stone" of information should live with you and be backed up frequently. Servers crash. It's a fact of life. Sometimes they lose data. You can control your own destiny much more easily if you update your master copy locally and then deploy to your site following proper backup procedures.
Ok, now you've listened to my lecture and taken it to heart. You no longer have to pull copies down from your web server to update your pages. Great. Now we can proceed to step 2 – procuring a new web host. If you haven’t found your new host yet, do it now (for tips on finding a new web host, read my web hosting reviews). Get your new account set up and make sure that it is working properly. Copy your site over from your existing web server (don't delete the files yet) and put them on the new one. If you use a database, snapshot what's on the existing server and copy that over as well. Make sure you have all file and DB permissions configured correctly, and that everything is working as it should. Test your new site thoroughly using the temporary URL or IP that your new host provides. Check your code to make sure you aren't pointing to an IP on your old server, and make sure you’ve properly configured all subdomains and email accounts.
When you are sure that everything is working as it should, you can now proceed to step 3 – DNS. This is where most problems occur. The most common mistake is to change your DNS servers and immediately cancel your old hosting account. You should wait a minimum of 48 hours for the new DNS settings to propagate before shutting down the old server, and I usually wait a week just to be safe. The next most common mistake is assuming that your new host has completely and correctly set up your DNS records in their name servers. It is always advisable to check. If your current host (or domain registrar) allows you the ability to edit your own DNS records on their servers and your new host has given you a dedicated IP, it’s sometimes safer to simply change the A record to point to your new IP. If for whatever reason it doesn’t work, you can quickly rollback without waiting for tech support. The method I use varies from site to site, but the critical part is that I never shut down the old host until at least 5 days of trouble-free traffic has been flowing across the new server.
The last step is to ensure that all of your local mail and database connections point to the new host. I run a lot of MSSQL DTS packages, so I usually do a lot of testing as I’m moving my code over. Make sure your mail is working, too – test all accounts.
Once you’ve completed these steps and run for 5 days on your makeshift redundant system, you can safely shut down the old hosting plan and collect any refunds. That's really all there is to it – a little work, a lot of planning, and a lot of testing, but no drama and no downtime are your sweetest rewards.
{ 0 Comments... Views All / Send Comment! }
Post a Comment