Do we need to rename every existing file to match the new convention?

No, and trying to is usually what kills the rollout. Apply the convention to new files from an agreed date forward, then fold existing files in gradually, whenever someone next opens and edits them, or as a background cleanup task. A library doesn't need to be 100% consistent to be dramatically more useful than it was.

Should the version number stay out of the filename even for important documents?

Yes. SharePoint keeps a full version history for every file automatically, so a version number in the filename is redundant at best and actively misleading at worst, because it splits one document into multiple file objects that search and Copilot can each surface separately. If a document needs a stage marker, use a status word like Draft, and remove it once the document is final.

Why does the date format matter if everyone can already read dd-mm-yyyy?

People can read either format fine. The problem is sorting: a file list sorted alphabetically only sorts chronologically if the date is written yyyy-mm-dd. Any other format sorts as plain text, which scatters files from the same month across the list and makes the most recent version of anything hard to spot at a glance.

What should we do about client names that already have inconsistent spelling across old files?

Fix the reference list first, one agreed short code per client, written down somewhere everyone can check, then apply it consistently to everything new. Older inconsistent files can be corrected opportunistically rather than in one project; the goal is that the variant spelling stops multiplying, not that history gets rewritten overnight.

Are there characters we should avoid in filenames even if they seem to work fine today?

Yes. Characters like #, %, &, ~, *, {, }, \, /, :, , ? and | can cause sync or upload failures for some users even when they appear to work for others, because different apps and platforms handle them differently. Sticking to plain letters, numbers, spaces and hyphens avoids the problem entirely rather than relying on everyone remembering an exceptions list.

SharePoint file naming conventions: a system teams will actually use

Most businesses already have a file naming habit. It's just not a convention, it's whatever each person happened to type under deadline pressure: Invoice Final.docx, Invoice Final v2.docx, Invoice Final v2 ACTUAL.docx, Copy of Invoice Final v2 ACTUAL(1).docx. Nobody designed that. It accreted, one rushed save at a time, and for years it didn't really matter because a person went looking for the file, recognised the icon, remembered roughly when they saved it, and opened it.

That tolerance is gone. Once SharePoint search and Copilot are doing the retrieving, on a colleague's behalf or as an answer stitched into a chat reply, a filename stops being a private mnemonic and starts being metadata a search index and a language model both have to parse. A file called Invoice Final v2 ACTUAL tells a human almost nothing useful either, but a human at least knows to be suspicious of it. An AI assistant surfacing it in an answer just reads it as the invoice.

Why naming matters more now than it did five years ago

Search and Copilot rank and summarise content using signals that include the filename, the folder path, the document title, and how recently the file has been touched. A clear, consistent name is one of the cheapest, most reliable ways to influence which document wins when three similar files exist, because it's a signal every file has, unlike well-maintained metadata columns, which most libraries don't. Consistency also compounds: one well-named file doesn't do much, but a thousand files following the same pattern make an entire library predictable and far easier for a new starter, or an AI assistant, to reason about correctly the first time.

A convention worth adopting

The best naming convention is not the most descriptive one, it's the one a busy team will actually follow at 4:45pm on a Friday. That means short, that means predictable, and that means it fits a template people can hold in their head without opening a policy document to check it. A dependable structure looks like this:

[Date] [Client or Project] [Document type] [Short description] — the four building blocks, in that order, separated by a consistent character
Date always in ISO format: yyyy-mm-dd, for example 2026-08-19
Client or project as a short, fixed code or abbreviation, not the full company name spelled out differently each time
Document type as a short fixed word: Invoice, Contract, Report, Minutes, Policy
A short description in plain words, no more than four or five, with no version number and no 'final' anywhere in it

Applied, that turns Invoice Final v2 ACTUAL.docx into 2026-08-19 Acme Invoice August services.docx. It's longer to type once and dramatically faster to find, sort and trust for the rest of the file's life.

Dates that actually sort in order

This is the single highest-leverage change in the whole convention. Write dates yyyy-mm-dd, not dd-mm-yyyy and not the shorthand version with the year dropped. A file column sorted alphabetically is also sorted chronologically the moment every date in it is ISO format, oldest to newest or newest to oldest with one click, no separate date column required. Any other date format sorts as text, which means 03-01-2026 lands next to 03-02-2025 and nowhere near 01-03-2026, and nobody notices until they're looking at the wrong month's figures.

Characters and length that don't break things

A handful of characters cause real problems in SharePoint and OneDrive and are worth ruling out entirely: the tilde, hash, percent, ampersand, asterisk, curly braces, backslash, forward slash, colon, angle brackets, question mark and pipe symbol can all cause a file to fail to sync, upload, or open correctly for some users. Leading and trailing spaces and periods cause similar trouble. The safe habit is plain letters, numbers, spaces and hyphens only.

Path length is the other quiet failure mode. SharePoint counts the full path, site address, library, every folder in the chain, and the filename itself, and a path that runs too long will fail to sync to OneDrive on some machines even though it opens fine in a browser, usually with an unhelpful error that doesn't explain why. Deep folder nesting, exactly what a naming convention is meant to reduce the need for, is the usual culprit. Keeping folder structures shallow, three or four levels at most, and using a short client or project code rather than a spelled-out folder name at every level, keeps the whole path well within safe limits.

Client and project prefixes without a mess of exceptions

For any business that works across multiple clients, projects, or cost centres, a short fixed code beats a full name every time. Decide the code once, when the client or project is set up, write it down somewhere everyone can check, and never invent a variant later. The failure pattern to avoid is the same client appearing as Acme, ACME Corp, Acme Corporation and Acme Pty Ltd across four different files, which defeats both a human scanning a list and search trying to group results by client.

1Assign the code when the client or project folder is created, not when someone first needs to save a file into it
2Keep a single reference list of codes, a simple page or list in the site itself works fine, no separate system needed
3Use the code consistently in the folder name and in every filename saved inside it
4Treat a new variant spelling as a bug to fix immediately, not a style choice to let slide

Rolling it out without a mutiny

A naming convention that arrives as a two-page policy document nobody reads will not survive contact with a real deadline. The rollouts that stick are short enough to fit on one page, start with new files rather than demanding an immediate rename of everything that exists, and give people one visible example to copy rather than an abstract rule to interpret.

Write the convention as a single template line plus two or three worked examples, not a policy document
Pin it somewhere it will actually be seen, the top of the document library itself, not a page three clicks away in the intranet
Apply it to new files from a set date forward; don't demand a mass rename of the existing library on day one, it kills momentum and nobody finishes it
Fold existing files in gradually, whenever someone touches them next, or as a background cleanup task rather than a big-bang project
Nominate one person per team as the person who fixes a wrong name on sight rather than walking past it, habits hold when someone visibly cares

Before and after, worked

A short before-and-after set makes the convention concrete faster than any amount of explanation. Here's a typical folder of client files before and after the convention above is applied.

Before: Contract FINAL.docx → After: 2026-08-19 Acme Contract Services agreement.docx
Before: Report_v3_use this one.pptx → After: 2026-08-19 Acme Report Quarterly review.pptx
Before: Meeting notes (2).docx → After: 2026-08-12 Acme Minutes Project kickoff.docx
Before: Policy new NEW.pdf → After: 2026-08-01 Internal Policy Leave and remote work.pdf
Before: Copy of Invoice v2 ACTUAL.pdf → After: 2026-08-19 Acme Invoice August services.pdf

None of the after versions take more effort to type, they're simply structured the same way every time, which is the entire point. That fixed order is what makes the library, and everything reading it, trustworthy.