There are at least three ways to do anything on a server, and testing is no different; there are four methods I can think of off the cuff to test migrated websites. And I only recommend using the first one.
Hosts File Modification
The most accurate way to test the partially migrated websites during your migration is to modify the hosts file on your workstation or computer. An entry in your hosts file would look like this:
123.45.67.89 domain.com www.domain.com
Multiple domains can be added on one line, as long as the first element of the line is an IP. This file is the first stop for your browser when resolving DNS. It’s order of operations goes:
- Is this an IP address already?
- Is there an entry in the hosts file?
- Do I have a cached record?
- Ask my default nameserver.
Since we are testing domains and not IPs, the hosts file cuts in before public DNS is queried. So, your browser is essentially ‘tricked’ into thinking that the DNS has already been updated for this domain, when for the rest of the world, it hasn’t.
This method is more than 99% effective in clinical trials. This is because the server is also ready to serve normal requests for the named domain on its listening IPs.
So as far as the server and your browser are concerned, this is normal legitimate traffic, which is why it is so accurate. This is how the server will react when it eventually receives traffic.
There are some pitfalls, which are common to most every testing method. Objects stored on subdomains would resolve normally, unless they too had hosts file entries. Third party tools that are authorized or verified by public DNS or are licensed by IP would fail to work as well.
Public Proxy
The next method which I begrudgingly accept as an alternative is to use a proxy rewrite tool, such as hosts.cx. In fact I’m not sure that there is an alternative to hosts.cx, but you could potentially create your own by making use of the proxy rewrite options of nginx if you are crafty.
The way this tool works is by utilizing a go-between url, such as 5ubd0ma1n.hosts.cx, translating that into a request with the proper domain name towards a specific IP address (your new server), receiving the response, translating the domain name back for any links, and returning the page to the browser.
Obviously, this takes a bit of time and processing power. Therefore, using this type of testing tool will be unnecessarily slow, slower than real traffic. So, testing throughput or speed will not work well.
I find that these testing links are around 70% effective; they load most of the data correctly, but anything that utilizes a subdomain link or alternative domain could easily direct the browser back to the real domain name, and this is no fault of the server, rather it is a shortcoming in the proxy service.
If you encounter an issue utilizing the proxy, I’ll just recommend that you try using the hosts file, because you cannot eliminate the proxy as the source of the error.
Apache Mod_Userdir or Temporary URL
I recommend against this because it is old and insecure. Essentially, you would test by enabling mod_userdir for a certain user, then browse to the IP address of the new server, suffixed with the docroot call for the user, like 123.45.67.89/~username.
This rarely works, because modern CMSes generate their relative links based off of a specific URL. So, you may be able to browse the home page of your blog, but additional elements would load from the real domain, and clicking any link would take you back to the live URL on the source server.
The only way around this is to change the core URL for the migrated domain to the IP and username suffix, or to use a temporary URL which DNS can be updated for. But, this change must be made in the reverse direction when the testing is finished, and these are two points for human error to be introduced.
Besides, you want to avoid dev work, right?
Update Public DNS Temporarily
Don’t. This is not smart.
Updating live DNS obviously gives a chance for live traffic to hit the new server, possibly allowing someone to post a comment or make an order. If you then switch the DNS back, you will have a divergent data set that cannot be reconciled.
The DNS, though TTL values have been lowered considerably, DNS is a lumbering dinosaur, and if you try to turn on a dime, you may find that your turning radius is a bit larger than you expect. It can take some hours for DNS to propagate, and if some caching nameserver out there has the wrong value, visitors could hit both servers at the same time, exasperating the divergent dataset.
Just don’t do it.
Preliminary Automated Testing
Before you even try your hosts file, it might be good to give the site a shot with an automated testing tool, so that you can see if there are any glaring bugs that should be addressed first.
A tool which I use which is open source (MIT license) is called Marill. This standalone linux binary will analyze the running webserver application (apache/nginx) on a server for hosted domains, curl those sites, and determine the response code, whether any elements went missing, and how many of those. It aggregates that data and turns it into a score, and utilizing a specific threshold, gives each site a pass/fail. Passes likely don’t need a lot of attention, but fails definitely need a hosts file edit and some troubleshooting.
