I have just finished a project to upgrade a client from MOSS 2007 to SharePoint Server 2010 and I want to share the process I used and the resource I found useful so it may provide a starting point to anyone else you needs to upgrade their system.
The best place I found for information was, as you would expect, the technet site for SharePoint 2010. From there you can find a whole raft of information on best practices, suggested approaches, things to consider and it really helped me formulate my approach but also justify it to the stakeholders involved in the project.
After reviewing the clients current setup one of the first things I noticed was they hadn’t installed service pack 1 or 2 so I knew this was the first thing I had to address.
From experience I know it is never advisable to install services packs directly onto live servers and this presented the first issue as there was no representative development environment which I could use to test the updates. After discussing this with some of our infrastructure team we decided to take a copy of the existing servers and place them into a virtual environment. This would then be placed in a private network thus giving me a duplicate environment that was isolated from the network.
Once I had tested the virtualised environment was up and running I then took a snapshot of the servers so I could return to the pre-service pack state at a later date. I then proceed to install both service pack 1 and 2. To help with this I found some very useful articles by Shane Young on How to install WSS and MOSS SP1 and Install Guide: SP2 for SharePoint (WSS v3 and MOSS 2007). All this was done with a recent copy of the content database in order to establish if the updates would cause any issues.
On a date agreed with the client the virtual servers were rolled back to the pre-service pack state. I then marked the live content database as read only so the client could still access the system but couldn’t update the content while the service pack updates were installed on the virtual environment. Just to ensure users could access the system but not update it I performed a series of tests trying to add items to lists and document libraries. Once I was happy with this I then backed up the SharePoint content database and copied it across to the virtual database server and restored it. At this point I encountered a variety of issues from the time it took to back up the database to the the time it took to transfer across the network. The biggest issue for me was being able to get the database back up file into the virtualised database server. As I mentioned we had set up the virtual environment in a private network which meant we couldn’t easily copy/move files onto the virtual servers. In the end the only solution was to have another server in the main network copy the database file to this then join the server to the private network.
After the service packs were installed and the site had been tested by both myself and the client the old servers were switched off and the new virtual ones added to the network.
This may seem like a lot of work but it gave me the ability to test without affecting the live system and provided some reassurance to the client as they were able to test the system before it went live.
One of the biggest lessons I learned from this was to allow time in the project plan for copying of the data from one environment to another. In this project the client’s intranet was just over 50GB and what I forgot to factor was the time it would take to back this up and copy it from the old servers to the new ones.
In my next article I will discuss the steps I followed to upgrade the site to SharePoint Server 2010 using the content DB attach upgrade method.