This week, many AIS team members are attending the Microsoft SharePoint Conference in Las Vegas, Nevada. We’ll be posting blog posts from each of them as they learn what’s new and what’s exciting during sessions, demonstrations and other conference highlights.
During yesterday’s breakout sessions, I attended Sean Livingston’s session on SharePoint 2013 Upgrade. A few minutes into the presentation, Sean offered up a quip that is certainly true across any platform level migration: “Upgrades lead to unpleasant feelings between the users and the IT staff.”
To be fair, upgrades bring “new stuff,” which often the users are clamoring for. However the process of designing, engineering, implementing and provisioning the upgrade tends to be long running, particularly where large blocks of content must be migrated from one version to another. Upgrade plans must carefully balance the run times required to upgrade the content, training time for users and other background tasks against the need to keep serving up content through the transition. Migrations can be a headache from start to finish. However, several features in SharePoint 2013 aim to ease the upgrade process, if not completely avoid all headaches.
For starters, the in-place upgrade is not an option. Sounds like a retrograde? Not really. In-place options always look appealing at first glance, but considering roll-back options and the inevitable legacy of operational changes, the in-place upgrade incurred risks and thus required additional planning. The supported method for upgrading from SharePoint 2010 to SharePoint 2013 is by database attach.
When a content database is attached, SharePoint 2013 only performs a schema update to the database. From the site collection level and below, the objects remain backwards compatible to SharePoint 2010. This allows for a deferred upgrade managed on a site collection by site collection basis. So instead of an “all or nothing” content migration (or the sub-optimal backwards compatible user-interface transition) the SharePoint site appears and works just as it did in SharePoint 2010.
Well…with one exception. While pending the site collection upgrade, a new top level banner appears on the sites. This is the System Status Notification bar, and notifies site collection administrators of options to upgrade the site. In the SharePoint 2010 compatibility mode, users cannot take advantage of the new features provided with SharePoint 2013 (such as improved social networking, newsfeeds, etc.). However, the site continues to function as it did on the old farm, provided the required customizations were installed prior to the database attach.
Options to upgrade site collections include administrator run powershell scripts, but the preferred method is by way of the GUI interface accessed through site settings. Let me say it with emphasis: Microsoft intends for site collection administrators to perform the upgrade.
[pullquote]Microsoft intends for site collection administrators to perform the upgrade.[/pullquote] This is, in my opinion, the most important shift with the upgrade process. Under the older versions of the product, a difficult round of coordination hemmed in the process. In the past, migrations slowed — or even ceased — because particular site collections contained content or customizations that could not go through upgrade at a particular time. Options to split content across multiple content databases brought out more farm administration tasks. And most importantly, all the moves had to be timed with user acceptance and re-training. With the deferred upgrade, the adjudication of the upgrade is delegated at the site collection level to the very stakeholders who know best when to perform the upgrade.
Adding to the deferred site collection upgrade, SharePoint 2013 also offers site collection health checks and evaluation site collections to support the management of the upgrade. The health checks operate much in the same way as SharePoint 2010 reported issues and concerns across web applications and content databases. In this case, the site collection is assessed for upgrade. If deficiencies exist that prevent the upgrade, the site cannot be upgraded through the user interface. Evaluation site collections allow administrators to create a “test drive” version of the site collection (leveraging SQL Server snapshots or backup/restore). Both features provide site collection administrators with tools to evaluate the upgrade before clicking the “go” button.
There are several improvements on the farm administration side. But to keep this brief for now, I’ll offer thoughts on those later. Looking at the user facing side of the SharePoint 2013 upgrade process, there are good reasons to feel good about future implementations of the product. The deferred upgrade does not absolve the IT staff from planning. And certainly the IT staff cannot simply dump the actions in the lap of the site collection administrator. Rather the tools provided enable the two groups to better coordinate…or shall we say collaborate…towards the goals set within an upgrade project.
