In Agile world there are no immutable constraints. Your requirements may change, libraries used may be replaced during development, application may outgrown your current server setup etc. I'll show you how to make web application migration between servers as fast as possible: with minimum downtime and data consistency preserved (techniques also apply to hosting providers environment).
Known Problems
You may say: moving a site? No problem: just copy your files, database and voila! Not so fast. There are many quirks you may want to handle properly:
- DNS propagation time
- Database consistency
- Preserve logs
- Preserve external system configuration
- Environment change impact integration tests
DNS Propagation Time
DNS is a distributed database handed by servers along the globe. In order to be efficient some kind of caching had to be introduced. For every DNS record you can define so called "TTL": "Time To Leave" (time in seconds when the information can be cached safely). Typical it's half hour. I suggest you to make TTL shorter (5 minutes for example) during transition.
Then create new site under new temporary address and validate if it's working properly. I suggest to configure temporary.address.com in your DNS and redirect it to your new location. This way you can access new site and validate if all is working properly under new address.
Setup redirection on old site. This redirection will work during DNS update time. Here's example that can be used for Apache (place it in .htaccess if AllowOverride is enabled):
Redirect 301 / http://temporary.address.com
Here's the poor-mans' version that use HTML HTTP-EQUIV header (use it if you don't have .htaccess enabled on your account):
<meta HTTP-EQUIV="REFRESH" content="0; url=http://temporary.address.com">
This will redirect all visitors that open your site in transition period. After it ends add redirect in opposite way: from temporary address to main application address.
Database Consistency
The worst thing you can do is to leave two public versions of your application and leave them "open" for customers. You will end up with two separate databases modifications that will result in data loss (it's practically impossible to merge updates from two databases). I suggest the following procedure:
- Setup new site under temporary address (see previous section)
- Prepare fully automated script that on new site (easy with SSH + RSA keys + Bash):
- block both application instances (service message)
- download database dump from old site
- install database dump on new site
- unblock old site and redirect to temporary adress
- unblock new site
- Test the script (only 2, 3 steps)
- Run the script
- Reconfigure DNS-es
Above procedure ensures:
- no concurrent DB state modifications (only one public version available)
- no updates lost (freeze during move)
- minimum downtime (process is automated)
Preserve Logs
Application logs hold information on application history. They are not critical to application but you may want to move them with application in order to leave historic information for analysis.
Logs could be transferred in the same step as application database. Then new location will just append to transferred logs and all history is preserved.
Preserve External System Configuration
To be checked/migrated (listed in random order).
- Webserver configuration (i.e. virtuals setup)
- Crontab setup that supports the application
- Mail Agent configuration (specific to application being moved)
Environment Change Impact Integration Tests
Your new environment may differ in environment setup to old one. That's why temporary DNS address is very useful here. You can make integration test on new location before migration to be sure no environment changes will break application. The following environment attributes need to be taken into account:
- OS architecture (32 / 64 bit)
- OS (i.e. Debian, Centos)
- Webserver software used (Apache / Lighttpd / Ngnix)
- Database versions
- Application server (JBoss, Weblogic or just plain Tomcat?)
Are there other issues I haven't mentioned?