With the release of SharePoint 2010, a feature known as backwards compatibility mode was introduced. There is very little public documentation available around this feature, so in this post I will try and clarify what it is, how it works, and a few very important things to be aware of which will impact your SharePoint update deployment plans, whether you like it or not!
What is backwards compatibility mode?
The primary reason this feature was introduced was so that if security updates affecting SharePoint are ever released on Patch Tuesday, and Microsoft Update pushes the update out to servers in a farm and to be installed., rather than forcing PSConfig to run and immediately incur downtime after the patch has been installed, the database upgrade piece can be deferred to a later date. This means you can benefit from the patch (e.g. security fix) without experiencing huge amounts of downtime. When the database upgrade is deferred, the databases are in “backwards compatibility mode”.
However, it was only ever intended that it’s used in the scenario described above, and that you run in this backwards compatibility mode for short periods of time. Running in this state for too long can cause some inconsistent behavior.
How does it work?
As mentioned above, backwards compatibility mode allows binaries on the server to be at a higher build than the databases.
But how much higher we can go? The way this is supposed to work is that the backwards compatibility mode will be re-based lined with Service Pack releases, i.e. Service Packs should introduce a compatibility boundary. A compatibly boundary would mean that after Service Pack deployment, we would not be able to upgrade binaries on the server and defer database upgrade. So we support an N-1 range of binaries on servers to database backwards compatibility where N equals a Service Pack build.
Does Service Pack 1 introduce a compatibility boundary?
Based on the description above, we’d expect Service Pack 1 (SP1) for SharePoint to introduce a compatibility boundary for SharePoint. SP1 introduces a partial boundary for compatibility mode. It is essentially the Search service which introduces a boundary, preventing indexing from functioning until after upgrade has completed across the entire farm. In theory everything else should still work except that indexing will stop and start getting stale until you upgrade, but search queries will still function across the existing index.
On top of that, there are more adverse effects of SharePoint Foundation Search, in that the service is unlikely to start, and consequently not function whatsoever. Upgrading the entire farm will ensure all of the above works as expected.
It’s also worth pointing out that only when the content databases are upgraded that important new capabilities like the site and site collection restore features will light up, which depend on database schema changes to function.
If I haven’t given you enough reasons to avoid running databases in compatibility mode post SP1 deployment, there is one scenario where you may consider to this, but proceed with caution!
In the scenario that you have Search running in a Parent or “Services” farm, it would be possible to use backwards compatibility mode to spread the upgrade out across a couple of weeks if really required. The farm not running search could have databases upgraded at a later date, but as for the services farm, the full upgrade should be carried out at once. I would only recommend running in compatibility mode as described here if you really think there’s no way you can upgrade all content within one service window, and would only suggest delaying upgrade by a couple weeks at most after SP1.
Another reason to stay away from this...
By now you’ll have gathered that staying in backwards compatibilitymode for any long periods of time is NOT a good idea.
SP1 is a good example of why this is true and future service pack releases will be even better ones. If you patch to SP1 but don't upgrade, several things will be broken or not be available, as described above.
As per the N-1 range of binaries to database backwards compatibility, thinking about a future service pack release, this could cause the entire farm to stop rendering entirely if the databases had not been upgraded to at least SP1. Once again running a farm upgrade would fix that after applying the next service pack, but one should have run upgrade long before that to prevent the unexpected outage.
Final thoughts…
It should be clear by now that this feature was designed to prevent unexpected outages due to a patch deployment, but was not meant to support an upgrade approach. You should only ever run in a state where you are patched but not upgraded for hours or days, a couple weeks at most, but not for months or longer as the above or potentially other issues could arise. A farm should be alerting you via its health rules that you when and if you are ever in this state, and if you find out that you are, you should address it ASAP.