Now first a little remark about this post: This post will not handle the actual upgrade from MOSS 2007 to SP2010. It will only provide a possible method to use when you are considering to gradually upgrade specific web applications, meaning that you actually want to have the same web application with the same hostheader available on MOSS 2007 and SP2010 and redirect your users to the correct farm depending on the site collection they target.
I have been doing some brainstorming with regards to an upcoming SharePoint 2007 to SharePoint 2010 migration for one of my customers. I have had my fair deal of upgrading from SharePoint 2003 to MOSS 2007 using the gradual upgrade approach that was built-in into MOSS 2007.
In that scenario you were able to use the URL redirection feature of MOSS. In short you could alter your DNS settings for your web application to point to your MOSS farm and then MOSS would determine if the specific site collection the user was targeting had already been upgraded and if not MOSS would redirect the user to the old SharePoint 2003 site using an alternative URL. This scenario causes a lot of confusion with your users that are accessing sites that have not been upgraded because they would start seeing your alternative url. For example: your original url was teamsites.contoso.com. Once you activated the gradual upgrade of a that specific web application, all your users would start targeting the MOSS farm and then be redirected to the alternative url which could be something like old-teamsites.contoso.com or teamsites.contoso.com:8080
In SharePoint 2010 there is still a way to use this alterantive url redirection as described in the “Using AAM URL redirection as part of the upgrade process (SharePoint Server 2010) white paper”
Now my customer asked me for a way to do it without an alternative url and simply use the same url and depending on the targeted site collection be redirected to either MOSS 2007 or SP2010. This got me thinking that it would certainly not be feasible using only DNS. The alternative url redirection feature was not an option, so I needed something that can handle such logic. This brought me to my good friend ISA server (more specifically ISA 2006)
Let me explain using a small scenario:
MOSS 2007 Farm
- Web application: teamsites.contoso.com
- site collection: /sites/siteA
- Web application: teamsites.contoso.com
- site collection: /sites/siteB
Now there is no way that you can have your users access teamsites.contoso.com/sites/siteA and teamsites.contoso.com/sites/siteB if you are just going to use a DNS entry. To which farm would you have it pointed? The user would only be able to access one of these two sites.
What if you have the DNS entry pointed to an ISA server? Could you configure ISA to analaze the incoming request and redirect the users to the correct farm? The answer is Yes !
In ISA 2006 you can create a publishing rule for publishing a SharePoint site. With a publishing rule you can accept incoming hostnames and redirect that to a specific computer or IP address. Now in addition to that you can specify the paths that a rule should respond to.
So for this solution to work you would create 2 Publishing rules :
- 1 publishing rule publishing the web application teamsites.contoso.com towards the SP2010 farm using the IP address of the SP2010 WFE or using load balancer Virtual IP address of the WFE Servers. On the Paths tab for the rule, remove the /* path and add the path /sites/siteB/* path
- 1 publishing rule publishing the web application teamsites.contoso.com towards the MOSS 2007 farm using the IP address of the MOSS 2007 WFE or using load balancer Virtual IP address of the WFE Servers. On the Paths tab for the rule, remove the /* path and add the path /sites/siteA/* path
Apply the new rules and that should do it.
With this in place you can easily plan the upgrade of all the individual site collection one by one if you want and let your users work transparently throughout your migration period with the same url they are used too.
Now I have tested this scneario and it actually does work. I also must admit that I have not tested this scenario very thoughly yet and that there mey be some catches, but hey it’s the idea that I want to pass you on