lessons learned in my last sps to moss migration project using gradual approach

I have been doing a fun project for a customer, which asked to have his SharePoint Portal Server 2003 farms upgraded to MOSS 2007 using the gradual upgrade approach. I wanted to share some tips and things to consider when you are facing such a project.

1. remove unused and/or previous versions of webparts fom the SharePoint configuration.

There can still be web parts registered in SharePoint that have been physically or manually removed from the virtual server. Check stsam -o enumwppacks for any webpart packages installed that are no longer registered in the web.config files and so on. Know that when you start the upgrade of the web application, MOSS will try to upgrade all registered webpart packages and that if it cannot find it anymore, the process will fail and you zill not be able to upgrade the web application until you have fixed this. 

2. check if your IIS sites have not been renamed

Another one of those things to keep in mind is the fact that when the farm is created in SPS, it writes down the name of the IIS web site in the configuration database. The MOSS upgrade will use this information to find out which IIS site corresponds to the SPS sites. If these sites have been renamed in the meantime and you want to upgrade a SPS web application, then you can get a message indicating that there is nothing to upgrade or you will also not be able to find your SPS virtual servers in the MOSS upgrade pages in Central Administration v3. If for some reason you are in a farm scenario and your IIS site name has been changed on another front end server and not on the one you are performing the upgrade, then you will not get this warning, but the MOSS upgrade will not update the IIS site with the alternat url or port that you configure and you will therefore need to make the changes manually.

3. consider adding an additional frontend server to be used as the server that performs the upgrades

When you are ready to start upgrading sites, you need to do this on a server running the Central Administration role and the Web Application role. Do not think you can get away by using your index server to do your upgrades. The moss upgrade pages go through your IIS configuration to find the web applications that can be upgraded. If you are going through the upgrade pages on a central admin site hosted on your index server and net having the web application role, you will not find any web applications and/or site collections for which you can start the upgrade. Of course having installed MOSS on top of your existing front end servers, already bring an additional load to those systems and your users will probably start complaining with performance issues. That is why I would advise havin an additional frontend server installed in your SPS farm and use this one for performing the upgrades.

4. beware of the side effects of prescan

Another thing that surprised me in the project is prescan. This required tool suppoedly does not change anything to your sites. However it does. You know when you are viewing a list of all yous Document libraries and lists in your site, that it mentions next to each list when the last modification was done in that library or list (e.g. 6 days ago). Well running prescan will reset that information. So while it does not actually change any documents or lists, it does change the last modified date of the list or library itself. Knowing this may help you when you get your users on the phone complaining that all the document libraries have been changed all of a sudden (after you have run prescan)

5. there is no stsadm command to lock/unlock a site in SPS

damn, this is a bugger. Planning to script the upgrade of each site I found out that you cannot lock a site in SPS using the commandline stsadm tool. Apparently this was only introduced in MOSS. I found the solution in SPSiteManager (see my post about it)

6. Plan your content databases in MOSS

part of my project I was asked to have tha large databases in SPS, split up in multiple databases in MOSS. I did this by using the stsadm -o mergecontentdbs operation right after the site has been upgraded. Unfortunately you cannot choose wher the upgrade porcess needs to put the upgraded site collection. Part of the preparations to your upgrade is the fact that you need to configure a 1 to 1 relation of your existing SPS content databases to your MOSS databases, meaning that if a site is located in a specific content database, that its upgraded version will end up in the configured MOSS database and nowhere else (even if there is a parameter in the stsadm -o upgrade command that allows you to specify the targetdatabasename)

A piece of good advise: If you are planning to have more content databases in a specific web application in MOSS than you have in the corresponding virtual server in SPS, create additional empty databases in SPS to match the number of content databases in MOSS. It will save you a lot of trouble if you need to revert an upgraded site and reupgrade it again.

7. Check your upgrade.log file

Every action that MOSS does which regards upgrades of web applications, upgrades of site collections and even reverts of sites is logged in the upgrade.log file. If you have chnaged the default logging location in Central Administration v3 – Operations – Diagnostics Logging, then do not expect the upgrade.log file to be there as well. This log file does not leave the nest. You need to find it in the 12-hive Logs folder. A good practice would be to clear this file before starting the upgrade of any site.

8. Know how to rollback a failed upgrade of your SPS virtual server.

I had this issue that I was finally ready to start the upgrade of the web application and that during this upgrade process the well-known “unknown error occured” appeared. When I went back to the upgrade page, I was not able to rollback this operation or redo the upgrade. So what do you do next? the answer is very simple: delete the newly created web application in MOSS and every change made to the IIS sites (URL redirection) will automatically be undone as well.

I am sure that I can add some otherpoints to this list, but nothing comes to my mind on this sunny sunday afternoon. If something does come up I will gladly add it to this post and share it with you guys.

2 thoughts on “lessons learned in my last sps to moss migration project using gradual approach

Leave a Reply

Your email address will not be published. Required fields are marked *