1. Introduction to SharePoint 2010 Upgrades
You must plan an upgrade
carefully in advance, and everyone involved with managing SharePoint
must agree on the best approach for your organization when deciding
whether you should perform an in-place upgrade to SharePoint 2010 or a
migration upgrade to SharePoint 2010. An in-place upgrade involves
upgrading your current SharePoint configuration from its existing
implementation to SharePoint 2010.
You are probably familiar
with recommendations that you should not perform an in-place upgrade to
more recent software, because you potentially can bring residual issues
or challenges from the previous version into the new version.
SharePoint is no different than any other type of software with respect
to these sorts of considerations, and it is highly recommended that you
perform a migration upgrade by installing SharePoint 2010 and then
migrating your SharePoint content and configuration settings from your
existing version to avoid problems that can be caused during an in-place
upgrade or anytime after the in-place upgrade.
Because SharePoint is often an
enterprise-wide solution, you have to be careful when performing an
upgrade to avoid or minimize any interruption of service. Most
SharePoint enterprise interruptions are caused by upgrades from previous
versions or to a more robust version (for example, upgrading from
SharePoint Foundation 2010 to SharePoint 2010). Most versions of
SharePoint are significantly different from their predecessors, which
can cause system administrators many days and nights of frustration
because of the differences and customizations between the old and the
new versions, or more likely because of a lack of planning
for and understanding of the upgrade process.
1.1. Philosophy
For those of you who are
familiar with the upgrade process from Microsoft SharePoint 2003 to
Microsoft SharePoint Server 2007, there is some good news. The upgrade
process was redesigned with the administrator in mind. Administrators
were extremely frustrated with upgrade issues in the 2003 to 2007 paths,
because they experienced poor performance as well as a lack of
documentation and appropriate tools to use during an upgrade.
SharePoint 2010 makes great
strides in improving the upgrade process in all of these areas. In order
to enhance the upgrade process, the following requirements had to be
met and actions had to be taken:
Early detection of upgrade issues
Feedback to administrator during upgrade
Incur no data loss
Keep content and current settings intact
Decrease the amount of downtime required by implementing processes that mitigate unnecessary downtime
Eliminate fatal errors and continue on when possible
Be reentrant; prevent catastrophic failures that necessitate complete restoration
1.2. How It Works
If you have a good understanding
of what comprises an upgrade, it will be easier for you to understand
how an upgrade works. In simple language, an upgrade is an ordered
sequence of steps. Each step completes an action. For an upgrade to
finish successfully, each sequential step must finish completely and
successfully.
There are two major phases in
an upgrade: the first phase occurs while running PSConfig.exe, and the
second phase occurs in a timer job. The reason the second phase occurs
in a timer job is because administrators often perform upgrades using
Remote Desktop/Terminal Server (RDP) connections, and during the
upgrade, the remote connection to the server is lost.
Figure 1
is a high-level overview of the upgrade process. In the second phase,
certain steps are highlighted to illustrate that certain service
applications and content databases are upgraded during the upgrade
process in timer jobs that do not affect the rest of the upgrade.
The upgrade process consists of a sequential series of steps that are linked together and have the following characteristics.
Each sequence of steps acts on certain objects dictated by the tasks the steps perform.
Each sequence of steps is one of the three stages of the update.
Each task can also include a series of steps.
Each successful update in the series updates the object schema.
If
a task fails, the process continues on with the next step in the
upgrade until all steps have been completed. If the upgrade needs to be
restarted, it will resume from where it last failed, avoiding the need
to start the upgrade from the beginning again.
2. SharePoint 2010 Upgrade Types
Having a thorough
understanding of what upgrade options are available can influence how
you ultimately install SharePoint 2010. There are several factors that
you need to take into consideration before deciding on how to get to
SharePoint 2010.
Current hardware architecture (32-bit or 64-bit)
Current operating system hosting your current SharePoint and Microsoft SQL Server software
Current edition and version of SharePoint
Current edition and version of SQL Server
Note:
To perform an upgrade to SharePoint 2010, you must have SharePoint Server 2007 with Service Pack 2 (SP2) installed.
2.1. SharePoint 2010 Upgrade Scenarios
After determining what
your current hardware and software SharePoint Server 2007 environment
is, you next need to determine the type of upgrade you can use to
upgrade to SharePoint 2010. There are two primary
upgrade scenarios: an in-place upgrade and a database attach upgrade.
However, there are also two variations of these primary upgrade
approaches.
Table 1 contains compares these four different upgrade options.
Note:
The gradual upgrade, in which
you run two sets of SharePoint binaries installed side by side, is no
longer supported for SharePoint 2010.
Table 1. SharePoint 2010 Upgrade Options
| UPGRADE TYPE | PROS | CONS |
|---|
| In-place
upgrade
You have the ability to install SharePoint 2010 on the same hardware as
the current version of SharePoint. You can also upgrade the content and
settings in the server farm as part of a single process. | Farm-wide
settings are preserved and upgraded. Customizations are available in
the environment after the upgrade, although manual steps may be required
to upgrade or rework them. | Servers
and farms are offline while the upgrade is in progress. The upgrade
proceeds continuously. Consequently, you must allocate enough time for
all content to be upgraded in sequence. |
| Database
attach upgrade
You can upgrade the content for the environment on a separate farm. The
result is that you do not upgrade any of the services or farm settings.
You can upgrade the databases in any order and upgrade several databases
at the same time. | You
can upgrade multiple content databases at the same time, which results
in faster upgrade times overall than an in-place upgrade. You can use a
database attach upgrade to combine multiple farms into one farm. | The
server and farm settings are not upgraded. You must manually transfer
settings that you want to preserve from the old farm to the new farm.
Any customizations must also be transferred to the new farm manually.
Any missing customizations may cause unintended losses of functionality
or user experience issues. Copying databases over a network takes time
and bandwidth. You must plan for that. You need direct access to the
database servers. |
| Hybrid
approach 1: Read-only databases
You can continue to provide read-only access to content during the
upgrade process. For this approach, you set the databases to read-only
while the upgrade is in progress on another farm. | The
existing farm can continue to host non-upgraded sites (in read-only
mode) while you upgrade the content. As a result, there is minimal
downtime for users.
You can upgrade multiple
content databases at the same time, which results in faster upgrade
times overall than an in-place upgrade.
You can upgrade hardware in addition to software. | The
server and farm settings are not upgraded. You must manually transfer
settings that you want to preserve from the old farm to the new farm.
Any customizations must also be
transferred and upgraded manually. Any missing customizations may cause
unintended losses of functionality or user experience issues.
Copying databases over a network takes time and bandwidth. You must plan for that.
You need direct access to the database servers. |
| Hybrid
approach 2: Detach databases
You can take advantage of an in-place upgrade’s ability to upgrade
content and settings while adding the speed of a database attach
upgrade. For this approach, you use an in-place upgrade to upgrade the
farm and settings and to detach and upgrade multiple databases in
parallel (on the same farm or a separate farm). | Farm-wide settings can be preserved and upgraded.
Customizations are available
in the environment after the upgrade, although manual steps may be
required to upgrade or rework them.
You can upgrade multiple content databases at the same time, which
results in faster upgrade times overall than an in-place upgrade. | Copying databases over a network takes time and bandwidth. You must plan for that.
You need direct access to the database servers. |
Note:
When using an in-place
upgrade approach, you are performing an actual upgrade of your existing
environment to SharePoint 2010. Conversely, performing a database attach
upgrade is more of a migration upgrade and is considered a safer
upgrade option.
2.2. Special Cases
In addition to the
previously discussed common SharePoint 2010 upgrade approaches, there
are five special case upgrades that you can choose to perform as well.
These special case upgrades listed in Table 2
are helpful if you determine that none of the four common upgrade
approaches will work or will be an efficient approach for your
organization’s upgrade to SharePoint 2010.
Table 2. SharePoint 2010 Special Case Upgrades
| SPECIAL CASE TYPE | UPGRADE APPROACH |
|---|
| Upgrading from a 32-bit to a 64-bit edition of SQL Server | If
you need to upgrade from a 32-bit to a 64-bit edition of SQL Server,
you should perform that upgrade before you upgrade to SharePoint 2010 to
ensure the best performance benefits. Ensure that you perform only one
upgrade at a time to avoid upgrade failure. For more information, see
“Migrate an Existing Server Farm to a 64-Bit Environment (Office
SharePoint Server 2007)” located at http://technet.microsoft.com/en-us/library/dd622865.aspx.
The following are two options for upgrading from a 32-bit to a 64-bit edition of SQL Server.
You can back up
all the databases for the farm, perform the upgrade, and then restore
the databases. (This option is supported and recommended because you
will have a full backup, and after you restore the databases, you do not
have to change anything within SharePoint 2010). You
can move the SQL Server databases that you want to upgrade to a
different 64-bit edition of SQL Server. You must add the different
64-bit edition and then run a command to the computers running
SharePoint 2010 to point them to the new 64-bit edition of SQL Server.
(This option is supported but not recommended because it requires more
work in SharePoint 2010 when, for example, the databases change
location).
|
| Upgrading from a 32-bit operating system to a 64-bit operating system | If
you are using a 32-bit operating system, you must migrate to a 64-bit
operating system before you upgrade. For more information, see “Migrate
an Existing Server Farm to a 64-Bit Environment (Office SharePoint
Server 2007)” located at http://technet.microsoft.com/en-us/library/dd622865.aspx. |
| Upgrading from Microsoft SharePoint Portal Server 2003 | Upgrade
to Office SharePoint Server 2007 and then upgrade to SharePoint 2010.
For more information about how to migrate from SharePoint Portal Server
2003 to Office SharePoint Server 2007, see the Migration and Upgrade
Resource Center for Office SharePoint Server 2007 at http://go.microsoft.com/fwlink/?LinkID=104403. |
| Upgrading from Windows SharePoint Services 3.0 | Use
the database attach upgrade method to upgrade the content databases
from Windows SharePoint Services 3.0 to SharePoint 2010. This process
upgrades the data in the content databases but does not transfer any
farm settings. |
| User-Copy-Only | This
method is used when you want to retain all of your current information
in SharePoint Server 2007, but you want to implement a new information
architecture (IA). You build your new SharePoint 2010 farm and then
export the content out of the SharePoint Server 2007 farm and import it
into the SharePoint 2010 farm in the new IA design. |
As you can see, there are
several types of upgrades you can perform and several items you must
consider before beginning an upgrade to SharePoint 2010. It is important
to take the time to familiarize yourself with all components of your
existing SharePoint implementation to ensure you have a successful
upgrade to SharePoint 2010.
2.3. SharePoint 2010 Upgrade Paths
Now that you are familiar
with the upgrade types, you need to also become familiar with the
upgrade paths available when upgrading to SharePoint 2010. Understanding
the supported
upgrade paths will help you make a well-informed decision on how to
perform the upgrade to SharePoint 2010. You’ll first need to determine
if an upgrade to SharePoint 2010 from your current implementation is
even possible.
2.3.1. Supported Upgraded Topologies
The first thing you need to
do is analyze and document your current SharePoint configuration and all
of its supporting components to determine if it will be possible for
you to perform an upgrade to SharePoint 2010. There are several
considerations that you must be familiar with when determining if you
are going to upgrade to SharePoint 2010.
When you upgrade to SharePoint
2010, you must upgrade to the same kind of installation. For instance,
you can only upgrade your current stand-alone SharePoint installation to
a SharePoint 2010 stand-alone installation, or upgrade your current
server farm to a SharePoint 2010 server farm. During an upgrade, you
cannot upgrade from a stand-alone installation to a farm installation or
vice versa using an in-place upgrade. However, that doesn’t mean you
are committed to staying with the current type of installation; it just
means you must change the size and scale of a server farm to suit your
requirements either before or after you upgrade to SharePoint 2010.
Alternatively, if you perform a database attach upgrade, you are able to
attach your databases to a different installation type.
This means that
migrating from a stand-alone server to a SharePoint 2010 farm
configuration is a two-step upgrade. In step 1, you will create a new
farm using your current version of SharePoint and move the databases
from the stand-alone server to your newly created farm. Step 2 is then
to perform the upgrade of your current version server farm to a
SharePoint 2010 farm.
You also must follow this two-step upgrade
if your current version of SharePoint is running on 32-bit hardware. In
this case, you cannot perform an in-place upgrade to SharePoint 2010.
You must perform a migration upgrade by first obtaining 64-bit hardware
and then installing SharePoint 2010; the final step in a migration
upgrade is migrating your content from SharePoint Server 2007 to your
new SharePoint 2010 farm.
2.3.2. Upgrade Restrictions
Most Microsoft Office SharePoint Server 2007 installations can be upgraded to SharePoint 2010, but there are some restrictions. Table 3
lists the SharePoint Server 2007 and SharePoint 2010 server editions
that can be upgraded to specific SharePoint 2010 editions using an
in-place upgrade, and it lists those in-place upgrades that are not supported.
Table 3. SharePoint In-Place Upgrades to SharePoint 2010
| CURRENT EDITION | NEW EDITION (SUPPORTED IN-PLACE UPGRADE) |
|---|
| Office SharePoint Server 2007 with SP2, Standard Edition | SharePoint 2010, Standard Edition |
| SharePoint 2010, Standard Edition | SharePoint 2010, Enterprise Edition |
| Office SharePoint Server 2007 with SP2, Enterprise Edition | SharePoint 2010, Enterprise Edition |
| Office SharePoint Server 2007 with SP2, Trial Edition | SharePoint 2010, Trial Edition |
| SharePoint 2010, Trial Edition | SharePoint 2010, full product |
The in-place upgrades listed in Table 3
are the simplest forms of upgrades that you will encounter when
performing most upgrades to SharePoint 2010. However, there are
cross-product upgrade scenarios that you may also encounter, and you
should be familiar with these in case you have to perform some of the
less common types of upgrades. Table 4 lists both the supported and unsupported SharePoint upgrade options that you also could encounter.
Table 4. Cross-Product In-Place Upgrades to SharePoint 2010
| CURRENT EDITION | NEW EDITION (SUPPORTED) |
|---|
| Windows SharePoint Services (WSS) 3.0 with SP2 | SharePoint Foundation 2010 |
| Microsoft SharePoint Foundation 2010 | SharePoint 2010 |
| Microsoft Search Server 2008 | SharePoint 2010 or Microsoft Search Server 2010 |
| Microsoft Forms Server 2007 | SharePoint 2010 |
| Microsoft PerformancePoint Server 2007 | SharePoint 2010 |
| Microsoft Project Server 2007 with WSS 3.0 with SP2, or SharePoint Server 2007 with SP2 | SharePoint 2010 Enterprise Edition plus Microsoft Project 2010 |
As you can see, there are
several options to choose from when deciding whether you will need to
use a two-step approach for an upgrade, or whether the upgrade you are
considering is simple enough to perform in one step to move from your
current version of SharePoint to SharePoint 2010.
Remember: It is strongly
recommended that you perform a migration upgrade of your existing
content to a new farm rather than upgrading your current farm because of
the possible residual negative effects.
