Upgrades and Migrations, now is the time to get it right

BusinessCommunityMicrosoftSharePointTechnology

Over the past few months, weeks, days I have been involved in planning, architecting (is that a word?) migrating and implementing various SharePoint environments for multiple organisations. These included building brand new MOSS environments and WSS V3 environments as well as some disaster recovery situations where a “few” Beta2TR installations had expired unexpectedly. Shane Young and Zac has these posts on how to upgrade to Beta2TR to RTM.

One of the most recent migrations that I carried out with my team was a migration of a medium WSS V2 farm to a new WSS V3 farm. The organisation used WSS V2 as the primary collaboration platform for teams and document management. When we were engaged by this organisation the first thing I recommended doing was to do an audit on the existing WSS V2 environment to determine the current server capacity as well as how WSS V2 has been installed.

So the next step was to go through the SQL server install and identify the content databases and make a backup. Once that was done we built a new WSS v2 environment in a virtual PC and restored the content database and created a staging area. Now we had a V2 environment to test our migration. The content DB was roughly about 20GB in size. (Yes it’s a small farm)

Our next task was to prepare our new hardware for the WSS V3 environment. For the new environment we  provided a detailed specification document and a build specification according to the requirements set out by the client. Suffice to say that we had two “grunty” servers. One for the web front end (WFE) and one as the SQL Server 2005 database.

As part of our implementation and migration we provide detailed Build and Configuration document, which consists of all the required specs for hardware and software components installed. Information about the server accounts used and why and where these accounts are used. (You need at least 5 accounts for a server farm). If your environment is not using 5 accounts then you are probably missing something. This document also include the backup and disaster recovery strategy for the new WSS V3 implementation.

Then the actual migration process can start. And as Joel points out over and over gain on his blog running prescan over the WSS V2 environment is a MUST!. Do not even attempt to migrate your sites if you are not prepared to take this step. Prescan will tell you the deepest darkest secrets about your WSS V2 sites and what needs to be fixed. This post outlines some of the information you get from prescan and how to decipher it.

Another very very useful thing is to write some PowerShell scripts. If you have still not used PowerShell then you should start right now. It will help you do some of the most tricky operations in your migration and upgrade. PowerShell + STSADM = winning combination for a successful migration. Zac is the master of PowerShell and he has this to say about using it for user account migration.

Basically if you are doing an upgrade or a migration make sure that you have the following documents at the start and end of your upgrade and migration.

  • Audit of existing sites and security

  • Implementation architecture for new installation

  • Migration plan and disaster recovery plan

  • Communications and training plan for end users

  • Detailed configuration guide

Information about how to plan and carry out your migration and upgrade is available on TechNet and Joel’s blog has very detailed posts about migrations. Or you could always ask me how (I will charge you money of course) :-)

PS: This post was created using Windows Live Writer Beta 2. It now supports WSS V3 Blogs! YEAI!

← Back to blog