White Paper SharePoint 2010 Upgrade Methodology

By: Tom Castiglia & Tony Rockwell

SharePoint Upgrade Methodology

Unlike many software applications, SharePoint is not a product, but rather a sophisticated platform for building and hosting a variety of different business applications. This makes SharePoint a powerful and flexible system that organizations rely upon as a mission-critical part of their IT infrastructure. It also makes the process of upgrading an existing MOSS or WSS farm to SharePoint 2010 more complex than most applications or other server products from Microsoft.

Purpose
The purpose of this document is to explain the necessity and value of careful planning and testing before upgrading a MOSS 2007 or WSS 3.0 farm to SharePoint 2010. The information gathered during the planning and testing stage will help assess the overall time, complexity and costs associated with performing the upgrade.

SharePoint Upgrade Planning Checklist

The following checklist will help with the upgrade planning and testing process: Document Farm and Setup accounts & passwords Document farm architecture & components (include server names & IP address) o SharePoint Web Front End servers (Qty & services running on each) o SharePoint Application servers (Qty & services running on each) o SharePoint Index servers (Qty & services running on each) o SharePoint Database servers (Qty & services running on each) o Identify server details (for each server listed above) OS & version CPU (32-bit/64-bit) RAM Identify the IIS version and any special settings Identify the .NET version Local disks or SAN Define any Extranet or External sites or connections List all solutions installed (free, 3rd party, or Microsoft provided but not default OOTB) List all custom features or web parts (not installed as solutions) List any customizations including custom applications or integration with other systems Identify any custom branding, themes or style sheets If Reporting Services is being used, list # of reports & details of report servers Capture configuration details of SSPs Page 1 of 8 October 17, 2011

White Paper SharePoint 2010 Upgrade Methodology

By: Tom Castiglia & Tony Rockwell

List each SharePoint Web Application & port used List all SharePoint Site Collections Document Content Databases list each by name & include size List any libraries or lists using custom forms o Identify any InfoPath forms in use List any Business Data Catalog usage or connections to external data Identify system criticality, down-time restrictions, and business expectations Identify key contacts for system/network access, dba, business and project leads List all Workflows custom, SPD, 3rd party, and standard SharePoint workflows Indicate the number of audiences and how they are being used.

Extensibility and Customization

A typical production MOSS 2007 or WSS 3.0 farm contains many customized features and solutions, such as branding elements (master pages, page layouts, themes and CSS), web parts, workflow, site definitions, web pages, etc. These customizations are generally developed using SharePoint Designer and/or Visual Studio and are provided by developers from internal IT staff, outside consultants and 3rd party components that are purchased off-the-shelf. The extensibility framework and large ecosystem for custom and 3rd party solutions is what makes SharePoint such a powerful tool. Most customizations will work properly in SharePoint 2010; however, some may not be as simple.

Inventory all customizations

In the early planning stages of a SharePoint 2010 upgrade, it is important to inventory all customizations. There are three main sources of customizations to look out for: 1. 3rd party components 2. Customizations created by the IT staff 3. Customizations created by an outside consultant For proper customizations that were deployed as a Solution, some of this information is readily available in SharePoints Central Admin, under Operations>Solution Management (see figure 1 below). This screen will display a list of all deployed solutions including which web application(s) they are deployed to. This information can be used to start your inventory of customizations; however, additional information about each solution is necessary for planning purposes: Is the solution actually being used? What type of customization does the solution contain? What is the installation procedure for the solution? Page 2 of 8 October 17, 2011

White Paper SharePoint 2010 Upgrade Methodology

By: Tom Castiglia & Tony Rockwell

Who created the solution (and who supports it)? How to regression test the solution.

Typically, research is needed by a SharePoint administrator to properly document this information. The SharePoint administrator may find only a small percentage of the many solutions deployed are actually in use. Removing solutions that are not being used, will simplify the upgrade process dramatically.

In addition to the properly deployed solutions, many production SharePoint servers have various ad-hoc customizations created in SharePoint Designer and in some cases unofficial (rogue) web parts or other modules that were deployed without using SharePoints solution framework. While these customizations are more difficult to track down, it is important to identify all customizations for inclusion in the inventory. The completed inventory of customizations will help determine the overall complexity of the pending upgrade.

Create a SharePoint Test Farm

Due to the extensive level of customizations found in most production SharePoint farms, it is highly recommended that all organizations maintain a SharePoint test farm that mimics the production farm as close as reasonably possible. A test environment is needed to accurately test the deployment of services packs and cumulative updates on your MOSS or WSS farm as well as for planning an upgrade to SharePoint 2010. Page 3 of 8 October 17, 2011

White Paper SharePoint 2010 Upgrade Methodology

By: Tom Castiglia & Tony Rockwell

The test farm should be running the same version of SharePoint and use the same versions of Windows OS and SQL Server as the production environment. However, it is not critical to match the number of servers in your production farm. For example, if a SharePoint farm contains multiple web front end (WFE) servers, it is typically fine to create a test farm with only one WFE server. In some cases, a test farm can be staged on a single server combining multiple roles (WFE, SQL, APP). The most common

scenario is to have a two-server test farm, with one web front end and one database server running, SQL Server 2008 R2. When planning an upgrade from SharePoint 2007 to 2010, if a test farm does not exist, the first step is to plan a test farm. The specific requirements for each test farm will vary depending on the project budget, the complexity of the production SharePoint farm and the type of upgrade that is planned (InPlace vs. Database attach). In addition to the inventory of customizations, the level of complexity to create a test environment will depend on numerous factors, including: 1. Number of web applications, site collections and content databases 2. Size of content databases 3. Number of SSPs 4. SSP Content (Audiences, Search rules, Profile mappings and MySites) Tip: Using a virtual server (VMWare or Hyper-V) is highly recommended for staging a SharePoint test environment. This reduces hardware acquisition costs and provides the ability to create snapshots of the test environment throughout the testing process. Should the testing process encounter a problem, the server can be restored to a previous, known-good snapshot.

Pre-Upgrade Checker
With the release of Service Pack 2 for MOSS and WSS, SharePoint includes a specific utility called the Pre-Upgrade Checker (technically, this utility is simply a new command available in STSADM). The Pre-Upgrade Checker will compile a detailed report about the readiness of the SharePoint system to be upgraded. If your existing SharePoint 2007 farm has SP2 installed, your administrator can run the Pre-Upgrade Checker command at any time to identify any major issues with the current configuration. The Pre-Upgrade Checker reports on data that is global to the entire farm as well as unique to the current server, so this command should be run on every WFE or APP server in your SharePoint farm.

Page 4 of 8

October 17, 2011

White Paper SharePoint 2010 Upgrade Methodology

By: Tom Castiglia & Tony Rockwell

The report produced by the Pre-Upgrade Checker identifies major show stopping issues that will prevent the upgrade outright along with warnings of potential issues that may or may not be serious, depending on any number of factors. Note: The purpose of the Pre-Upgrade Checker is not to determine that your MOSS or WSS farm is completely ready for an upgrade, but only that it is ready for detailed upgrade testing.

Preparing for the Pre-Upgrade Checker

Because the Pre-Upgrade Checker requires SP2, many organizations will need to first install this service pack before they can run this tool on their production SharePoint server. Optionally, it is suggested to also install the October 2010 Cumulative Update at this time as well. Although SP2 and the October 2010 CU are very reliable, it is suggested to deploy these updates in a test environment first and then regression test the system to verify that the SP2 did not break or change existing functionality. Once regression testing is complete, the same updates can be deployed to the production farm, enabling you to actually run the Pre-Upgrade Checker.

Limitations of the Pre-Upgrade Checker

The Pre-Upgrade Checker however, may not catch every possible pitfall related to the upgrade. For example, the Pre-Upgrade Checker cannot validate that every custom web part, workflow or other custom solutions will behave the same way in SharePoint 2010 as it does in MOSS or WSS. Hence the need for a test farm, where the upgrade process itself can be tested and any customizations can be methodically regression tested after the upgrade installation is complete.

Resolving Errors and Warnings from the Pre-Upgrade Checker

In a perfect world, the Pre-Upgrade Checker will not report any errors in your production farm. However, in most cases, at least a few errors are reported that must be addressed before upgrade testing can begin. In many cases, the reported errors will have straight-forward solutions and can be resolved quickly. But that may not always be the case. Common Errors reported by the Pre-Upgrade Checker include:

Unsupported customizations (only those that will prevent the upgrade from completing) Orphaned Objects Invalid Configuration Settings Unsupported Database requirements Unsupported Hardware/operating system October 17, 2011

Page 5 of 8

White Paper SharePoint 2010 Upgrade Methodology

By: Tom Castiglia & Tony Rockwell

As each error or warning is resolved, you should re-run the Pre-Upgrade Checker to confirm that the problem is no longer reported. You can run this command as many times as needed. Depending on which upgrade approach you plan to use, some of the reported errors may not be relevant. In some cases, you may use the results of the Pre-Upgrade Checker to determine which upgrade approach to utilize.

Visual Upgrade
With the introduction of the Ribbon Bar, SharePoint 2010 introduces a major change in the fundamental user interface design compared to MOSS and WSS. As a result, most custom branding elements from

SharePoint 2007, such as master pages, page layouts and CSS will not work as expected in SharePoint 2010. The good news is that SharePoint 2010 provides an option called Visual Upgrade, which allows web site owners to choose between two options: 1. Switch to the new SharePoint 2010 user interface 2. Retain the look and feel from SharePoint 2007 The Visual Upgrade option can be enabled for each Site Collection. When enabled, site owners can choose either option for each site and SharePoint 2010 allows them to test the look and feel of the site under both options and then choose whichever one is preferred.

Retain the look and feel from SharePoint 2007

This will enable custom branding elements to continue to work as they did in MOSS or WSS. The benefit of this approach is that no functionality available in SharePoint 2007 is lost. The downside is that some SharePoint 2010 functionality will not be available in this mode (such as, the ribbon UI, in-place editing for Wiki pages, interactive calendars, and list relationships). Therefore, this option is intended only as a short term solution until the branding is updated or replaced with branding that is compatible with SharePoint 2010 and this can be assessed during the overall testing process.

Switch to the new SharePoint 2010 user interface

If the MOSS or WSS system has little or no custom branding, the Visual Upgrade option will not be used, or if it is used then the new SharePoint 2010 UI will be selected soon after the upgrade.

Page 6 of 8

October 17, 2011

White Paper SharePoint 2010 Upgrade Methodology

By: Tom Castiglia & Tony Rockwell

Additionally, sites with custom branding can still be briefly tested in this mode, and if the results are acceptable then the new UI can be enabled permanently without any changes to the branding.

Select the Right Upgrade Approach

SharePoint 2010 supports two upgrade approaches: In-Place and Database Attach

In-Place
The In-Place approach is used when you want to upgrade the existing SharePoint servers to SharePoint 2010. This approach is only valid if the hardware and operating system meet SharePoint 2010s minimum requirements (64-bit, typically with Windows 2008 R2). With the In-Place upgrade, the SharePoint 2010 installation is run on each WFE and APP server in the farm. The installer detects that MOSS or WSS is previously installed and presents the user with the appropriate options to upgrade.

This approach absolutely requires a greater level of up front planning and testing, because if the upgrade process does not go smoothly the production server could be unavailable for an extended period of time. However, once thorough planning and testing is complete, the In-Place upgrade is the easier of two upgrade options. For the In-Place upgrade, the test environment is used to stage a replica of the production MOSS or WSS farm, with Service Pack 2 and the October 2010 CU is installed. After resolving any issues reported by the Pre-Upgrade Checker, an actual test of the In-Place upgrade can proceed on the test server. The purpose of this test process is as follows: 1. Verify that the core upgrade completed successfully 2. Verify that the content databases upgraded successfully 3. Test the Visual Upgrade 4. Regression test the upgraded SharePoint 2010 environment to identify any components that do not function as expected.

Database Attach
The Database attach option is used when you need to install SharePoint 2010 on a new server(s) that do not already have MOSS or WSS installed. In this scenario, a new SharePoint 2010 farm is created with clean installation of SharePoint 2010 on at least one WFE server. Once the new SharePoint 2010 farm is created and the existing SharePoint 2007 system has been updated with SP2, any custom solutions that need to be used in SharePoint 2010 should then be installed.

Page 7 of 8

October 17, 2011

White Paper SharePoint 2010 Upgrade Methodology

By: Tom Castiglia & Tony Rockwell

At this point, the existing content databases can be backed up from the production SQL Server and restored to the test SQL Server. After the content database(s) are restored to the test database server, they can be attached to the SharePoint 2010 farm one at a time. When each content database is attached, it will be automatically upgraded to be compatible with SharePoint 2010. If the SharePoint 2007 farm makes use of SSPs, Audiences and/or MySites, the SSP database(s) can also be backed up, restored and upgraded to SharePoint 2010. The actual upgrade process for the Database Attach option contains a few additional steps compared to the In-Place upgrade. Compared to the In-Place upgrade, the benefits of this approach are: 1. The ability to leave the production MOSS or WSS farm operational (in read-only mode) during the upgrade process. 2. Lower risk because you can resume use of the MOSS or WSS farm should the SharePoint 2010 upgrade not work as expected. With the Database Attach approach, you should expect to test a complete upgrade at least one time and then assess the results: 1. Verify that the content databases upgraded successfully 2. Test Visual Upgrade 3. Regression test the upgraded SharePoint 2010 environment to identify any components that do not function as expected. With the Database Attach approach, often the test farm will become the production farm once the upgrade process is complete. In this case, there is no difference between the testing process and the upgrade process if the upgrade test process works perfectly the first time, then the upgrade may be considered complete. In reality, there are likely to be some issues uncovered during the testing process that will need to be remediated and re-tested in order to complete the Database Attach upgrade process. With careful analysis and regression testing, this process should only be repeated once. But the benefit of the Database Attach option is that the process can be repeated as many times as necessary.

Page 8 of 8

October 17, 2011