By way of providing a context to this, I am currently helping a government department make the transition from SharePoint on-prem to SharePoint Online (SPO) – it seems to be a main-stay of my tasking these days.
The department in question held onto a legacy document/records management solution for SharePoint 2010 (yes you read that right) for a decade longer than they should have. This solution was aimed at delivering enhanced governance and compliance with documents stored in SharePoint libraries and a key requirement for this product to work as intended was to ensure that major/minor versioning was enabled and that whenever a document was edited, it was automatically checked out.
In case you are unaware of this feature, SharePoint allows users to check-out documents which amounts to planting a flag on them, preventing anyone else making changes to the document until it is once again checked in (or the check-out overridden by an owner/admin with consequence of losing all pending changes).
On the face of it, enforcing checkout might seem like a sensible idea and it is super easy to set up (to this day) – just set the radio button in Library Settings > Version Settings.
If you are remotely interested in my thoughts on major/minor versioning, I encourage to read my post SharePoint Document Version Control and Content Approval works but…, where I reach the conclusion that there relatively few cases where you need to enable minor versioning.
Fast forward, and thousands of libraries and hundreds of thousands of documents have been successfully ShareGated to SPO. The only problem is that whilst the legacy records management tool has (at long last) been dropped, the library settings required by that system (minor versioning/forced checkout) remained intact.
In hindsight, the team might have being able to set up ShareGate to address this, but that happened before my time and I think there was a degree of nervousness about trying to do anything too clever – which is totally understandable.
Experience has taught me that these features have a downside. The problem with check-out is that users tend to leave documents checked out by accident, rather than by intent, and then have an annoying habit of taking leave or leaving the organisation altogether, thereby leaving documents in an unstable state. Do we dare discard their changes for fear that we might drop something important?
Consider also, that this feature is as old as SharePoint is and was developed long before the idea of co-authoring (where multiple uses can edit the same document concurrently) was considered a viable option. Obviously, check-in/out and co-authoring are mutually exclusive features!
And a major problem with minor versioning (no joke intended) is that draft items (those which have never made it to version 1.0) are not (by design) indexed by the search engine – leaving users concerned and confused as to why these documents don’t show up in search results.
It turns out that only about a third of the migrated documents where ever published as a major version and so 2 thirds of the document corpus remains invisible to searchers!
Sadly, switching off enforced checkout still leaves checked-out documents in a checked-out state, and switching versioning to major versions only, does not automatically publish draft items to v 1.0 (although new items will come in at version 1.0).
This means we still have a lot of work to do to bring everything in order. I either need to put users to the task (which involves training them and straining them) or I must develop some kind of tool or script to deal with this – but that means losing/hiding when the document was last modified and by whom.
The moral of this story is to think long and hard before you enforce document check-out or enable minor versioning. I’m not saying that these features should never be used but rather that they should be used with some caution and awareness of subtle side effects that may come back to bite you.