You probably know that CF Webtools hosts a fair number of sites in our own burgeoning data center. We are not a commodity host (i.e. Godaddy or HostMySite). Instead, we host a large group of Farcry sites, several dedicated servers, and a large group of very complicated Coldfusion sites with special requirements (data feeds, point to point encryption, data aggregation and third party secure services etc.). Our hosting has grown substantially in the last year and has become an excellent revenue center for us.
One of the type of projects we find ourselves doing with some regularity is a "site re-host". Usually a company has an application that clearly requires more help and attention than can be gained using a commodity host and self service control panels. Furthermore, such sites have often "evolved" from widgety little intranet type sites with B2B tools, special custom ecommerce applications or homegrown CMS capabilities into monsters of maintenance with hundreds of pages (many of them titled stuff like "order_bak.cfm" or "index.old"). Incidently never leave a file like "index.old" on your web site. If the web server is in default config mode it can serve that file up to your user without running it through the Coldfusion engine. That exposes your code and makes you easier to attack.
In any case, re-hosting a site seems like a simple enterprise. If your site consists of a database and codebase then it can be simple - but the devil is in the details (and in the cat as my Dad use to say). Here is a rundown that you might find useful.
Before you begin you need to make sure the site owner agrees to no code changes until the re-host is complete. If code changes are critical while the project is underway you will need to re-synch the code "on the fly" during deployment (or make some other arrangement). Usually that's a bad idea and results in errors and customer service issues. In any case, the following steps should be taken prior to moving to a production server.
Time to setup the domain records and email. If the user is using a third party DNS then this step will be part of the deployment script. Otherwise, set up domain records as needed on your DNS server. When the site owner switches the registrar delegate to your DNS server your site will "begin" to be live on your servers (more about this later).
Don't forget about email. You will need to get a list of email addresses (if you are supporting the customers email) and set them up on your email server along with passwords. If you are using POP then you should assist the user with setting up the account in their email client. They will have both accounts set up (the old and the new) so make sure you have a unique way of hitting both servers. This is important because while the domain propagates it's possible for email to go to either email server. If email is important to the customer then you should set up 2 email accounts in the client - the old one can be dropped a few days after the DNS is switched over. Remember this is all in preparation for the switch over.
This is a 1 page list of things you will do and the order in which to do them. These tasks are the "go live" tasks. When you get to the end of the list the site will be live. This is important in order to minimize downtime and loss of data. The list should include your plan for keeping the data in synch, adding maintenance messages to the old and new server, changing DNS etc. Remember, re-hosting a site will bring on unique Data synchronization problems.
Take an ecommerce site as an example. After you make your DNS changes it will take 12 to 48 hours for those changes to "propagate" throughout the Internet. It takes that long for all the thousands of DNS servers to "know" about your changes. During that time the potential exists for orders to be placed on both the old and the new servers. What should you do about that? There are a few of approaches.
In this approach you simply take down the old server and put up a message like "down for maintenance. You take a hit on traffic for 12 to 48 hours but it is the simplest "brute force" method to get this done with no data problems. If the site is mission critical then this is not an option and you will need one of the other approaches.
With this approach your deployment script includes synching the database and then putting a redirect on the old site that forwards the user to the new site via the IP address. Note - you have to forward to the IP address because there is no way to "force" the browser to resolve the domain name to resolve as your new IP address. The browser is dependent on whatever DNS servers it can query. Consequently, you have to redirect to the raw IP address - i.e. <cflocation url="http://xxx.xxx.xxx.xxx"/>.
What's the problem with this approach? SSL will not work as expected. A certificate is bound to an IP and to a domain. Your cert expects "www.123.com" not 126.96.36.199. You can still use SSL and encrypt the page using the ip address like so - https://188.8.131.52. The page will indeed be safely encrypted and from a technical standpoint just as secure as if you used the domain. But the browser will throw warning messages because the domain doesn't match. This will naturally strike fear in the heart of the user and possibly cause a seizure - or worse they could call or email you.
Aside from the warning message, most sites that use SSL hard code the links into specific sections of the site that are supposed to be protected (like shopping cart checkout). The redirect method may result in the user showing up on the new site via IP address, but being redirected back to the old site via domain as soon as SSL is required. Again, using ecommerce as an example, the user would put things in his cart and then click "checkout" - whereas the browser would head back to the "old" site. But the "old" server would not know what to do because nothing would be in the cart on the "old" server.
To make this work usually requires the cooperation of the "old" site host. Other than general goodwill there is little incentive for them to do this. But if you can find a disgruntled technician ready to "stick it to the man" you might be in luck. This method ensures maximum uptime with minimum disruption, but it does pose something of a security risk so beware. In this scenario you set up a new datasource on the old server that points to the new database server (are you with me so far). In order to do this you will have to temporarily fiddle with firewall rules. I recommend opening the port only to the IP address of the OLD server. If you have a security problem you will at least suspect that it originated on the old host network and not on the web at large (at least that is the idea).
During deployment you would take down the "old" site temporarily, synchronize the data from the "old" server to the "new" server, then re-point the code on "old" server to use the datasource on the "new" server. When you bring up the old server and change the DNS both the old and new servers will be live - but using the same datasource. This results in little downtime and keeps your data in synch. You can even do this in advance of the actual switch over if you have time constraints. Please note, although the same datasource is used, this does not mean that sessions are synchronized. So you want to make sure that if the user arrives on Server A, that they stay there and are not re-directed to server B.
As you can see re-hosting a site or application is not as simple as moving code from server A to server B. There are many many details to navigate. Missing a small item (like a jar file for example) can result in lost sales, disruption of service or even a hung server. But if you pay attention to the details you can do it successfully with little downtime.