Case study
SharePoint support: taking back control of document sharing
Training, governance and migration: helping IT departments make SharePoint the company's document reference, in place of file servers and improvised Teams sharing.
- Client
- Several clients
The context
Almost every company running Microsoft 365 already has SharePoint. Few really use it. In practice, documentation stays on a legacy file server, and Teams has filled the gap — because it was there, not because it was designed for it.
The result is document sharing that escapes the IT department: nobody knows any more where the authoritative version is, or who has access to what.
What goes wrong
The file server is showing its limits. It assumes a connection to the corporate network, which suits neither remote work nor sites abroad. It offers no native way of sharing with the outside world.
Teams has taken over without being meant for it. The same document ends up dropped into several teams, with no authoritative version. External sharing is often open by default, and an ordinary member can invite a third party without any manager having to approve it. When a team is abandoned or deleted, the documents it held go with it.
IT has lost visibility. Creating a team is unrestricted, spaces multiply, and some channels create storage areas invisible even to their owner.
What we do
Our role is not to deliver a platform and leave: it is to make the in-house teams self-sufficient on a tool they already own. Four kinds of engagement, depending on the client's maturity.
Presenting and training. A session on SharePoint administration and what it genuinely allows in document management: creating and organising sites, managing access, good maintenance and governance practice. This is often the starting point — many decisions are taken badly simply because what the tool can do is poorly known.
Setting the governance. Defining who creates what, how rights are granted, what is shared externally and subject to which approval, what is retained and for how long. Without those rules, any tidying up unravels within months.
Auditing before go-live. A technical review and hardening of an existing SharePoint or Power Platform development before it is deployed, or an analysis of a malfunction on an application already in service.
Supporting the migration. Moving the content of a file server or of scattered Teams shares into a properly held SharePoint structure, preserving the existing access rights.
An example: from a file server to SharePoint
At one of our clients, the remotely accessible file server remained the document reference, while Teams was used for sharing between sites. Two competing sources, then, and neither authoritative.
We ran a workshop with the IT teams to establish a clear priority: deal with the file server content first, in order to offer a structured alternative to Teams sharing quickly and reduce the associated risks.
A prototype was then built to validate the target organisation before any rollout: a hub space bringing together the various document areas, each keeping its own access rights. On the home page, each employee sees only the areas they actually have access to — with no per-area configuration to do.
The project is at the pilot stage: a limited but representative scope, used day to day over a defined period, to surface the real usability difficulties before deciding on a general rollout.
What it changes
The IT department regains control over what is shared, with whom, and for how long — without taking away the flexibility teams have grown used to, since every document area remains reachable from their Teams.
And because the approach starts with training and with a pilot proven in real conditions, it is the in-house teams who hold the solution afterwards, not us.