Upgrading SharePoint has never been pretty or fun. Most of us have just managed to chase away the grizzly memories of when we had to upgrade to SharePoint 2007, but now we are confronted with the same situation again.

This paper will take a look at how to best plan your SharePoint upgrade, avoiding the common pitfalls. We will dissect the individual SharePoint components and how they can be upgraded.

We will also include the option of using third-party software to eliminate some of the pain points within the upgrade process. Generally, third-party software is not required, but in many cases, the ROI of employing such solutions is simply too significant to ignore.

Our recommendations are based on hands-on experience, mostly following best practices suggested by Microsoft.

What to Do First

We find that the most successful upgrade projects are those that turn the problems that come with a SharePoint upgrade into opportunities. Your SharePoint upgrade project gives your organization the chance to learn from past experience with SharePoint. Why not ask the various groups of users what they would like to get out of the upgraded SharePoint 2010?

For example, we often find that it makes sense to use the upgrade to SharePoint 2010 as a chance to review and revise the corporate taxonomy. Used correctly, the new SharePoint 2010 taxonomy capabilities can lead to tremendous improvements in how efficiently your organization creates, searches and stores information.

Taxonomy revision is only one example of the many opportunities that come with upgrading to SharePoint 2010. Further examples include enterprise search, workflows, document collaboration, Excel Services, Single Sign On, task tracking, and more.

Verify Technical Core Requirements

To upgrade your current SharePoint deployment to SharePoint 2010, the following core requirements must be met:

a) 64 Bit server hardware for SQL and SharePoint

b) Windows 2008 (64 Bit) or Windows 2008 R2 (64 Bit)

c) SharePoint 2007 SP 2 (all servers must be on the same patch level)

d) SQL Server 2008 (64 Bit) or 2005 SP3 (64 Bit)

Prepare for the Upgrade

As soon as the above technical core requirements are confirmed, it is time to plan the actual upgrade. There are generally three different upgrade paths, each of which with its own strengths and weaknesses. Whichever path is finally selected, it is essential to have a detailed understanding of how the existing system works. In other words, you need to answer the following questions:

a) Third party web parts

b) Web.config

c) Authentication

d) Solution files

e) Account information

f) Custom code

g) Server applications

h) Third-party applications

i) Custom iFilters

j) Features and site definitions

These upgrade consideration show that SharePoint upgrades are not trivial and must be planned meticulously. Most of the above information should already be included in your existing SharePoint disaster recovery plan. If this is not the case, the upgrade should be taken as an opportunity to get the SharePoint disaster recovery plan up to speed.

How to Minimize Risk and Downtime

Upgrading with SharePoint on-board tools always results in a certain amount of risk and downtime. These can be minimized by focusing on the following four areas:

a) Planning

b) Minimize database size

c) Testing

d) Server performance

SharePoint Onboard Upgrade Options

Microsoft included three general upgrade options for SharePoint. Let’s review these options with their pros and cons. Then we’ll look at how third-party applications can simplify the upgrade process.

1. In-Place Upgrade – Not Recommended
Due to its significant disadvantages, the in-place upgrade should only be used for non-mission-critical, small SharePoint deployments. Here is how it works:

a) Run SharePoint 2010 setup on all farm servers.

b) Run SharePoint 2010 Products Configuration Wizard on the Central Administration machine. This will upgrade the configuration & content databases, as well as the SharePoint services.

c) Run the configuration wizard on all other servers.

Advantages:
• Preservation of most customizations

• Preservation of farm-wide settings

Disadvantages:
• All or nothing upgrade

• Possibility of additional downtime

In short, the risk of upgrade failure and significant downtime renders the in-place upgrade non-viable for most organizations.

2. Database Attach Upgrade
Create a brand new SharePoint 2010 farm on new hardware and attach your existing content databases. Here are the main steps:

a) Apply all settings and customizations

b) Detach content database from source farm

c) Attach and upgrade content databases

Advantages
• Granular upgrade of content databases

• Parallel upgrade of content databases

Disadvantages
• Settings not preserved

• Loss of all customizations

In short, the database attach upgrade offers a lot more control than the in-place upgrade, but also requires a lot more planning. Preparing the target farm often is a demanding process that requires a lot of testing, ideally with real-life data.

3. Hybrid Upgrade Approach
To avoid the significant downtime that comes with both of the above upgrade types, Microsoft recommends the following two hybrid approaches:

Approach 1: New Hardware
This approach assumes that the SharePoint 2010 farm will be hosted on new hardware. It works as follows:

a) Apply all settings and customizations to the new farm.

b) Set content databases on the source farm to read-only.

c) Back up, restore and attach content databases to new farm.

Advantages
• Granular upgrade

• Minimal downtime

• Upgrade multiple content databases

Disadvantages
• Customizations must be manually applied

• Settings are lost

• Race against time

Approach 2: Existing Hardware
If you are running your existing farm on 64 Bit hardware, this second hybrid approach could be for you. Here’s how it works:

a) Take source farm offline.

b) Detach content databases.

c) Run in-place upgrade.

d) Re-attach content databases.

Advantages:
• Settings preserved

• Customizations mostly preserved

• Upgrade multiple content databases at the same time

Disadvantages:
• Downtime

• Risk

Why Consider Third-Party Options

The more critical SharePoint becomes to the organization, the more antiquated the above out-of-the box solutions appear. The central problem with these SharePoint on-board upgrade procedures is their impact on the existing SharePoint farm. As soon as the upgrade process starts, there will be disruptions to the users of the existing system. These disruptions often force the SharePoint team into a race against the clock. Ten years of SharePoint experience have taught us that even the most detailed planning effort does not guarantee a flawless upgrade process.

A problem that goes hand-in-hand with this issue is that when the upgrade is complete, only the actual users can tell whether it was successful or not. In many cases, the upgrade will look fine to the eye of the engineer, but the actual end-user might find missing or broken functionality. The problem here is that the end-user often does not have enough time for a thorough review, as the clock is still ticking on the upgrade process. This often leads to business users signing off too fast on their specific sites. When they then find problems, a week later, the databases between the upgraded site and the old site are already out-of-sync. This is when the SharePoint team has to burn the midnight oil.

Now wouldn’t it be great if we could give all these business users a lot more time to sign off on the upgraded system, while the existing SharePoint farm is in full operation?

This is where third-party migration tools, like Metalogix SharePoint Migration Manager, come in. Using the SharePoint API, these tools allow users to keep the databases of the old and new SharePoint farms in sync. This means that even if there are issues after business users are already on the new SharePoint 2010 farm, we can let them use the old SharePoint instance, while fixing the new farm. Once everything is working as it should, the data can be synchronized again and the 2007 or 2003 farm remains on standby for a while, until we can be sure that all aspects of the 2010 farm are fully functional.

Taking the above thought even one step further, wouldn’t it be ideal if content owners could easily migrate their own SharePoint sites? This has the added advantage of forcing the end users to review their content to ensure that it is still needed. The users also get the chance to reorganize content, instead of simply transferring everything to the new farm. This housecleaning effort often has a reviving effect on the new SharePoint implementation. Allowing end-users to gradually review and move their own content generally leads to a better SharePoint site, as the end-user knows best how she and her colleagues use the site.

Additional significant advantages of utilizing third party migration software are:
• Migrate directly from SharePoint 2003 to 2010
• Map permissions, audiences, metadata and versions
• Migrate sites that fail the Microsoft pre-upgrade check
• Gradually migrate items, lists, sites and site collections
• Re-template content
• Keep original farm intact
• Migrate to BPOS or other cloud solutions
• Automatically correct links
• Reorganize content databases

In our experience, the ROI of these migration tools is significant. Not only do these tools save staff and consulting hours, but they also take the risk, downtime and time pressure out of SharePoint migrations and upgrades. And once the upgrade is complete, migration tools are still handy for ongoing administration tasks.

Final Advice: Test, Test, Test

Assuming that something works because it is supposed to work, instead of testing with real data, often brings the SharePoint administrator into a situation that entails registering with all the major job websites. There should be testing before the actual upgrade, to confirm that all procedures will work within the specific target environment. We strongly recommend testing with real content, your production hardware, your authentication providers and all third-party software systems present. Business users should always be aware of these tests and sign off on the results.

Last Words

SharePoint upgrades are never trivial, even if everything looks simple. Proper planning, testing and involvement of business stakeholders are the three factors that are essential to the success of your upgrade project.