Document Version Control: Rules That Survive Real Work

Document version control is the set of rules that makes one copy of a document authoritative and every other copy obviously not. It sounds administrative until the week two people negotiate the same contract from two different files and only find out at signing.

Every organisation has version control. The question is whether it lives in file names and memory, or in a system.

Why file names stop working

The naming convention is the first thing anyone tries, and it works for exactly one person. contract_v2_final_AB_comments.docx encodes four facts: a number, a state, an author and a purpose. Three of the four are opinions.

It breaks in predictable places. Two people edit in parallel and both produce a v3. Somebody renames a file to tidy up and detaches it from its history. An attachment leaves by email and comes back changed, with the same name. None of these are carelessness; they are what happens when the only thing holding the version is a string somebody typed.

What version control has to give you

One authoritative copy

There is exactly one current version, and the system says which. Everything else is history, reachable but clearly not current. This is the whole point, and most of the other features exist to protect it.

A history you can open

Not a list of dates: the actual earlier versions, openable, with who saved each one and when. The useful question is rarely "what changed" in the abstract. It is "what did this look like on the day we signed it".

Check-out, or a way to prevent collisions

Either the system locks a document while someone edits it, or it merges concurrent edits properly. What it must not do is let two people overwrite each other silently and discover it later.

Major and minor, if your process needs it

Drafts and approved versions are different animals. Numbering that distinguishes 1.3 from 2.0 lets people see at a glance whether they are reading something agreed or something being worked on. It is optional, and it is worth it anywhere a document gets approved.

A link between the version and the approval

The version that was approved should be identifiable as the version that was approved, not reconstructed later from an email thread. Where approvals run in the same system as the document, that link is automatic; where they do not, somebody has to maintain it by hand, and somebody will forget.

Versions and retention are different clocks

This catches people out. Version control answers "which copy is current". Retention answers "how long is this kept and when is it destroyed". They run on different clocks, and a system that confuses them either deletes history that was still needed or keeps every draft of every document forever.

The practical rule: the record is the case, not the file, and the term sits on the case. Earlier versions are part of that case and live under the same term. Working drafts that never became anything can usually go earlier, and that is a decision to make deliberately rather than by accident.

Where versions actually get lost

• At the boundary. A document leaves the system as an attachment, gets edited outside it, and comes back as a new file with no connection to its own history.
• In the copy made "just in case". Someone saves a personal copy before a risky edit. That copy survives, gets shared, and becomes a second authoritative version nobody declared.
• In the migration. Moving documents between systems frequently flattens history into the latest version. That is a decision; it should be made on purpose, not discovered afterwards.

Where this sits in our products

If your documents live in Microsoft 365, versions are native to SharePoint and our document management for Microsoft 365 works on top of them, adding approvals and contract flow in the same place. If you run the classic platform, versioning is part of document management software. The two are different architectures rather than two editions of one thing, and the right one depends on where your documents already are.

Once a document stops being worked on, it moves into the archive, where versions are no longer the question and terms are: that is document archiving software, with the rules on top handled by records management software.

FAQ

What is the difference between version control and a backup? A backup lets you recover after a failure and is overwritten on a cycle. Version control keeps earlier versions deliberately, as part of the document's own history, and they stay available to users rather than to administrators.

Do we need major and minor versions? Only where documents get approved. If every save is equal and nothing is ever formally agreed, a single incrementing number is simpler and people will actually use it.

How long should old versions be kept? Normally as long as the case they belong to, because an earlier version can be the thing an auditor or a court asks for. Working drafts of documents that never went anywhere are the exception, and the rule for them should be written down rather than improvised.

Can version control work if people edit in desktop Word? Yes, provided the document is opened from the system rather than from a downloaded copy. The failure mode is almost always the local copy, not the editor.

Related reading. the six stages of a document, what document archiving is, how to write a retention policy.

See it on your own documents. Talk to us and we will show versioning on a real approval flow rather than on a sample file.