How to Switch Web Hosts
UPDATE (August 8, 2015): after repeated poor experiences with Arvixe, we have changed our hosting solution and have abandoned shared hosting altogether. Here is additional information about why we made the switch.
For the previous five years we at Ten Ten Studios have hosted many sites with a company called AN Hosting -- selected primarily because of their good reviews with regard to Drupal websites. On the rare occasions when we needed it, we received good support and were very satisfied with the speed and reliability of the hosting packages that we purchased. Unfortunately, approximately six months ago (October, 2014) AN Hosting announced that they would be merging with their parent company, Midphase. We migrated all of our accounts into a single Midphase master account and, initially, enjoyed the simplicity of management that this arrangement provided.
However, it wasn't long before we started experiencing the growing (merging?) pains of the Midphase takeover. The first client that we launched on Midphase was a rather large custom project called Art Fair SourceBook and, while the server handled the traffic well, they failed to apply the static IP address to the account which we had purchased. This itself wouldn't be a huge problem except for the fact that another site on the server was sending out spam which caused the entire server (by IP address) to be blacklisted -- including clients that had nothing to do with the spammer. We had another issue with the host changing the MySQL version without notifying its customers, causing downtime as site owners scrambled to make the necessary changes. Ultimately Midphase had to perform a rollback followed by a proper upgrade to solve the problem. And finally, we were faced with a mysterious problem of hundreds of error emails popping into the mail queues, alerting us to an error that was solved weeks prior. While a simple reboot or migration to another server would have solved the problem, Midphase was unwilling to do so. Due to the massive volume of emails being generated, the clients were unable to utilize email at all as they were often forced over quota by this bug.
Arvixe: Onward and Upward
Our search for a new web host took us to Arvixe, a company that received high marks specifically for its Drupal hosting but also received PC Magazine's Editor's Choice award for 2015. To ensure that we had made a good choice, we began by migrating our own site (tentenstudios.com). Hopefully you'll agree that the speed and responsiveness of the site is very good. Arvixe keeps their databases on the same physical machine as the web server software, which is very important to the performance of Drupal sites like this one. While their technical support chat team is a bit slow (possibly just understaffed) they have proved to be very knowledgable and helpful when needed and they offer somewhat rare features like migration assistance for those moving an existing site.
The Migration Process
When you set up a new site it's a relatively straightforward process: upload your site files and database and point your domain to the proper name servers. But moving a live site is not quite that simple. First, you'll need to backup everything on the current host. If you're using a web host with cPanel the process is easy: click the Backups link in cPanel, then click the Download or Generate a Full Website Backup button. cPanel will then compress your entire site (HTML/code, MySQL databases, email settings, logs, etc.) into a single zip file which you can then download to your local computer. Depending on the size of your site this may take only a few minutes or up to several hours.
If you don't have a cPanel web host the backup process is a bit more complicated, though not much more so. You'll want to FTP into your server and download all site files in the site's root folder (typically /public_html or /www/sitename depending on the configuration. Then you'll need to export your database (if necessary) to a SQL file for import into the new web host. This can be accomplished in a variety of ways depending on your database administration software (phpMyAdmin or Adminer, to name two of the more popular options.) Ultimately there should be a way to export the entire database, tables, data, and all, into a single SQL file.
Once you've got all of your necessary data it's time to push it to the new server. Again, the right way to do that depends on your server's configuration, but FTP is a safe option for site files. Just upload the files into the new server's root folder (again, probably /public_html or /www/sitename) and you're all set. If you're using a database you'll need to first create the database instance. In cPanel, scroll to the Database panel and click MySQL databases. Create a new database and a corresponding database user with a complicated password (tip: you can use the same password that you had on your previous server, but probably not the same username.) Depending on your site's configuration you'll need to assign the proper permissions for that user on the new database -- Drupal recommends granting only a handful of permissions but your milage may vary here.
Before You Flip the Switch
You may think that it's time to change DNS and point the domain to the new web host, but there are probably at least a handful of changes that you need to make first. If you're using a database, the odds are good that you'll need to modify one or more configuration strings to make sure that your site can connect to the new database properly. This is because web hosts rarely share the same naming conventions for their users. For example, on your old host your username might be mysi55, and consequently, your database users would all start with that as a prefix: mysi55_dbuser, for example. Your new host might allow you to use the full site name such as mysite, making your new database user mysite_dbuser. Close, but not exactly the same -- and the difference will prevent your site from connecting to your new database properly.
If you open your site's temporary domain in a browser (typically http://servername.webhost.com/~username but not always -- ask your host) you might see a variety of errors. Database errors are typically solved by adjusting connection strings as I've just described, but you might very well see missing CSS, images, or scripts, depending on how you referenced them in your code. These errors are caused by the fact that the temporary URL has your site in a sub-folder (/~username, in the example above) which could break absolute paths. Fortunately, these sorts of problems will sort themselves out when the DNS propagation goes through, but it makes it a bit tough to debug prior to launch.
You'll also want to make sure that your users know that your site is moving. This is especially important in sites that have a lot of user-interaction, such as a forum. From the time that you initiate the backup until the time that the site has been pointed to the new server, no content will be migrated over, unless you plan on performing some potentially complicated post-migration database updates.
If you're confident that you've connected your database properly (if needed) and you understand any URL path problems (if they exist) then it's time for the last step: pointing the domain name to the new web host. To do this you'll need access to your domain name control panel and the two name servers for the new host. If your host is also your registrar, this will be pretty simple. However, if you have your domain registered through a third party you'll need to login to that control panel to make the change. We use Network Solutions for all of our domain registrations so that's what I'll detail here, though the process is the same regardless of your registrar.
Once logged in you'll need to browse to the option to change where your domain points -- this option may say DNS settings or name server settings -- and you should see the current name servers for your domain. Change them to the name servers provided by your web host and save it. DNS propagation should take between 6-24 hours, though we've seen it take less than an hour and as long as 48 hours, so be prepared for some delay and alert your users accordingly.
That's it! Give it some time and you'll soon be viewing your site on the new host. The easiest way to verify that the DNS change has occurred is to use a traceroute application that's appropriate for your platform. Watch for the last few hops which will tell you where the request is being routed. Keep in mind that this will only tell you that your ISP is routing traffic to the new host -- others may still see the old site for some time -- but it's a safe bet that within 48 hours all of the internet will be pointing to the correct place.