Most restaurant groups I walk into are running their entire operational backbone off a shared drive. The ops manual lives at S:\Operations\Manual\2024\Final. The recipe cards are in S:\Kitchen\Recipes, organised by head chef initials and last modified in 2022. Supplier contracts sit in a folder called Contracts_new alongside Contracts_old, Contracts_archive and, inevitably, Contracts_DO_NOT_DELETE. It works. Nobody is on fire. The kitchen can find the allergen matrix when EHO walks in. And that is why nothing changes.
The trouble is that the shared drive works about 80% of the time. The other 20% is where the operation quietly leaks - version conflicts, lost files, GMs on site who cannot open something on a phone, the compliance folder that turns out to be three months out of date the week before audit. If you run ops for a growing group, 80% is about to become a problem. Here is why, and what actually works instead.
What your shared drive is really doing
Stop and list what lives on that file server. In a typical 12-site casual dining group, I expect to find: the brand ops manual, SOPs by department, recipe and spec cards, allergen and nutritional data, training decks, site-opening checklists, supplier contracts and price lists, insurance and lease documents, weekly rotas, payroll exports, stocktake spreadsheets, HR templates, disciplinary records, maintenance logs, and a few hundred photos from the last relaunch that nobody has moved to the marketing drive.
The shared drive is not just a file store. It is doing three jobs at once. It is the document repository, the approval workflow (by email with attachments) and the version control system (by filename). That last one is where the wheels come off. You know the pattern - MenuSpring2026.docx, MenuSpring2026_final.docx, MenuSpring2026_final_v2.docx, MenuSpring2026_final_KIERANEDITS.docx, MenuSpring2026_USE_THIS_ONE.docx. Six files, three of them actually different, and the one the kitchen printed last Tuesday is not the one finance costed.
Why this fails at scale
The failure modes are predictable and they get worse the more sites you run.
No version history. When someone overwrites the master allergen matrix with last month’s version, the only recovery is a tape backup restore, assuming your IT provider still has tape backups and assuming they run within the restore window. I have sat through that conversation more times than I would like.
Broken permissions. Shared drives inherit permissions from folders, and over years of “can you just give Sarah access to that one folder” requests, the permission model becomes a plate of spaghetti. Nobody can tell you who can see what. When a GM leaves, removing their access means a half-day of clicking through folder properties, and you will miss something.
No audit trail. If a disciplinary file is modified, a supplier contract is deleted, or a price list is edited on a Friday evening, you have no reliable way to answer “who, when and what”. For HR and compliance work, that is a real exposure.
Lost files. People save locally “just to work on it”, then forget. The only copy of the Q4 training deck is on a laptop that went home with a starter who lasted three weeks.
No mobile access. This is the one that bites hardest in hospitality. Your area managers are in cars and on trains. Your head chefs are on the line. Your GMs are on the floor. None of them are sat at a desk with a drive letter mapped. If they cannot pull up the stock sheet or the latest SOP on a phone, they will not use it.
No search. Finding “the risk assessment for the pizza oven at the Shoreditch site” on a shared drive means remembering where someone filed it in 2023. SharePoint search, done properly, will give you that document in three seconds.
SharePoint is not perfect, but it fixes most of this
I am not going to pretend SharePoint is a clean, elegant product. It is Microsoft, it is opinionated, and it will happily let you recreate your shared drive mess inside a document library if you let it. But out of the box it solves the big problems: version history on every file, granular permissions with clear reporting, full audit logging, mobile access through the SharePoint and Teams apps, and a search engine that actually works if you feed it the right metadata.
The catch is that SharePoint only delivers those benefits if it is designed deliberately. “Lift and shift” a shared drive into a single SharePoint library and you will get the worst of both worlds - Microsoft’s quirks on top of your existing structural problems. The migrations that fail are always the ones where somebody treated SharePoint as a drive letter replacement.
Translating shared drive thinking into SharePoint
For ops teams making the jump, the mental model shifts like this. A shared drive folder becomes a SharePoint site. A shared drive permission (which user can open this folder) becomes a SharePoint group (which role can access this site). A file path like S:\Ops\Compliance\Fire\2026 becomes a document library with metadata - document type “Fire”, year “2026”, site “All” - which means the same document can be found by anyone looking under Compliance, Fire, or 2026, without duplicating it.
That last shift is the hardest one for long-time shared drive users and the most valuable once it clicks. You stop filing things by where they live and start tagging them by what they are.
Design principles for a hospitality SharePoint build
When we design SharePoint for a restaurant or hotel group at CloudMatters, we work to a small set of principles that have held up across every client we have migrated.
One hub site, one site per venue, one site per function. The hub is the brand home - ops manual, company news, policies, training. Each venue gets its own site for local documents, site-specific risk assessments, rotas, and the operational bits that only matter there. Each function (HR, Finance, Marketing, Kitchen, Maintenance) gets a site for its own working documents. This structure scales cleanly from 5 sites to 50 without restructuring.
Metadata over folders for anything that needs to be findable. Recipe cards, compliance documents, supplier contracts, risk assessments - all the documents where “where is it filed” is the wrong question. These go into libraries with columns for site, document type, effective date, and owner. Folders are fine for working drafts and marketing assets, which are browsed rather than searched.
Read-only for most users, edit for function owners. The default permission model is that everybody in the company can read the ops manual, the SOPs and the training content. A small number of function owners can edit. This is a reversal of the typical shared drive, where permissions are granted narrowly and hoarded jealously. Read-by-default is safer, not less safe, because it removes the “just give me access” email chain that leads to accidental over-sharing.
Approvals built in. Power Automate runs approval workflows for the documents that need them - menu changes, price list updates, SOP revisions. The approver gets an email, clicks approve, and the new version is published. The old version is retained in history. There is no “can you email me the latest one” because the latest one is the one in the library.
The mobile angle
This is the part that sells SharePoint to your operators. Install the Teams app on a GM’s phone, pin the venue’s SharePoint site as a tab, and suddenly every document they need is two taps away on the line. The allergen matrix, the emergency contact list, the fire procedure, the deep clean schedule, the week’s rota. No VPN, no drive letter, no “can you email me that”. For FoH managers and head chefs who have never had proper document access from their phones, the difference is immediate and visible in week one.
Combine this with Teams for in-the-moment chat - the venue channel, the head chef group, the duty manager rotation - and you have the operational backbone in a single app that people already have on their phones.
Common pitfalls when moving
Permission sprawl. The biggest mistake is to recreate the old permission structure inside SharePoint, site by site, folder by folder. Don’t. Start from the principle of read-by-default, write-for-owners, and only carve out exceptions where there is a real reason.
Migration failures. Large shared drives have files with illegal characters in names, paths that exceed Windows limits, duplicates, and hidden system files. A naive migration tool will choke on all of these. Budget time for a clean-up pass before you move, and run the migration in waves rather than a single big bang.
User resistance. The team who has spent five years mastering S:\ does not want a new system. The answer is training that shows the things they cannot do today - finding a document from a phone, seeing who edited a file, getting the real latest version. Once a head chef finds a recipe in three seconds on their phone, you will not get them back.
Security as an afterthought. SharePoint lives inside Microsoft 365, so getting the underlying tenant right matters. MFA, conditional access, external sharing controls and data loss prevention all need to be configured before you migrate anything sensitive. This is where we lean on our cyber security team to harden the tenant before a single document moves.
How we approach a migration
Our process at CloudMatters is simple: design, migrate, train. We start with a workshop on how your ops team actually works - what they file, what they search for, who owns what. From that we design the site structure, the metadata schema and the permission model. Then we clean up the shared drive, run a staged migration, and sit with each function through a training session on their new site. We do not leave the old drive live for long - it creates a fallback that people use for months and undermines the whole move.
The groups who have done this with us typically see two tangible changes within the first quarter. First, the compliance binder catches up to reality, because the effort of updating a document collapses from “find it, rename it, email it, hope everyone uses the new one” to “edit the one that exists”. Second, the operational questions that used to eat half a day a week - where is the latest version, who has access, can you send me that - simply stop arriving.
If your group is still on a shared drive and starting to feel the strain, this is the conversation to have. Our managed cloud team runs SharePoint design and migration projects across London hospitality, end to end, with the operational understanding to get the structure right first time. We would rather design it once properly than rebuild it in two years because the original move was a lift-and-shift.