SharePoint Upgrades and Migrations there is no 'Silver Bullet'
This post will be of interest to most of you who are doing migrations and upgrades from WSS V2, SPS 2003 to WSS V3 and MOSS 2007. I previously talked about how to plan and get your migration strategy right the first time around. This post is an extension to that with a few real world scenarios relative to a few projects that I have been working on.
If you are in the process of planning a migration and upgrade make sure that you have identified these. I am writing this in the context of a WSS V2 to WSS V3 data migration and upgrade.
In our case we did an audit on the existing production server to determine sites and how much storage each site is using etc. Then identify which sites have been recently used and are being used. In some cases you may find that sites are not being used. This will allow the business to make a decision on the priority of the sites that require to be migrated. It is very important that the proper expectations are set by the project team to each site owner or team who’s site’s are being migrated. In this case we were doing a like for like migration in getting all content and sites moved to new infrastructure as well as the WSS V3 upgrade.
If there are any Custom Site Definitions or Custom Site Templates being used you will be able to identify these from the outset and plan accordingly on the upgrade process and method for these. Note down any managed paths being used and special configuration settings.
These guidelines are available from Microsoft for planning to upgrade custom site definitions.
Upgrade Toolkit for Windows SharePoint Services Sites and Templates Guide
In our migration we had no custom site definitions. But I recommend that this is an important document that you should read and understand in any case.
Note down the version of the WSS V2 server. With each service pack the version changes. The version for WSS V2 SP2 is 6.0.2.6568. In some cases security updates and hot fixes may change this version number. Basically depending on your opted migration method you may need to build a pre-migration server which is a close match to what your current production build is. In the server we were auditing the version was 6.0.2.8117 which had KB924881 applied as a post SP2 fix.
This environment should match the WSS V2 environment where you can easily restore backups from the production server and identify issues with individual sites. In some scenarios if a staging server exists for testing it is possible to use this. In our case we opted to do a STSADM backup from the production server then restore the sites to this pre-migration server. This allowed the business to keep on using the current server while migration and upgrade preparation was underway. It is very important to note that prior to doing STSADM backups that you lock or remove access to sites. Basically if you try to restore a site which has not being locked before running STSADM -o backup you will get an error such as:
Exception from HRESULT: 0x80040E2F
Keith Ritchie has a very good post outlining why this error occurs and what you should do on his blog.
http://blogs.msdn.com/krichie/archive/2006/07/25/678040.aspx
In our case we had to upgrade to SQL 2005 from SQL 2000. We built the holding pre-migration WSS V2 server with SQL 2005 as the back end database server. You can restore STSADM backups taken from a SQL 2000 server to a SQL 2005 database back end server.
Once you have the sites restored you will need to run prescan.exe /all on this server.
Details about PRESCAN errors are available here on Bill Baer’s blog
http://blogs.technet.com/wbaer/archive/2006/12/22/prescan-errors-what-they-mean.aspx
This is where you need to spend a bit of time planning your new environment. The time that is spent to plan and architect the production server topology in critical to the success of your migration. In a production WSS V3 install you should have a minimum of 3 or more service accounts. In our installation we used 5 service accounts for the entire server farm. These accounts are used for the following purposes.
Refer to the TechNet planning and installation guidelines before you start installing. Ideally you will build a development WSS V3 server and practice the install and document your installation for future reference. The documentation should include a deployment topology and rationale behind your decisions for opting for a particular topology. ex: Single Server vs Server Farm.
Refer to the TechNet Planning and architecture series articles and doanloadable e-books.
Planning and architecture for Windows SharePoint Services 3.0 technology.
If your SQL Server is managed by external service providers then a DB administrator will need to participate in your planning session. The following databases can be pre-created prior to your installation on the SQL Server.
Detailed information about these databases in your install are documented on TechNet.
In this step you will need to identify the best method for upgrading your sites. Basically depending on your site audit of the current server and sites you should be able to determine what method is suited best.
In any case do NOT use “In Place” upgrade. In Place upgrade works if you have a vanilla WSS V2 install and your users have no business critical use of the environment. Basically if you start a In Place upgrade your server is unavailable for the duration of the time your upgrade is running. Needless to say that if you have not prepared a DR environment then you should avoid this.
Next option is using the “Gradual” upgrade. Gradual upgrade method is best if you have to use your existing hardware. WSS V3 can be installed on the same server side by side with WSS V2. The actual migration will need to be planned very carefully to avoid service disruption to existing sites and users.
We opted to use the DB migration method as we were moving to new hardware for the new WSS V3 server. DB migration method works well if you plan accordingly and fix any PRESCAN errors you may encounter. For our migration this worked very well. At a high level these are the steps for a DB migration.
Note: That the above steps are VERY VERY High Level. In any case the migration process should be tested and practiced on a development server prior to the migration being applied and documented. The migrations we have done was done in planned releases to match the business priority of which sites were required to be migrated first. So we had to ensure minimum disruption and site downtime.
Most of all these steps were discussed and communicated with everyone in the team. Since we had a pre-migration UAT environment we were able to show and engage the site owners and users before the actual migration.
](https://www.chandima.net/Blog/Lists/Posts/Attachments/60/UpgradeX.jpg)
The above diagram illustrates how we prepared our migration environment. Theoretically you can cut out the WSS V2 pre migration server and the WSS V3 pre migration server. We included these as temporary virtual servers to ensure that we had high availability during the whole process. This also allowed us to fix and test broken and orphaned sites and troubleshoot various issues. Depending on the size of the site’s you are migrating and your complexity of the site’s you will need to carefully plan these environments. Ex: If a single site within a site collection is about 40GB in size it will take a fair amount of time to back up and restore these. So there is no real way of accurately saying that it will take XX number of hours to migrate 1 site. Based on a 10GB site we migrated it took some where between 2-3 hrs for a full STSADM backup. Then about the same to restore it. (Please note that these are indicative numbers only)
In the end the success of your migration is dependant on the planning and engagement within the organisation.
The production migration streams were planned to be done after work hours with a recovery plan and a communications plan at the ready in case of success or failure. Since we opted to do migrations in batches we were able to mitigate any adverse results carefully.
My main points to anyone planning migrations
For more resources on planning a migration please refer to TechNet:
Upgrading to Windows SharePoint Services 3.0
If you are looking at upgrading a SPS 2003 to MOSS 2007 fellow MVP Cornelius J. van Dyke has this detailed post on a Real world migration.