Before
planning for an upgrade to SharePoint 2010, you must first examine the
various supported upgrade scenarios and examine the existing environment
using tools provided by Microsoft.
Understanding Supported Upgrade Scenarios
The in-place upgrade process or
the gradual migration process has limitations to which versions of
SharePoint can be migrated, and which version of SharePoint 2010 they
can be migrated to. Table 1
indicates which versions of various SharePoint products can be upgraded
directly using the in-place upgrade process provided by Microsoft.
Table 1. Supported Direct In-Place Upgrade Targets for Various SharePoint Versions
| | SharePoint Foundation 2010 | SharePoint Server 2010 Standard Edition | SharePoint Server 2010 Enterprise Edition |
|---|
| SharePoint Team Services | | | |
| SharePoint Portal Server 2001 | | | |
| Windows SharePoint Services 2.0 | | | |
| SharePoint Portal Server 2003 | | | |
| Windows SharePoint Services 3.0 with SP2 | X | | |
| Microsoft Office SharePoint Server 2007 Standard Edition | | X | |
| Microsoft Office SharePoint Server 2007 Enterprise Edition | | | X |
| Search Server 2008 | | X | X |
| Forms Server 2007 | | X | X |
| PerformancePoint Server 2007 | | X | X |
| Project Server 2007 with WSS 3.0 SP2 or MOSS 2007 SP2 | | | X (with Project 2010) |
| SharePoint Foundation 2010 | | X | X |
| SharePoint Server 2010 Trial | | X | X |
As indicated in Table 5.1,
the older versions of SharePoint are not supported for direct upgrade
and must be first upgraded to a supported version if using the Microsoft
tools. If this is not an option, third-party tools are available from
major SharePoint manufacturers that enable direct upgrade between
versions.
Note
If the source SharePoint
2007 farm is running SQL Server Express, it can only be upgraded to the
equivalent SharePoint 2010 edition running with SQL Server 2008 Express
Edition. To get around this issue, use the database attach upgrade
process instead.
One exception to this list in
terms of the database attach upgrade process involves WSS 3.0
migrations directly to SharePoint Server editions, which are supported
on a database-by-database basis. In other words, you can take multiple
WSS 3.0 farms, pull the content databases from those farms, and migrate
their contents directly into a new SharePoint 2010 Server environment
that has been freshly built.
Assessing Site Migration Readiness with the Pre-Upgrade Check Tool
The most critical task that an
administrator needs to perform before beginning a migration is to assess
the state of the current site structure. Multiple factors can affect
how a site migrates, so they need to be taken into account and tested in
advance. Microsoft anticipated this when it created Service Pack 2 for
SharePoint 2007 because SP2 includes a pre-upgrade check utility that
enables administrators to check the readiness of their environment for
upgrade to SharePoint 2010.
This pre-upgrade check runs
as an extension to the STSADM command-line tool, included in the
\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\12\BIN folder on a SharePoint 2007 Server (either WSS or
MOSS). When an environment is completely upgraded to SP2, this tool can
be run without risk because it is read-only and makes no modifications
to any of the files on the server.
Run the pre-upgrade check by typing stsadm –o preupgradecheck, as shown in Figure 1.
The pre-upgrade check tool
runs through a battery of tests and checks your environment for
compliance with SharePoint 2010 variables. It produces a detailed
report, such as the one shown in Figure 2,
that outlines what areas of the existing farm are ready for upgrade,
and which ones are in need of remediation before they can be upgraded.
Creating a Prototype Test Environment
As previously mentioned, it
is critical to test the migration process in a lab environment. Doing
so requires the current SharePoint 2007 environment to be restored onto a
separate server, and then upgraded via either the gradual or in-place
migration options described in this article. By doing this, the actual
production environment remains untouched, and a full discovery of the
types of issues that might be experienced during the migration can be
uncovered.
It is ideal to have knowledge
workers for each site test out the migrated site on the prototype
server in advance. By giving the prototype server a different Fully
Qualified Domain Name (FQDN), both the legacy 2007 site and the migrated
2010 version can co-exist so that functionality can be validated by the
end users.
For example, if the sales department team site is normally accessed by https://sp.companyabc.com/sites/sales, the prototype sales site that has been migrated can be accessed by http://sp-pilot.companyabc.com/sites/sales. This way, if there are errors experienced during the upgrade, they can be addressed in advance of the actual move.
Ideally,
during this prototype phase, a hold would be placed on any type of
serious site modification, such as custom web parts, SharePoint designer
modification, and any types of activities that fit outside the scope of
standard SharePoint document management functionality. This would limit
the risk that a site customization made after the prototype server is
built would cause issues not seen during the actual testing process.
SQL Database Upgrade Considerations
The database technology
used by both SharePoint 2007 and SharePoint 2010 is Microsoft SQL
Server, but x64-bit versions only, and only SQL Server 2005 SP3, SQL
Server 2008, or (preferably) SQL Server 2008 R2. If the SQL database is
upgraded, there is no effect on the SharePoint environment (aside from
downtime from the migration process), and a SharePoint migration has no
effect on a SQL server.
That said, some organizations
use the opportunity afforded by a SharePoint environment to also migrate
their SharePoint databases to SQL 2008 R2, which provides for the best
set of options for SharePoint 2010, including PowerPivot functionality.
This is typically done in scenarios where new hardware is utilized for
the new 2010 environment.
