Moving between hosting companies made simple
The time has come and you have decided for whatever reason that you need to switch hosting companies; it sounds like an easy enough task, but once you get into it, you will quickly find that there is more involved than initially meets the eye, and it can become a bit of a minefield.
Here we will attempt to explain everything that you will need to know in order to accomplish the task with the minimum amount of fuss and aggravation, and as usual, it all comes down to planning.
Step 1: Understand what your current hosting company provides for you This may sound like a bit of an odd first step, but without understanding what needs to be moved, it can almost never be accomplished easily. So, what to check for? Below is a quick list of what a hosting company may provide to you. Once we have the list, we'll go through each item in turn and explain in some detail what is involved in moving it around.
- Domain names. All of them. Remember to note down every part of every domain name that you have registered: this may include sub-domains and aliases as well as main domain names. Work out what each one does (if anything),how it is used, where it points to and what impact moving it around will have on your business or your life.
- Websites. Again, all of them. You'll need to include websites that are set up for redirections as well as those which only have an API or web service interface too them as well as the ones that your visitors see. Pay special attention to those websites that are contacted by third parties (for example, those with PayPal or eWay integration).
- Certificates. If you have secure site certificates (SSLs) then you will need to know which certificates you have and you must have access to them.
- DNS entries. For each domain that you are moving, you will need to know which DNS entries are in place because all of the IP addresses shown will be changing, and you will need to ensure that they have all been done completely
- Email accounts. This is the one that everyone notices - once their domain name is moved, the e-mail stops working. It's also the most difficult item to deal with during the crossover period
- Databases. If your website uses one or more databases, or your soon-to-be-ex-hosting company has databases hosted for you, ensure that you have access to them
Step 2: Set a time frame for the change It should be fairly evident from the above that moving between web hosting companies is not something best achieved on a spur-of-the-moment decision, or in haste. All that will happen is that your world will come crumbling down around your ankles and you will be in a whole lot of trouble very quickly.
If you've followed step 1, then you'll know what is involved, and you'll know that it takes time to complete. You'll need to understand how long it will take to move your assets to the new company, and how long it will take to TEST once they have been moved. Remember to account for the time taken for DNS changes to take place, and plan what will happen during that time.
The DNS change time is the variable here; it can take anything up to 48 hours for all DNS servers around the world to be updated with the new details. Some will update as quickly as one hour, and there will be others at every stage in between. This means there will be a time where (according to various parts of the internet) your website(s) and e-mail address(es) will be available to two places at once. You will need to plan for this eventuality.
We advise that DNS changes are made at the start of your quietest period. For most businesses, this means making the change on Friday evening so that everything is back up and running on the new severs for Monday morning and you have all weekend to monitor the situation. Of course, each situation is different but that's a general rule.
Step 3: Backup This really should be steps 3, 4 and 5 as you can never have too many backups of something. At the very least ensure that you have backups of your website files, your databases and your e-mails. Remember, when you turn off the old hosting company, you also turn off access to everything they held for you, so if it's not with the new host and you don't have a backup of it, it's lost! You have been warned!
Step 4: Upload your files to the new host and configure everything Website files: This is technically the easiest part of the process but is often the most time consuming. Your new hosting company will generally provide you with FTP access (or a way of creating FTP users for your own access) so that you can upload your files to the new server. The legwork of the actual transfer is largely dealt with by an FTP application such as FileZilla, and your involvement is pretty much limited to selecting the correct files and uploading them to the correct location. Be aware that different hosting companies configure their servers in different ways; some may tell you to upload files to the root of the FTP site they have provided, some to a specially-named directory. In our case, all website code goes into a specially named directory called WWWROOT which is beneath the directory named as the domain name. Other companies use httpdocs or anything else they care to choose.
Databases: A database in reality is just a file (or group of files) like any other so it can also be moved around in the same fashion. The best way to move databases around though is by using a backup/restore process: you backup the database on the old hosting company's severs and you restore it to the servers of the new hosting company.
As usual, there are a number of ways to achieve this and each hosting company again can be different. For us, we use a web-based backup/restore tool called MyLittleBackup for the task (for Microsoft SQL Servers anyway), and you will be provided with the relevant URLs at the right time to be able to achieve this. From a restore perspective, one would point the tool at the backup file that has been created, it in turn would then upload it to the server and install it to the database servers. Again, largely outside of your control, you just have to sit and wait for it to happen.
There may be special requirements in place for a database to be moved; for example, you may have specifically-named users of the database in which case, they will need to be created before the restore is done otherwise you may run into security and permissions problems when using the database. ALWAYS ADD YOUR USERS BEFORE RESTORING YOUR DATABASE.
Finally with databases, remember that the connection string to the database will now be different, so you will need to make code changes as necessary. Depending on your configuration, this could mean simply changing the connection data in web.config, or it could involve re-building a module of the connection string is hard-coded in there. Be aware, once the old host is dispensed with, the connection string will no longer work.
SSLs: If you own SSL certificates, then you need to ensure that they travel with your website. It's a simple process but usually one that you will need your old and new hosts to do for you. SSL certificates can be "exported" from the old host and "imported" to the new, but exporting a certificate does not remove it from the original server. This enables you to have the SSL certificate on multiple servers at once (handy for testing).
As mentioned before, your hosting companies would normally do the exporting and importing for you, all you need to do is get the certificate from the old company and supply it to the new one.
Step 5: Test, test and test again Now that everything is in the correct location (we think) you need to ensure that everything is working correctly. Your new host will normally provide you with a temporary URL so that you can make sure that your website is working properly, and you should use this to make sure that every page is shown. If you have a site that updates the database, make sure that it is updating the correct (new) database etc. Generally, use everything from everywhere to make sure that the website is doing everything that it needs to.
Remember that if you access a secured website from a temporary URL, the certificate will not be in that domain name, so you will get security certificate errors. As long as the SSL shows what will be the final domain name, you are safe to ignore these errors during testing.
Although you will be able to test the website works, and the database is updating, the SSL is in place and any APIs respond, you will not be able to test that e-mail accounts are working. Sadly, this just has to be dealt with by "it will work, we promise you" because it one cannot usually add e-mail accounts to a temporary domain name. But it will work, we promise you.
Step 6: Gather the new e-mail settings With your domain name about to move, it is time to think about e-mails. There is a special section below about some of the e-mail-specific situations that may occur, so be sure to read that too.
Of course, you have e-mail accounts attached to your domain(s), and you need to have them working to ensure that your business functions. So, you are going to need to replicate those e-mail accounts on the new host so that when the name servers change, everything continues to work as it did before.
So now you have a very manual, and potentially time-consuming tasks to perform: you'll need to create all of the new accounts, not forgetting any forwarding that is in place, and groups, distribution lists and everything else. When creating the accounts, it would be best (if possible) to use the same passwords as used on the accounts at your old host just to ease the transition.
Each e-mail user will need to update their client application (Outlook, Thunderbird etc.) to point at new host's severs - this will involve changing the incoming (POP or IMAP) sever address and possibly the outgoing (SMTP) server address. Remember too that the new host may have different authentication requirements for e-mail accounts to the old host, so be sure to make a note of these too and be prepared with how to talk your users through that change. Here is where e-mail then starts to become a little tricky!
Your users may be using either POP or IMAP to access their e-mail, and each has different ways of moving forward. In the case of POP, e-mail messages are stored at the client side so besides having a backup, and making the configuration changes when the time comes, there is nothing much to do. IMAP however, is the complete opposite. With IMAP, all messages (received, sent and filed) are stored on the server; with the server changing, the old items will be lost unless they are specifically moved. Therefore, you will need to download all messages from the server and store them locally before domain is switched. Optionally, you could also upload those (now local) e-mails to the new server so that your users continue with their work with minimum downtime.
Step 7: Changing the name severs We are now reaching the end of the process and we are at the point in our time frame that we have allocated to make the switch. In our example from above, then it is Friday afternoon/evening, and we are about to change the name servers for the domain(s) in question.
Name servers are controlled using the control panel of the company through which you purchased the domain. That could be your old hosting company, or it could be a specific registrar, or it could be a completely different company that you use specifically for managing your domain names. Either way, you will need to access your control panel for that domain and modify the name servers.
** Be aware at this stage that domains are sometimes locked, with something called a registrar lock. With this lock set, name server changes and any other changes will be rejected and your transfer will not occur. Almost all control panel software provides a way to remove that lock in order to make the changes as required, so make sure you do that otherwise everything will stop at this point. **
Generally, there will be anywhere from two to six name servers allowed against a domain (by far the most common number is two, anything above three is frankly, excessive). You will have existing name severs shown against the domain name - these must be removed and replaced with the new ones that your new hosting company will provide to you. They look like any other web address but will usually be named the same as the hosting company that you are going to. For example, some of our nameservers are as follows: NS1.EXPEED.COM.AU and NS2.EXPEED.COM.AU
From the moment you click the update button, the change is taking place. It is incredibly important that you check, double-check and triple-check the name servers you enter. Put in the wrong one and your world goes dark very quickly.
The clock is now ticking on the update, and from here on for the next (up to) 48 hours, your domain is in a state of flux. Some DNS servers around the world will be pointing to the old hosting company, some will be pointing to the new, so you have all of your stuff in two places. Therefore, during this time, you want to have as few changes and updates as possible. Especially to databases as they are hard to update after the fact. E-mails too are a pain during this time as they may be going to different hosts.
The way the update system works is that every so often each DNS server around the world issues a query to establish whether it holds the most up-to-date information about a given domain. If it doesn't then it updates the records that it holds. If you imagine that each DNS sever around the world (and there are millions of them, possibly tens of millions) each checks at different intervals, there are many updates that need to take place (which is why it can take 48 hours).
Whenever you connect to a website, the DNS server of your Internet service provider is consulted, it in turn returns an address of the server as best as it knows it. Your browser then sets off to that address (called an IP address) to get the website you requested. Therefore, if the DNS record on the ISP's network is out of date, you will be sent to the wrong address. Once their server updates its records, you will be sent to the correct address.
How to tell whether you are being pointed to the right place? Well, the best way to check is using a tool called PING. It's available on all PCs as a rule (Windows, Linux and Mac). If you were to use PING (and in Windows it is a command line function, for Mac it is in the Network Utility application and Linux of course it is a command line) it would return the IP address that it will be looking for.
The syntax is normally: ping www.mydomain.com Your new hosting company would often tell you what the new IP address of your website will be so you can match it up to that. Alternatively, if you were to run a ping check before changing the name servers, you would get the old IP address for sure, and would know when it was changed. Remember though, just because it has changed for you, it may not have changed for everyone who comes to your website. Once your ISP is getting the new IP address and returning it to you, that is the time to update the settings of your e-mail client application.
Step 8: A special note about e-mails As has been mentioned already a couple of times in this guide, e-mails are a pain when moving between hosting companies because sometimes they arrive at the old host, sometimes they arrive at the new host. You will need to devise a scheme for managing this process, but often it involves using the web mail interface of either the old or new company.
Up until the point you change your settings on your e-mail client application, you are consulting the old hosting company's mail servers for data. Therefore, anything that comes to the new host will be unknown to you. Likewise, after you change your e-mail client settings you are looking at the mail server for the new hosting company, but if a sender's ISP is reporting the old IP address to them, they will have their e-mail routed to the old host.
The plan: Before you change the settings on your e-mail client, use Outlook (for example) to do most mail applications and the new hosting company's web-based mail interface to keep an eye on anything that arrives there, and deal with it as required. It may be useful to not remove it from there just yet so that you can amalgamate everything later.
Once you have changed your e-mail client settings, use the old hosting company's web-based mail system to keep an eye on "legacy" traffic. Do this for at least two days. When the DNS population has finished (after 48 hours) you can then move the e-mail messages around between the hosts as required to bring everything into line.
Step 9: A special note about dynamic data Databases suffer the same problem as e-mails during the change over period insofar as it is entirely possible for two different sessions to write to different databases depending upon which website the visitor has ended up on. Of course, this presents a problem if yours is a highly-active transactional website because it may involve dozens, hundreds or thousands of transactions. Only you will know the potential extent of this cross over.
It's impossible to give generic advice that will suit everyone because each situation is different, but a simple strategy might be to change the numbering system on tables in the database that resides with the new hosting company. Many tables have auto-incrementing values for their ID, and those values have a start point (normally 1) and an increment (also normally 1). If, for the database on the new hosting company, you set the start point to a number sufficiently higher than the highest number in the table at the point of transfer, you will be able to merge data from the old database without getting duplicates.
This is especially important for shopping cart applications etc.
Step 10: Close the old hosting account The final step in the process is to dispense with the old hosting company. This is not something that should be rushed into either; you need to make sure that everything is up and running under normal operational conditions before you dispense with their services. Remember, once you close that account, you say goodbye to all of the files therein, so if there is something that you need only occasionally you may not notice it is missing until it is too late.
Of course only you know what's best in this situation, but it would be wise to keep the old hosting account for an extra month if possible so that you have access to anything that may have been missed. Of course, if you have copied everything in the first place, and have good, reliable and tested backups then this is less likely to be required.
Conclusion That's how you would go about moving a domain between hosting companies; not the easiest task in the world but by no means the most difficult if it is correctly planned and dealt with methodically.
All that remains is to wish you luck with your transfer. We are here to help you whenever we can, so don't be afraid to ask.
Post Tags: Account Management , Administrator , Basics , Blog , Configuration , Create , Database , DNS , Domain , Email , Hosting , How To , Information , Instruction , Learning , Settings , SSL , Teaching , Users , Website