Forum Moderators: phranque
As expected, the move wasn't a slamdunk. Ignoring the usual DNS confusion-induced issues when the IP address changed, we saw things like these crop up:
Blog/CMS Software Failure. First, the PHP path was different and the script wouldn't run. That was simple. Then, everything looked fine, but authors couldn't log in. Not so simple. After a couple of days of messing with permissions, we finally identified a mismatch in the versions of the underlying database. As soon as the host installed the version that was on the old server, it started working.
Custom Error Processing. I knew this would be a problem, and wasn't disappointed. The site uses finicky IIS settings to make this work, and despite our cautions the host didn't get this right the first time. After a couple of tries, they got it right.
Mail Generation. The site's order processing software had used ASPMail. The new server had a different program, which naturally caused stuff like order notification to break. We switched to CDONTS mail, which appeared to work. We then discovered that customers would get notified, but not the site owners. Another couple of days of trouble tickets (and the host blaming the software) finally led to the discovery that the new server wouldn't send CDONTS mail to the same domain (i.e., like the site owners' e-mail addresses). Alternate e-mail addresses were installed while the host figured out why the original ones wouldn't work.
Form Processing. In a bizarre reversal of the preceding item, the form processor used Sendmail, which on the new server would ONLY send to an internal e-mail address. Thus, when we tested the script using an outside address, we got no mail. It actually would have worked for the owners.
There were probably some other issues, but rather than bore people to tears, I'll go to my question. I'm wondering if anyone has developed a server move checklist or other technique that minimizes these sorts of issues. Clearly, bringing the new site up on an IP address and testing it is one solution, and indeed we caught some of the problems above during this phase. The functionality of some items is locked into the domain, though, and one can't really fully test them.
I've got an even bigger move coming up (this one's Linux/Apache), and I'm hoping to make it smoother. Thoughts & suggestions?
An IP address change shouldn't be an issue so long as you have sufficient notice of the change and have access to the DNS records for your domain.
When an IP address is requested from an authoritative DNS server for your domain, the requesting DNS server also receives a Time To Live value (TTL).
The requesting DNS server is entitled to cache the address record received on behalf of future requests for the same host for the period specified in TTL.
So step 1 in the count down to an IP address change is knowing what your current TTL value is. If you don't know, search for "DNS Tools" - there are websites that can look-up the value for any given host name and display the current settings.
Step 2 involves changing your TTL value at least the current setting before changeover time - so if your current TTL value is 2 weeks then you must do this at least 2 weeks before changeover time.
What you change it to depends on how considerate you want to be to the Internet and your authoritative DNS servers.
The easy option is to set it to ZERO. By doing this, you can guarantee that by changeover time, every lookup will be coming through to your authoritative DNS. After changeover, set TTL back to a more sensible value.
If you are running a very busy site you should binary chop, say from 1 week down to 6 hours before changeover, and then go to zero.
