Set SharePoint default compatibility range after migration

SharePoint 2013 supports a great level of backward compatibility, where it allows us to run sites either in 2010 or 2013 mode. You can get more information on SharePoint 2010 and 2013 modes by referring to this article.
This feature comes in very handy for a migrated environment which has following requirements.

• Need to create new sites, but they should have SharePoint 2010 look and feel
• Site collection administrators should not be able to upgrade there sites to SharePoint 2013 until they feel it's 100% ready to do so

You may think above requirements are absurd. Why do we migrate an entire environment, and still keep the older look and feel. But they have some valid points.

• Users are not still ready for the new look and feel, and migrated environment should not cause any confusion for end users
• End user, super user, site administrator training is not complete yet.
• Policy where sites need to be upgraded gradually. (e.g.: home site upgraded first, and department site collections each week)

So how do we achieve the goal ?
We can modify the compatibility range web application property to arrive at a solution. We can use following Powershell commands to see current compatibility range

   1: $wa=Get-SPWebApplication "http://sp2013"

   2: $wa.CompatibilityRange

This provides us following information



The meaning of the above is that, if we create a site collection with default settings, the farm will create a site in SharePoint 2013 mode as the DefaultCompatibilityLevel is set to 15. Since the MinCompatibilityLevel is 14, it is possible to create sites with 2010 compatibility mode as well as 2013 mode with default settings (As shown in below image).



Apart from that, site administrators are notified that their SharePoint 2010 sites can be upgraded to SharePoint 2013 mode as the MaxCompatibilityLevel is set to 15.



Solution

We need to modify the compatibility range to suit our requirement. To do that we will execute following Powershell commands

   1: $wa=Get-SPWebApplication "http://sp2013"

   2: $range = New-Object Microsoft.SharePoint.SPCompatibilityRange(14,14)

   3: $wa.CompatibilityRange = $range

   4: $wa.Update()

   5: $wa.CompatibilityRange

The New-Object Microsoft.SharePoint.SPCompatibilityRange(14,14) instructs that both MinCompatibilityLevel and MaxCompatibilityLevel is set to 14 (SharePoint 2010 mode). So if we create new site collections, they will be in 2010 mode. (You can’t see the SharePoint 2013 option)



Furthermore site administrators are not notified about possible upgrade options.
If we need to revoke the setting later to allow SharePoint 2013 to be the default we need to execute following Powershell commands

   1: $wa=Get-SPWebApplication "http://sp2013"

   2: $range = New-Object Microsoft.SharePoint.SPCompatibilityRange(14,15)

   3: $wa.CompatibilityRange = $range

   4: $wa.Update()

   5: $wa.CompatibilityRange

In this scenario, MinCompatibilityLevel is set to 14 and MaxCompatibilityLevel is set to 15. The DefaultCompatibilityLevel is set to 15 which is as same as MaxCompatibilityLevel.

In a SharePoint migration scenario with strict policies and guidelines, CompatibilityRange property can be a lifesaver.

SharePoint 2010 mode in SharePoint 2013

If you’ve done a migration from SharePoint 2007 to SharePoint 2010, You may remember the visual upgrade features features of SharePoint 2010.

It was a cool feature. If the environment is still not ready for the drastically different SharePoint 2010 UI, They can still live with old SharePoint 2007 style UI.

But it had some drawbacks which makes it less usable. For an instance let’s assume we had web parts and some elements which we used in our SharePoint 2007 environment. Most of the time we get errors or they me not render properly in our new migrated environment.

SharePoint 2013 has improved a lot in the visual upgrade process and it provides us some additional benefits as well.

When we do a fresh installation, it’ll create both 14 and 15 folders in “Web Server Extensions” folder. (So we can say both 14 hive and 15 hive exists in SharePoint 2013 environment).

Why do we need both 14 and 15 hives in our SharePoint environment and what are the improvements in visual upgrade process ?

As far as I see, there are 2 main benefits

• Since it has Features, Layouts and Assemblies related to SharePoint 2010 solutions(WebParts and other elements) in 14 hive solutions will run seamlessly in a migrated environment.
• Apart from that when we deploy new SharePoint solutions (WSPs) we can target a specific compatibility level (SharePoint 2010 and 2013) as well by using the CompatibilityLevel Switch.
• We can scope site collections or entire web applications to SharePoint 2010 mode. If it is scoped in that way newly created site(s) will contain SharePoint 2010 UI and features. Simply say we can create sites in SharePoint 2010 compatibility mode as well as SharePoint 2013 compatibility mode.

In a separate post I’ll show some additional benefits of SharePoint 2013 compatibility modes.