The IT Leader's Guide to Multicloud Readiness
This guide provides practical key insights and important factors to consider to make informed decisions in your multicloud journey.
Upgrading SharePoint 2007, MOSS or WSS, can be quite a daunting task. With the extreme flexibility for customizations in SharePoint, there are many different areas that need to be analyzed and prepared for, prior to any successful upgrade project. There are 2 basic upgrade approaches – in place and database attach. It has been our experience at Perficient that most clients will require a database attach process, so for our conversation we’ll focus on that method. Also, this is not a step by step process post, there are plenty of those out there; these are recommendations, tips, and tricks gathered by experience. Ok, so let’s dive in and look at some key areas.
SharePoint farm architectures can vary from small to enterprise, from 1 tier to 3 tiers, and from one server to hundreds of servers. Prior to most upgrade projects, the organization has already determined their new farm architecture or has some idea of the changes they would like to make. At Perficient, we have found that many clients got started with a small farm in SharePoint 2007 and they have successfully grown their implementations, which now require a medium or large farm.
The first step in a successful upgrade project is to analyze the existing farm: identify all servers, server roles, services installed, and current versions. Next, ensure that the future architecture is fully planned and begin implementing the environment. We won’t dive into a design consideration discussion in this post, but planning for SharePoint and the new Service Application architecture is very important: Search, My Sites, User Profiles, and Managed Metadata are all important considerations. architecture is also very important to your hardware team as they need to know how many servers will be in the farm and how many resources those servers will require.
Next, you need to collect and document the full contents of your SharePoint implementation. ‘Contents’ refers to many different items: content databases, farm configuration settings, farm solutions, custom branding, My Sites, Shared Service Providers, Business Data Catalog settings, and any other custom components deployed in your farm. It is important to take detailed notes of version numbers and identify any potentially large Lists or Views in your sites. Finally, find and aggregate all files, images, source code, backups, and documentation – you’ll need it later.
The pre-upgrade checker is an Stsadm operation that you run in a Microsoft Office SharePoint Server 2007 environment to find any potential issues for upgrade and to review recommendations and best practices. The operation is available with Office SharePoint Server 2007 Service Pack 2 and has been updated in the October 2009 Cumulative Update for Windows SharePoint Services 3.0 and Office SharePoint Server 2007. After running this tool, you will get a report detailing known issues that will occur during the upgrade and a ton of really good information about your farm setup, settings, and customizations. The most important area to focus your attention is the potential blocking errors. These are the errors that should be cleaned up prior to upgrading.
The most important area to focus your attention is the potential blocking errors. These will not necessarily block the upgrade from completing, rather most of these errors relate to references to items no longer in the farm. A common occurrence is where a farm solution has been removed; say a 3rd party software that you were no longer happy with and you uninstalled it. You may have unintentionally left a web part on a page that references this uninstalled software, it’s easy to do. People often create pages that get buried or pages to use for testing and forget that they are out there. For purposes of the upgrade, simply remove the reference to the web part and the error will be removed from the pre-upgrade checker report. You may run the pre-upgrade checker as many times as you like and I encourage you to do so to mark your incremental cleanup progress.
Another very important step is to run test upgrades. Setup an environment for testing and bring over a few of your content databases that are representative of your organization. Then run them through the full upgrade process. You will get a very detailed report back detailing all errors and warnings. If you were to run the upgrade process prior to doing any cleanup, you’ll notice that this report matches almost identically to the pre-upgrade checker report. However, on occasion, this report will have errors that were not found in with the pre-upgrade checker.
After you’ve identified all errors, wash, rinse, and repeat as they say. Keep doing the same process as many times as it takes you to feel comfortable that the upgrade will complete with the least number of errors. Notice I did not say error free. I have never been a part of an upgrade project that completed error free. Just because there are errors and warnings does not mean they are fatal or even noticed.
Massage the Upgraded Site
Finally, once you’ve built your new farm, installed all the farm solutions, custom components, and you’ve performed your upgrade to SharePoint 2010, massaging the upgraded site will absolutely be necessary. As noted above, rarely does an upgrade project complete without any errors or warnings. You will often times need to go through the new site and delete web parts or pages that are creating errors. Sometimes Content by Query web parts will have display errors or the styling will be funny, simply delete the old web part (make sure to take note of the settings) and add a new one configured with the same settings. Most of the time these sorts of small massaging tricks will resolve your issue. When you run into something more obscure or complex, well, that’s when the fun begins!
Hopefully this post has given you some insight into the planning and execution of upgrading SharePoint 2007 to 2010. Good luck!