Last week I wrote in “Microsoft Services and Devices: For Real” from Microsoft TechEd 2013 North America that we’ve clearly entered a brave new “versionless” world of Microsoft services. That's evidenced by the one-year upgrade cycle for Windows 8, Windows Server, Visual Studio, and SQL Server and—it doesn’t take a rocket scientist to do the math—everything else.
One of the key enablers to a “versionless” world is a smoother upgrade process, so that you can upgrade from, say, SharePoint 2010 to SharePoint 2013, or between releases of Office 365.
RELATED: Why Migrate to SharePoint 2013?
Microsoft has done a lot of laudable work in this space, which I’ll cover this week. The rest is now up to us.
SharePoint Upgrade Process Improvements
The “technical” process of upgrade has been significantly improved in the SharePoint 2010 to SharePoint 2013 upgrade story. Gone is “in-place upgrade,” which was rarely a good idea anyway. Now, you build a new SharePoint 2013 farm and attach your 2010 content and service application databases to it.
When you attach a 2010 database to a 2013 farm, the database is upgraded.
However, site collections themselves continue to function as 2010-mode site collections until a farm administrator or site collection administrator upgrades them, at which point they look, feel, act, and are 2013 site collections.
This is called deferred site collection upgrade. The process is illustrated in the following figure:
Deferred Site Collection Upgrade
Deferred site collection upgrade is very different than the visual upgrade feature of SharePoint 2007 to 2010. When you upgraded from 2007 to 2010, site collections were upgraded. But you could apply a visualization that made it look—to end users—like a 2007 site collection. Beneath the master page, though, it really was a 2010 site collection, which meant that you were forced to evaluate and remediate upgrade problems before upgrading.
SharePoint 2013’s Split Personality
SharePoint 2013 farms, however, have a split personality—they contain both the 2013 (v15) “root folder” (aka “hive”) and the 2010 (v14) “root folder.” A 2010-mode site collection in SharePoint 2013 actually is a 2010 site collection, running against the 2010 root folder, which contains all of the 2010 features, site definitions, templates, etc. SharePoint 2013 farms also support 2010 workflows and 2010 customization models, including full-trust and sandbox solutions.
Of course, you will need to install any third-party or custom features into your 2013 farm that are required by your 2010 site collections. And you’ll want to make sure those third-party customizations not only function as expected, but are supported by the vendor.
The story is significantly improved, to be sure. The architecture of upgrade enables significantly reduced or eliminated upgrade blockers. In fact, I’m not hearing “screams of pain” from customers who have begun (or completed) upgrades, as I have in all previous upgrades.
Read Up—And Document
You should of course always plan and test your upgrade, and make sure you know what you’re doing. TechNet includes a collection of resources for SharePoint upgrade that you must read before you plan for or even commit to plans for upgrade.
There will be time spent documenting settings in your 2010 farm—particularly service application configuration, and web application settings, as you will be creating those fresh in your 2013 farm.
Take this opportunity to document those settings and to create a repository of documentation to make future upgrades—and updates—smoother. Create or obtain PowerShell scripts to assist in documenting, exporting, and importing settings.
RELATED: Windows PowerShell Scripts for SharePoint: Info on Files, Pages, Web Parts
And if you expect to utilize deferred site collection upgrade—which many of you will do—read up on the nuances of service applications, including the article about upgrading the Managed Metadata service if you use content type syndication.
Knowing How, But Also Knowing Why
Now I know there are a lot of articles out there about upgrading from SharePoint 2010 to SharePoint 2013, and hopefully this will paint a broad-stroke picture of the process. My real goal, however, is to set up a discussion of why Microsoft improved the upgrade process, and what it means for us moving forward with upgrades and updates, which we’ll tackle in coming weeks.
