Many
organizations have existing SharePoint products and technologies
deployed in production environments but are interested in taking
advantage of the new features in SharePoint 2010. Many of these
organizations have significant investments in the existing
infrastructure, however, and need to ensure site functionality
throughout the upgrade process.
SharePoint 2010
includes two built-in migration options that seem deceivingly simple,
and the process itself is not actually complex. That said, the process
is limited to migrations directly from SharePoint 2007, and some
components will not migrate easily. In addition, the two Microsoft
upgrade options are drastically different in approach, so it is
important to explore the pros and cons of each option before making a
decision.
Formulating a Migration Strategy
Migration from SharePoint
2007 to SharePoint 2010 for small environments is relatively
straightforward and can be performed with minimal risk. For
organizations with a complex or large SharePoint 2007 environment,
however, migration to SharePoint 2010 can be a daunting task.
Fortunately, the migration tools built into SharePoint 2010 enable
a gradual migration approach, in which groups of sites are migrated
slowly over time, allowing for reduced risk of failure or downtime and
enabling administrators to test site functionality before finalizing
individual site migrations.
The most
difficult part of a migration subsequently becomes the validation
portion, in which an assessment of existing SharePoint 2007 site
functionality and whether it will migrate successfully is determined.
This can be even more difficult for those environments with a heavy
investment in third-party add-ons to SharePoint 2007. It is subsequently
critical to formulate a migration strategy before beginning the
process.
Note
There is no direct
supported migration path to SharePoint 2010 from the 1.0 or 2.0 versions
of SharePoint technologies, including SharePoint Portal Server 2001,
SharePoint Portal Server 2003, SharePoint Team Services, or Windows
SharePoint Services 2.0. The only way to migrate these environments to
2010 using Microsoft techniques is to first upgrade the servers and
sites to SharePoint 2007.
Microsoft provides for
two out-of-the-box upgrade options: the in-place upgrade and the
database-attach options. Each options has its particular pros and cons,
and it’s important to understand first what each migration option is
before committing to one or the other. No matter what option you choose,
it is critical to test the migration process first before beginning.
Examining the In-Place Upgrade Scenario
The first and most
straightforward option for upgrading to SharePoint 2010 is the in-place
upgrade option. With this option, an existing SharePoint 2007 server is
upgraded in place to SharePoint 2010. The advantage to this approach is
that it is easy to perform and utilizes existing hardware and preserves
custom farm settings such as Audiences or Search customization. The main
disadvantage to this approach is that the hardware must be SharePoint
2010-capable and there is no going back when the migration starts.
The key to this approach is
that the existing servers must be SharePoint 2010-compliant, which means
they must be running the following minimum levels of OS and software:
Windows Server 2008 x64 or Windows Server 2008 R2 x64.
SQL Server 2005 x64, SQL Server 2008 x64, or SQL Server 2008 R2 x64 for the database.
Service
Pack 2 for WSS 3.0 and MOSS 2007, if using those products..
Examining the Database Attach Scenario
The database attach
upgrade process works off of a completely different concept. With this
approach, you build the new SharePoint 2010 environment on completely
different hardware and configure it to best practices. You have the
option of completely rebuilding all farm aspects and can even have the
new SharePoint environment serve as a farm target for multiple source
farms of various versions (WSS, MOSS Standard, MOSS Enterprise). When
the migration is ready to take place, it is done one content database at
a time and is performed by attaching the database (or a restore of the
database) to the new farm and upgrading it on that farm.
The significant advantage to
this approach is that it is much more forgiving if there are errors, and
it allows for easy fallback to the old farm if the migration fails. In
addition, for larger and more complex environments, it allows for a
phased-migration process, rather than the need to do a “big-bang”
upgrade. The main disadvantage to this approach is that it migrates only
content and does not migrate any farm settings, such as audiences or
custom search settings.
Examining Alternative Approaches and Third-Party Migrations
Although the in-place
upgrade and database attach upgrade approaches are the only two direct
Microsoft supported migration scenarios, various other approaches can be
used, including the following:
Third-party migration tools—
These tools typically do not have limitations to what versions can be
migrated from and also allow for splicing and splitting of site
collections and content databases, something not supported in the
Microsoft approaches. They also typically handle exceptions better.
STSADM exports or backups/restores—
Although STSADM, the command-line tool, can only export or back
up/restore to the same version, it can be used to export SharePoint
content to a farm of the same version level and then run the upgrade
process on that farm. You can use this same concept with database
restores as well.
Manual content move—
Some organizations simply prefer to build a new SharePoint 2010
environment and then show their users how to move content from the old
farm to the new farm. This is particularly useful if there is a great
deal of abandoned or useless data in the older farms.
Determining which approach to use is critical during the planning phase of an upgrade or migration project.
