There is usually more than one road to any destination, and this is true for migration paths from SharePoint 2003 to 2007. Which one you pick depends on a variety of factors, and as you go through the following sections, you'll see how each path is defined and the reasons you would choose one path over the others.
An in-place upgrade is the simplest and most straightforward upgrade migration path. It assumes that there are no complications involved in your move from SharePoint 2003 to 2007 and that you want to upgrade your entire SharePoint environment in one fell swoop. This is an "all-or-nothing" deployment scheme, which means that when the company employees all go home on Friday night, they will have just finished their work in a SharePoint Portal Server 2003 environment, and when they report to work on the following Monday morning, they'll begin their work in a Microsoft Office SharePoint Server 2007 environment.
The bright side to this option is that all your work is done, and now it's just a matter of administering the MOSS 2007 environment for your corporate users. Procedurally, performing the upgrade is as simple as inserting the MOSS 2007 media disc into the relevant servers and launching the upgrade tool. The migration process sweeps through every SharePoint site and replaces all the 2003 look-and-feel elements, web parts, and other components with 2007 counterparts, leaving your data (ideally) intact.
The dark side is that it probably will never be that simple. If something goes wrong with the migration, the scope of what goes wrong could be vast, affecting your site collection (or collections) as a whole. This could include all your content-bearing containers including libraries, lists, documents, and items. Also, even if the migration goes flawlessly, there will always be some users who either have forgotten what they were supposed to learn in the upgrade training or didn't attend specific parts of the training. In either case, the support calls will come rolling in from people seemingly baffled by the change in the interface and functionality of the new environment.
Microsoft recommends using an in-place upgrade only for small, single-server SharePoint deployments or only in a testing environment and to use the gradual upgrade path for all production environments.
Gradual upgrade migration
The gradual upgrade migration path is more complex than an in-place upgrade, but it has a number of built-in safety factors that will allow you to stair-step the upgrade process. This path requires that you install MOSS 2007 on the same system that hosts SharePoint 2003. Each platform relies upon its own content databases, so nothing is changed in each environment until you decide to institute a change. Once in place, you then can migrate one site or one group of sites at a time from 2003 to 2007, leaving the remainder of sites on the 2003 platform.
This process allows your SharePoint users to get used to the change one group at a time. For instance, let's say you migrate the sales department's site from 2003 to 2007, leaving the sites operated by all of the other departments untouched. The sales department becomes your pilot project of sorts, allowing you to determine the impact of migration for the entire corporation based on this one department. You can use this experience to work out the kinks in the process and then move on to the next site and then the next. If something goes wrong with a migration, you just need to roll back a single site rather than the entire SharePoint environment. Whatever support calls that come in will be limited to a single department rather than coming from all areas of the corporation.
The downside is that it takes a lot longer. The length of the migration time depends on how frequently you initiate migrations (one a day, one a week, and so forth), how many sites you migrate at any given point (one site, two sites, ten sites, and so forth), and the overall size of the environment. A SharePoint environment containing a single site collection consisting of 10 sites will go faster than one containing 10 site collections with each collection containing 100 sites.
In terms of the actual process involved, when content for a particular site has been called, the content database accessed will depend on whether that site has been migrated. The URL or FQDN of the site doesn't change before or after migration, but the migration process translates HTTP service requests, allowing the correct content to be accessed.
I mentioned previously that you wouldn't have to perform a database upgrade migration just because you were performing a SharePoint migration, but I also said it could be a viable option. This isn't a usual upgrade scenario, and Microsoft doesn't formally present it as a SharePoint upgrade option at all. It's considered an advanced option and one that you would utilize only if you were going to perform a hardware upgrade or upgrade your SQL Server software. In the latter case, you'd perform an in-place upgrade of the SQL Server system, say from 2000 to 2005. That said, it is unlikely that you, as a SharePoint administrator, would be asked to participate in a database upgrade migration and very unlikely that you will encounter any questions on the 70-630 exam on this subject.
Managing CMS in a SharePoint upgrade migration
This is a major area in this section of the exam objectives and rightfully so. Performing a CMS assessment prior to upgrade is required before initiating the actual migration. As you read earlier in this chapter, SharePoint 2003 works with CMS 2002 to provide services such as navigation, summary links, and scheduled deployments. These services are all integrated into MOSS 2007, so there is no need for a separate CMS deployment once the migration is done. However, there is a great need to perform an assessment (somewhat like the preupgrade scan on SharePoint 2003) to identify all the relevant information, programming, and components in the CMS application so that you can determine your upgrade migration strategy.
Microsoft published an online article called "Assessing and Analyzing Your MCMS 2002 Application for Migration" in May 2006 that describes all the details involved in performing the assessment. You can access the article at the following URL: http://msdn2.microsoft .com/en-us/library/aa480227.aspx.
The article includes an overview of the assessment process, how to install the CMS assessment tool, all the prerequisites for installing and running the tool, and how to interpret the report results. You can download the CMS assessment tool .exe file from this site: http:// www.microsoft.com/downloads/details.aspx?familyid=360d0e83-fa70-4c24bcd6-426cafbcc627&displaylang=en.
Managing business intelligence in a SharePoint upgrade migration
In SharePoint Portal Server 2003, the concept and practice of business intelligence wasn't an integrated service but was presented through a collection of onboard and third-party solutions.
For instance, SharePoint 2003 administrators who wanted to offer business intelligence features in the SharePoint environment relied heavily on Microsoft Office Web Parts and Components, also referred to as Office Web Components (OWC). OWC is a collection of web parts, web part pages, templates, and other services that interoperate with both Office 2003 and WSS 2.0 services. OWC utilizes ActiveX controls to provide chart, data source control, PivotTable, and spreadsheet services in the SharePoint environment to take advantage of the features offered by the Office 2003 suite of applications and present information in a business intelligence (BI) type of setting.
To review information about business intelligence in SharePoint 2007, see Chapter 12, "Using Excel Services and Business Intelligence," and Chapter 13, "Using Business Forms and Business Intelligence."
MOSS 2007 includes integrated BI solutions consisting of a larger variety of more evolved components, and as a result, OWC has been phased out. Although this is good news in terms of offering SharePoint users a more effective BI option, it presents difficulties when you have been using OWC functionality to provide BI presentations and now are at the threshold of an upgrade migration to SharePoint 2007 that uses an entirely different approach to BI. What happens to the customizations and particularly the data you previously configured?
There are two basic options: keep using OWC, or abandon your original BI solution and re-create it using SharePoint 2007 BI options.
Yes, OWC is no longer being supported, but you can still use the required web parts by extracting the CAB files from your 2003 installation and moving them to your 2007 platform once the upgrade is completed. These are the three required CAB files:
They are located at the following path: C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions60wppacks. Once you locate the referenced CAB files, you will need to use the stsadm.exeutility to add them to your SharePoint 2007 installation.
The following is the command syntax required:
stsadm.exe -o addwppack -filename "c:program filescommon filesmicrosoft sharedweb server extensions60wppacksmicrosoft.office.dataparts.cab" -globalinstall
You can learn more about these .cab files at the following blog: http://msmvps.com/ blogs/shane/archive/2006/09/02/How-to-manually-install-the-Office-WebParts-in-SharePoint-v3.aspx. You can find more useful information here: http:// support.microsoft.com/Default.aspx?id=929320.
Managing shared services in a SharePoint upgrade migration
The shared services architecture in SharePoint 2007 is markedly different than it was in 2003, and although these changes have allowed more flexibility and ease of use in sharing resources, the fact that the changes are so significant presents upgrade issues. Microsoft provides two viable solutions for managing the upgrade of shared services from 2003 to 2007:
- Perform a gradual upgrade with shared services by upgrading the parent portal first.
- Perform a gradual upgrade with shared services by upgrading a child portal first.
Performing a gradual upgrade of shared services by upgrading the parent portal is the recommended option. This process has five basic steps:
1. Upgrading the parent portal
2. Upgrading the personal site host
3. Upgrading MySites
4. Upgrading team sites
5. Upgrading child portals
Performing a gradual upgrade of shared services by upgrading child portals first has four basic steps:
1. Creating a new SharePoint Server 2007 environment
2. Upgrading the personal site host and personal sites in SharePoint Portal Server 2003 and attaching them to the new shared services provider
3. Upgrading team site host and team sites and attaching them to the new shared services provider
4. Upgrading child portals and attaching them to the new shared services provider
Each of the steps in these two approaches is a separate, multi-step task, and you'll have the opportunity to perform them later in the chapter. Since both of the shared services migration plans are based on performing a gradual upgrade migration, you'll learn how to perform the basics of both the in-place and gradual migration processes before addressing these more complicated solutions.
Planning a SharePoint 2003 to SharePoint 2007 migration
SharePoint 2003 to SharePoint 2007 pre-migration tasks
Determining a SharePoint Server 2007 upgrade migration plan
Download the rest of this chapter excerpt
Printed with permission from Wiley Publishing Inc. Copyright 2008. MCTS: Microsoft Office SharePoint Server 2007 Configuration Study Guide: Exam 70-630 by James Pyles. For more information about this title and other similar books, please visit http://www.wiley.com.
Dig deeper on Server Management, Monitoring Tools and Services