In the world of SharePoint upgrades and migrations, a number of terms are thrown around and often used interchangeably. This post outlines several key terms that will be surfaced throughout a three-part series on upgrade/migration strategies for SharePoint 2013. If you would like to jump to another post, use the links below:

  • Part 1 – Definitions (this post)
  • Part 2 – Considerations Outside of SharePoint (Coming soon)
  • Part 3 – Diving into Database Attach (Coming soon)

In past revisions of SharePoint, we had multiple ways to upgrade our farms (and the content within them) to the latest version using the tooling Microsoft provides. Over the years, Microsoft used a number of terms related to the types of upgrade available:

  • In-place upgrade – Often considered the easiest approach, but the most risky. The setup of the new system is performed on existing hardware and servers.
  • Gradual upgrade – Allows for a side-by-side installation of the old and new versions of SharePoint.
  • Database attach/migration – Allows for the installation and configuration of an entirely new environment where content is first migrated, and then upgraded to the desired state.

As SharePoint matured, the number of available upgrade options dwindled. For instance, in an upgrade from SharePoint Portal Server 2003 to Office SharePoint Server 2007, we could follow any one of the three upgrade paths noted above to reach our desired end state. In an upgrade of Office SharePoint Server 2007 to SharePoint Server 2010 we still had two paths available: the in-place upgrade and the database attach approach. For SharePoint 2013, we’re left with just the database attach approach.

Before we dive further into the database attach upgrade scenario, it’s helpful to take a step back and establish a common language as we discuss the upgrade process.

Very often, the terms upgrade and migration are used interchangeably, but they are in fact two different things. It is helpful to keep this in mind as we discuss viable upgrade approaches, as we’re often asked to perform two distinct tasks.

Data migration is the process of transferring data between storage types, formats, or computer systems.

In the context of SharePoint, a data migration refers to the transfer of our content databases (and sometimes Service Application databases) between SQL Server instances.

System migration involves moving a set of instructions or programs, from one platform to another, minimizing reengineering.

Migration of systems can also involve downtime, while the old system is replaced with a new one.

We do perform system migrations within SharePoint from time to time (i.e. application of a Service Pack or Cumulative Update), and in the case of an upgrade where our databases are attached to the updated system, any data transformations that need to occur will be executed. Also note that system migrations can (and often do) involve some form of downtime, which is acceptable, but must be accounted for in any planning and communications.

Upgrading is the process of replacing a product with a newer version of the same product. In computing and consumer electronics an upgrade is generally a replacement of hardware, software or firmware with a newer or better version, in order to bring the system up to date or to improve its characteristics.

Now we can begin to see that a SharePoint upgrade is in fact a migration (i.e. moving our content databases from one system to another) and an upgrade (the installation and configuration of a new set of hardware/software).