SharePoint Tip of the Month

Planning For Your Upgrade to SharePoint 2010

With SharePoint 2010 in beta, Abel Solutions has started looking at moving its own SharePoint sites to 2010. In the course of our planning, we’ve had an opportunity to learn a great deal about the process. What we’ve found is that there are more similarities to the 2003-to-2007 upgrade than there are differences.

Upgrade Approaches

Much like the 2003-to-2007 process, there are three high-level approaches that companies can take – the in-place upgrade, the content database upgrade, or content migration. Each is described below.

In-place Upgrade

With an in-place upgrade, you install SharePoint 2010 on an existing SharePoint 2007 farm. The benefit to this approach is that there is no moving of large database files back and forth. The main downsides of this approach are 1) the inability to revert back after the upgrade takes place, and 2) the SharePoint farm is completely unavailable during the upgrade process.

Content Database Upgrade

With a content database upgrade, a SharePoint 2007 content database is moved to a SharePoint 2010 farm and added to a SharePoint 2010 web application via the STSADM command. When upgrading via the content database attachment, the database itself is unavailable – or at least in read-only mode – during the upgrade period. However, other databases on the 2007 farm are available. Additionally, by upgrading content databases, administrators can test the upgrade, verify the results, and rollback if necessary, prior to committing any changes. Another factor is that with creative management of sites and content databases, individual sites can be upgraded on a case-by-case basis.

Migration

The last approach to moving to SharePoint 2010 is migration. Migration differs from an upgrade in that individual pieces of content are physically moved from a SharePoint 2007 (or earlier) farm to a SharePoint 2010 farm. As the saying goes, “Garbage In, Garbage Out.” Many companies, including Abel Solutions, have tools available to assisting with a migration effort. Migration may be appropriate if any of the following scenarios apply:

• When the content of a SharePoint site or entire farm is generally outdated and due for an update.
• Where the SharePoint taxonomy is due for a major overhaul. Sites with deep folder structures in the document libraries, for example, with little or no use of SharePoint metadata, or no custom-defined content types should strongly consider migration to SharePoint 2010 rather than an upgrade.
• When users, in general, express that content is difficult to locate, or that the search function provides limited added value, these are other good indications that a fresh taxonomy – and subsequent content migration – would be appropriate.

Challenges

Companies that upgraded from SharePoint 2003 to 2007 may recall some of the hurdles or considerations with upgrades. Many of the same rules apply, so we didn’t encounter too many surprises with our own upgrade. In short, anything that is custom presents a potential challenge for the upgrade process. Some customizations are more likely than others to cause issues:

• Graphic design – Graphic design customizations from 2007 can include master pages, page layouts, alterations to individual pages (through SharePoint Designer), and custom style sheets. Since the new platform introduces several new user interface components, any sites that use customized graphics will not pick up the new UI elements. While customized pages will upgrade, they will either look unusual or will simply not look like there is anything new. With rare exceptions, customizations to the graphic design should be considered obsolete when going to 2010.
• Web parts – For the most part, web parts that are coded against the SharePoint API will likely upgrade without a problem. A few classes and methods have been deprecated from the object model and are worth reviewing. Uses of these methods will be the exceptions to this rule. All web parts are still worth testing, however, to verify that they continue to work as advertised.
• Third-party solutions – Whether or not solutions purchased from other vendors will work depend entirely on the vendor. Contact your providers and inquire about 2010 compatibility for any purchased products.

Other Considerations

Ultimately, whether and when to upgrade/migrate will come down to a number of considerations. In addition to the things discussed above, credence should be given to the following factors:

• Hardware availability – SharePoint 2010 will require substantially more powerful server hardware than 2007. Most notably, Windows Server 2008 and 64-bit servers are key requirements that many 2007 farms lack.
• Training – With a new user interface, 2010 will require a training plan for users. The biggest UI change is incorporation of the ribbon, which will be new to users of Office 2003, but less of a transition for users of the Office 2007 client.
• Down-time – Which upgrade path to take will depend on the amount of total down-time that is acceptable for users of individual sites (or of the entire SharePoint farm).
• URL consistency – By migrating individual sites, or individual content databases, transitioned sites will need to change, while those that are left on the 2007 farm will remain constant.