Before entering into the process of
a SharePoint upgrade, it is important to understand what is involved. You have a
production version of SharePoint 2010, hosting data for users in your
organization, and you have plans to upgrade your SharePoint farm to
SharePoint 2013. Although Microsoft has made the upgrade process better
(over time), there is still much to consider, which is why you need to
plan.
Undoubtedly, upgrade of your SharePoint 2010
farm, which I will call the “legacy farm,” will involve some downtime
for users and at the very least impact users if the legacy farm
is read-only for the duration of upgrade. The planning process takes
into account impact on your data and users of your SharePoint farm, and
if executed correctly, planning will provide data integrity and peace
of mind that you are minimizing downtime and disruption to your users.
Note Similar
to previous upgrade versions, you can upgrade to SharePoint 2013 only
from SharePoint 2010. There exists no direct upgrade path from earlier
versions of SharePoint.
What Is New?
You might be familiar with the SharePoint
upgrade process already. Perhaps you upgraded SharePoint 2007 to
SharePoint 2010 and are now about to embark on a similar process for
upgrade to SharePoint 2013. Do not worry if you are new to SharePoint
upgrade. If you are staring at your SharePoint 2010 production farm and
wondering where to start in upgrading to SharePoint 2013.
Those of you familiar with the upgrade process
of SharePoint 2007 to SharePoint 2010 may remember the various flavors
of upgrade: in-place, database attach, and hybrid.
As the names suggest, in-place consisted of upgrading the legacy farm
by installing the new version on top of the old. Database attach
was, and remains today, the process of attaching legacy databases to a
new SharePoint farm. The hybrid approach consisted of parts of both
in-place and database attach methods to minimize downtime to users of
the legacy farm.
SharePoint 2010 to 2013 upgrade does not
support in-place upgrade. This makes a whole lot of sense because an
in-place upgrade was volatile; if something went wrong in the upgrade
process, then the legacy farm was lost! Those with virtual farms could
roll back to an earlier snapshot, prior to upgrade, but that meant
rolling back SQL and SharePoint servers, and this
was often a thankless exercise. In-place upgrade allowed organizations
with limited hardware to upgrade to the latest version of SharePoint,
whereas database attach and hybrid required additional hardware. In my
experience, most organizations took my recommendation for using the
database attach route, so that they could maintain their legacy
SharePoint farm in the event of upgrade failure.
Note Microsoft no longer supports in-place upgrade from SharePoint 2010 to 2013.
SharePoint 2013
uses a similar service architecture
to that of SharePoint 2010. This makes the process of upgrading some of
the shared service applications easier. The upgrade process now
supports database attach of some of the service applications. Table 1
shows the service applications in SharePoint 2010 that SharePoint 2013
will support as a database attach upgrade.
Table 1. Services Supporting Database Attach Upgrade
| Business Data Connectivity |
SharePoint 2013 Server and SharePoint 2013 Foundation support this service application. |
| Managed Metadata |
SharePoint 2013 Server only supports this service application. |
| PerformancePoint |
SharePoint 2013 Server only supports this service application. |
| Secure Store |
SharePoint 2013 Server only supports this service application. |
| User Profile (Profile, Social, and Sync) |
SharePoint 2013 Server only supports this service application. |
| Search Administration |
SharePoint 2013 Server only supports this service application.
SharePoint 2013 now includes what was previously called FAST—a complete
Enterprise Search Platform—thus, SharePoint 2013 only supports upgrade
of the Search Administration site. You must reconfigure your search
topology anew in SharePoint 2013. |
SharePoint 2010 required administrators to
upgrade all site collections immediately as part of an in-place upgrade
or either immediately or individually using PowerShell. SharePoint 2013
provides “deferred site collection upgrade” via site collection
settings. This allows administrators of site collections
to choose when they wish to upgrade from the legacy SharePoint 2010
user interface to the new SharePoint 2013 user interface. Because
SharePoint 2013 supports side-by-side binaries, layouts, and control
templates, administrators can continue to use the legacy look and feel
while other site collection owners in the farm use the new SharePoint
2013 interface. Both reside on the new SharePoint 2013 platform.
Additionally, site collection owners and administrators can request an
“evaluation” site collection, so they can see what their content looks
like in the new branding without losing their production site
collection. The evaluation site is essentially referencing the site
collection data from the legacy version but leveraging the new branding
and binaries to host the content in SharePoint 2013 look and feel.
Note Site
collection owners and administrators can now defer upgrade of their
site collection user interface to SharePoint 2013 look and feel.
The entire upgrade process now flows through
the Health Checker. Similar to how the Health Checker service provides
feedback to farm administrators on the health of and potential issues
with the SharePoint farm, the Health Checker provides site collection
owners and administrators with information on the health of their
upgrade process. SharePoint 2013 also includes throttling to ensure
that multiple requests for site collection owners and administrators do
not take down a server or farm.
Database Attach Process
Figure 1 shows a
high-level view of the database attach upgrade process. The process
consists of five main parts, described as follows:
- Database attach requires a working SharePoint 2013 farm, ready for you to attach legacy databases from a SharePoint 2010 farm.
- You copy databases from the legacy farm to your new SharePoint 2013
farm database server. This process typically involves using backups or
detaching the databases from the legacy farm first (which incurs
downtime).
- First, you upgrade service applications in the new SharePoint 2013
farm by attaching service application databases.
- Next, you upgrade content databases in the new SharePoint 2013 farm.
- Finally, site collection owners and administrators may decide when
to upgrade their site collections to the new user interface and
branding (this replaces the visual upgrade process in SharePoint 2010).
I detailed the process for installing and configuring a new SharePoint
2013 farm. This described process begins the upgrade process, as shown
in Figure 1.
There are some slight differences in the configuration of the new
SharePoint 2013 farm. If you are upgrading service applications
(described in Table 1),
you have no need to provision these services in the new farm. The farm
wizard normally creates new web applications and service application
databases for each desired service application, so you should not run
the configuration wizard after provisioning a new SharePoint 2013 farm
instance. Instead, you will create new application instances for each
service application and attach the legacy service database.
Minimizing Downtime
When upgrading an existing SharePoint 2010 system, minimizing downtime
and maintaining data integrity are very important. You might not
impress users of your current legacy system if the SharePoint site goes
down. Furthermore, an offline SharePoint system, used for business,
could cost your organization serious revenue if offline for a long
length of time. Fortunately, SharePoint provides capability to allow
you to maintain your legacy system online while you work on the upgrade
to SharePoint 2013 in parallel.
Setting the legacy SharePoint content and
system databases to read-only allows users continuous use of your
legacy system as a read-only resource. SharePoint 2010 is smart enough
not to throw errors when encountering read-only SQL databases, and
instead allows a read-only view of the data. This means users can
continue to read documents and information in the legacy site and
continue business as long as they do not need to write data back to
SharePoint. Read-only use of data in the legacy system also ensures
that users do not update data, which would render any copy in use for
upgrade stale.
Setting SharePoint as read-only only buys you a
small amount of time (relative to the size of your legacy system and
number of users accessing it). You might have some angry users knocking
on your door if you leave the legacy site read-only for a number of
days without providing a new system to store new content. What you need
is a fast way to upgrade content in the new SharePoint 2013 system.
SharePoint 2013 supports parallel upgrade of
service application and content databases. Since the new farm is not
yet operational, there is no real downside to pushing the resource
limits of the system with parallel upgrades, if doing so allows a
faster upgrade path. Since SharePoint 2013 also supports deferred site
collection upgrade and side-by-side customizations (with side-by-side
14 and 15 hive directories), you can roll out the new SharePoint 2013
farm as soon as you have completed content and service application
upgrades. The idea is to move users over to using the new SharePoint
2013 platform as quickly as possible, without causing discomfort to
your users with a new user interface and changes in customizations.
