As part of your planning you planning you need to make a decision on the upgrade approach that is right for your organization and service level agreements you have with the business for solutions and applications hosted within SharePoint 2007. There will be no single upgrade approach that can be used for every organization.

Unsupported Upgrade Scenarios - There are several standard upgrade scenarios you can look into. There are few unsupported scenarios that you know immediately. First it is not possible to upgrade from any version of SharePoint earlier than WSS v3 or MOSS 2007 SP2. If you are not on those versions you first need to upgrade to that which will require you extra planning and validation to ensure those upgrades worked correctly. So if you are still on SharePoint 2003 you will need to upgrade to version 2007 first. Second, there is no side-by-side installation supported meaning you cannot run SharePoint 2010 and 2007 on the same machines. Third there is no more gradual upgrade supported anymore like there was with upgrading from SharePoint 2003 to 2007.

In Place Upgrade– First there is an In-Place upgrade which is to basically just go through the installation wizard. It is the most simple however all sites will be unavailable during the upgrade. Users can continue to use the same URLs after the upgrade is complete. You will be required to upgrade the machines SharePoint is running on from 32 to 64 bit and the previous version of SharePoint 2007 must be removed off the machine. You can be ensured that farm wide settings will be upgraded correctly and customizations to SharePoint 2007 will be brought forward if they are SharePoint 2010 compatible.

Database Attach Upgrade – Databases from SharePoint 2007 platform can be attached into SharePoint 2010. This would include content, profile service and project service databases. SharePoint 2007 configuration and search databases cannot be attached into SharePoint 2010. At a high level the process is as simple as backing up the databases, restoring on the SQL machine where SharePoint 2010 is pointing to and then run two PowerShell commands. Using this approach you can upgrade many content databases at a time and you have the ability to consolidate SharePoint farms into a single farm. However all farm settings and configurations will be lost using this approach and more importantly all customizations will have to be manually migrated. I personally do not that is such a bad thing because it will force you to do an audit of customizations in your SharePoint 2007 environments and provide you the opportunity to put in a new governance plan to control customizations from this point moving forward.

Hybrid Upgrade Approach 1 – Using the two approaches above there are some potential ways to minimize some of the cons. One approach is to create a brand new SharePoint 2010 farm and subsequently move over all customizations to that new farm. Once the customizations have been tested, make the SharePoint 2007 content databases read-only, perform a back up of the databases and restore them on the new 2010 farm. Once the new 2010 farm is tested, you can then take down the old servers and bring the new one online. The good thing about this process is that is minimizes downtime because read-only access is still available. It also provides you some time to test everything before opening it up for use. The downside is that more coordination is needed to do this, more hardware is required, and farm configurations from 2007 are not migrated.

Hybrid Upgrade Approach 2 – Another approach would to stop access your SharePoint farm and detach your content databases. Then perform an In-Place upgrade of just the service and configuration databases. Then once the In-Place upgrade is complete, then reattach your content databases into the upgrade server. The advantage of doing this is the In-Place upgrade process will perform quicker if it does not have to do the content databases at the same time. If you want to even speed it up more you could create a temporary SharePoint 2010 on the side for just upgrade content databases while the In-Place upgrade process is running on the main server. Using this approach you still have the flexibility of consolidating multiple content databases from other SharePoint 2007 farms. As well customizations do not have manually moved to a new SharePoint 2010 server. Still a down side of this is that the SharePoint farm will be down for a period of time.

I personally like Hybrid Upgrade Approach 1 because it allows for minimal downtime and you will have a new clean SharePoint 2010 farm to start from. I know will require extra re-configuration of the services and migration of customs. However there is no point bringing over a ton of stuff that may not need to be used anymore and it allows you to put in some new governance to get control of customizations that are put into SharePoint 2010 from this point on.

Minimizing Downtime

Microsoft has built several features in to the upgrade process to assist with keeping the size of your upgrades small.

Read-only Databases – Was introduced in SharePoint 2007 SP2 and during the upgrade process content databases will be marked as read-only. This will prevent any change to the content but still provide read-only access to SharePoint while the upgrade is going.

Attaching Content Databases in Parallel – The upgrade process allows you to attach multiple content databases at the same time. This can be done by using multiple Window PowerShell sessions. So you are not limited to attaching one content database at a time. Microsoft is aware that many of their customers have content databases that are very large. This is why it is important to have good SharePoint Governance plans in place to make sure you have site collections that do not get too large. SharePoint Content databases can be terabytes but when something gets that big it hard to back and restore; and in this case upgrade. If you have the ability to break apart your content databases before the upgrade, that could be a good thing to look into.

Alternate Access Mapping – There will be cases where the content databases are very large and it is not reasonable to do upgrade of the content database in a single shot. SharePoint 2010 upgrade process supports using alternate-access mapping redirections to direct traffic between the old and new SharePoint sites (reference).

Other Upgrade Considerations

Along the way there are lots of things that need to be thought about when doing a SharePoint upgrade. Here is a couple you should be thinking about right off the bat:

New Hardware Requirements - Understand the new hardware requirements need to support SharePoint 2010. For instance for production use you need to use 64-bit machines with a minimum of 8GB memory. You can use either SQL Server 2005 or 2008 but the OS must be Windows Server 2008. This could be news to your infrastructure team and need to get the new SharePoint 2010 requirements in front of them.

Install Prerequisites - There are a lot of pre-requisites that have to be installed on every machine that will be running SharePoint 2010; too many to list here. To assist with this, Microsoft has provided a Prerequisite Installer that can check each machine that SharePoint 2010 will be installed on to ensure that it is compliant.

Streamlined Installation - There are several installation wizards for SharePoint 2010 that will assist you with the installation. There is a SharePoint 2010 Preparation Tool (new) that will install all the prerequisites. Setup wizard to that installs the bits. Configuration wizard which installs configuration database, central admin and adds servers to the farm (nothing new there). Server Farm Configuration Wizard (new) which is used to configure the farm itself, site collections, service accounts, etc. You need to plan on how to use these wizards as part of your upgrade.

Forms Based Authentication (FBA) – If you are using FBA authentication you will have to do some extra planning to move it forward. You will need to convert web applications to use the new claims-based authentication model of SharePoint 2010. You will need to make modifications to the web.config of those sites and you will need to use PowerShell to migrate users and permission forward.

Shared Service Providers (SSP) – If you did not know the concept of the SSP has been removed and there is a new service architecture has been introduced for SharePoint 2010 (read my blog here). You get an understanding of that an plan on how to move forward services that were being supported in SharePoint 2007 to 2010.

Understand the Logical Architecture for 2010 – As well the logical architecture for SharePoint 2010 has changed significantly and it more flexible than the previous version (read my blog here). You have so much more flexibility in the hosting and sharing of services and this should be accounted for when migrated SharePoint 2007 features to 2010.

LinkedIn

About Me

I currently work for Office 365 as a Principle PM on the Office 365 Gov cloud team. I spent my first 7 years at Microsoft as an Office 365 technical specialist leading sales efforts with US Federal. Prior to Microsoft I worked for a Microsoft Gold partner called RDA as a Project Manager. Prior to that, I was a software engineer working with Big 4 management consulting firms. Over the past years I have done a lot of work with Office 365, SharePoint, Exchange, Skype, Silverlight, K2, BizTalk, InfoPath, ASP.net, etc. I have written a Wrox book about SharePoint BPA technologies and one of the solutions was a finalist at Microsoft Worldwide Partner of the Year conference. I am a Virginia Tech alumnus completing both my undergrad and masters in Information Technology. I play ice hockey and lacrosse on a regular basis and I am huge Washington Capitals fan.