One pseudo gotcha I forgot to mention. If you're running SSL on your site, the SSL cert is generally tied to the main domain (www.mydomain.com.)
So, if you're doing an https:// redirect to the new server and it doesn't have a matching SSL cert, the user will be prompted on whether or not to "accept" the cert. You could avoid this by buying a real cheap SSL cert for whatever domain name/ip address you're going to forward to. The el-cheapo SSL certs work with the majority of browsers and would make the issue seemingly completely transparent. If you're not working with SSL, then this is not an issue at all. -Dan >-----Original Message----- >From: Andrew Scott [mailto:[EMAIL PROTECTED] >Sent: Wednesday, June 06, 2007 5:10 AM >To: CF-Talk >Subject: Re: How to handle the transition period to a new host? > >I have never had to do this, but I think this has got to be the best >solution that would work without any problems. > >Dan, nice post and very informative if ever I find myself in that position. > > >On 6/6/07, Dan G. Switzer, II <[EMAIL PROTECTED]> wrote: >> >> Mike, >> >> >I'm going to be moving a fairly high-traffic site to a new hosting >> >company in a few weeks, and I'm starting to plan out the tasks that >> >need to be done. >> > >> >How do you guys handle the transition period while the domain is >> >delegating, which can be up to 4 days? For this period, both sites >> >will be active, depending on the status of the dns servers the users >> >are connected to. >> >> Having just done this a couple of weeks ago, here's what I did. Once we >> migrated data to the new servers, we could not afford to have the old >> servers being used--because data would be out-of-sync. >> >> 1) If you have the time before hand, you could create a domain for the >new >> server (like www2.mydomain.com) that points to the new server IP address. >> This isn't necessary, but it will allow you to "hide" the IP address of >> the >> new server. >> >> 2) Once your data is migrated and you're ready to start using the new >> site, >> just use a <cflocation /> in your application.cfm to forward any requests >> to >> the new site. Something like this should work: >> >> // general UDF library >> function getCurrentUrl(){ >> var sUrl = CGI.SCRIPT_NAME; >> var sQueryString = CGI.QUERY_STRING; >> var aKeyPair = ""; >> var i=0; >> var sRegEx = ""; >> >> // the template name is not appended to the script's name, append >> it >> now >> if( NOT Compare(Right(sUrl, 1), "/") ) >> sUrl = sUrl & getFileFromPath(getBaseTemplatePath()); >> >> // if the query string is not empty, append the full URL >> if( len(trim(sQueryString)) ) sUrl = sUrl & "?" & sQueryString; >> return sUrl; >> } >> >> <!---// >> Make sure to replace "www2.mydomain.com" with your real domain >> //---> >> <cfset sNewUrl = iif(CGI.SERVER_PORT eq 443, de("https"), de("http")) & >> "://www2.mydomain.com" & getCurrentUrl() /> >> <cflocation url="#sNewUrl#" addtoken="false" /> >> <cfabort /> >> >> As DNS begins to propagate, you'll see the hits on your old server >> diminish >> and eventually stop altogether. >> >> This will all be completely transparent to the user. >> >> -Dan >> >> >> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Upgrade to Adobe ColdFusion MX7 Experience Flex 2 & MX7 integration & create powerful cross-platform RIAs http://www.adobe.com/products/coldfusion/flex2/?sdid=RVJQ Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:280221 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
