I’ve migrated more web hosts then I care to count yet it seems to remain for the most part a mystery and magic trick to migrate a hosted web service ( in this case I’ll stick to general web hosting ) from one server to another without fault or downtime.  In other-words a seamless migration.

I recently migrated a miscellaneous handful of web sites and associated services from GVO (Possibly the worst hosting company I have ever worked with) to Site5 (reasonable, affordable, simple hosting).  Here’s how I went about the seamless transfer.  In this case both hosts had cPanel & WHM however due to the websites on GVO being setup as add-on domains rather then standalone accounts I wasn’t able to just backup the whole picture in a single file and publish it to the new server.  The intent was to properly setup each domain as it’s own account (grouping some domains within a single account when it made sense to do so)

Logically the whole operation breaks down to individual domains or sets of domains most often simply redirecting to a single primary domain.

Information & Resource Gathering

Identify the Domain’s Registrar, owner and management credentials or the person responsible for managing (paying for) the domain name itself. This might be Godaddy, NetworkSolutions, etc. This information is easily sourced through a WhoIs Query.

Identify the Domain’s Name Servers and again, source the management credentials for the Name Server Zone File. Name servers are NS1.SOMETHING.COM and NS2.SOMETHING.COM and so on.  This information can be sourced from the Whois data as well. Managing a domains Zone File is often done within the existing hosting account’s control panel.

Review the domains Zone file.  Grab a copy of it even.  It’ll reveal all the sub-domains, redirects, mail server exchanges & so on.  These are all the items you’ll want to make sure migrate properly if necessary.

^^ simple zone file records ^^

Simple (standard?) web hosting can be broken down in to three primary elements.

1. Files
2. Database(s)
3. E-Mail System

Files can usually (simply) be copied from the old server to the new server.  Keeping the file permissions in tact during the transfer is healthy otherwise ya end up with file upload folders like you find in WordPress that no longer allow files to be written to them.  This can get especially complicated in old school LAMP environments where apache runs as a single user. This is however this is not the case in most windows environments.

FTP User Accounts – Sometimes a client will have multiple FTP user accounts for various reasons – don’t overlook them.   Occasionally I’ve run in to situations where clients (or I) have setup automatic backups over ftp/sftp both to and from the web host.  Identifying the things you’re going to break before you break them is always handy.

Databases are another simple acquire -> post situation.  Given phpMyAdmin or MySQLDump just export the databases from one entity and then import in to the next.  I create new username/password combinations for simple websites and CMS systems like WordPress,etc. If for whatever reason you are unable to duplicate the previous hosts database name, user name and password you’ll want to update the configuration files for the website if it did make use of a database resource.   A last note on databases: It’s been a few years since I’ve seen any issues migrating from one database version to another but it’s still worth noting that if you’re migrating between different DB versions (such as MySQL 5.7 and 5.8) – be prepared for problems. Try and upgrade the old database or import and update the data before trying to import between database versions.

Consider purging the junk – It’s easy to simply copy all databases to a new host.  It’s prefer to not let the clutter and waste build on web servers.  I always think in the back of my head that eventually some old unused piece of code or database entry will be used to exploit something so it’s best purged when possible.  In most cases it’s not necessary but if files and content are not being actively used then their only real use becomes the target of exploits.

E-Mail systems are (in my opinion) best operated outside of the web hosting environment but since email hosting comes as part of the standard package of web hosting you’ll often find e-mail accounts and the mail exchange are all on the same machine.  I’ve been a fan of Google Apps for Business for my own e-mail which requires no changes during a host migration – just remember to maintain the same MX entries in the domain’s Zone File.

Setup the New Host

Matching the existing setup – configure the new host environment.  Transfer files, Databases, E-Mail accounts, etc.

To ensure no changes are made to the files and database (CMS content) on the old server while setting up the new be sure to disable any login systems, FTP accounts, etc.

After I think I’ve got everything setup on the new server properly but BEFORE updating any DNS, NS or otherwise making the new host live I add an entry to the Zone File on the old server or Name Server management resource that points to the new host and begin testing the environment with a subdomain of the existing domain. I also add the same detail to the new host just for the sake of consistency.  This is generally enough to test most CMS systems with little trouble.  While I’m making updates to both the old and new host’s Name Server Zone File configurations I also add a subdomain (A) record targeted at the old host.  It’s come in handy a time or two. In this case

• (A) site5.domain.com  =   IP.Address.of.New.Host
• (A) gvo.domain.com    =   IP.Address.of.Old.Host

Now – after doing as much testing as possible, get someone else to review what you’ve done.  Generally speaking the customer or client is not a good target for this task.  Just !ping another tech with whom you share system administration tasks, resources, and so on.  A quick review isn’t much to ask and will help make sure that nothing blatantly obvious was overlooked.

While your work is being reviewed setup some simple automated backups.   Don’t rely on your host in any situation as the sole overseer of the content you rely on them to maintain.  I’ve played every role there is from managing simple reseller hosting accounts to maintaining dedicated, collocated & self hosted servers and in the last 12 years I have seen catastrophic failure twice.  The first time – there were no backups outside of the host that crashed and I lost years of resources so no matter how wild or far fetched a failure would have to be to truly atomize everything beyond any capacity to recovery it – it can and will happen.  Prepare for it!

Then….

FLIP THE SWITCH

Update the domain name Zone File primary (A) record to the new server & then update the DNS entries of the domain at the registrar to the new site.

…and test. test. test.  Everything should be green – bring on the client to verify every page is perfect.  Run a link checker, monitor system logs, etc.  I use UptimeRobot as a 3rd party resource to see if my sites kick rocks outside of my own monitoring.  If you seamlessly migrated from one host to another then none of your uptime monitoring tools should have complained.  Further – google webmaster shouldn’t complain either.

I’m sure I skipped a bunch.  I’ll add it as I realize what those things are.