SharePoint support — architecture, governance and audits

Why Teams does not amount to document management

This observation comes up at most clients and on its own justifies prioritising a migration to structured SharePoint libraries.

• Duplication. The same document is dropped into several channels or several teams, with no authoritative version.
• Diverging versions. Without structured version management, several states of the same file coexist, with the risk of working on an out-of-date one.
• Uncontrolled sharing. External sharing is often on by default, and a standard member can invite a third party without an owner's approval.
• Coarse permissions. Rights follow membership of the team as a whole: no granularity per folder or per business process.
• Loss on archiving. Deleting or abandoning a team means losing access to — or permanently losing — documents that should have been kept.
• No document governance. No metadata, no classification, no retention policy: finding a document rests on individual memory.
• A blind spot for IT. Private and shared channels create hidden SharePoint sites, invisible even to the team owner — hence concentrations of content outside any control.
• Drift from the source. A copy circulates on Teams while the original keeps evolving on the file server: two competing sources.
• Sprawl. Team creation remains unrestricted, which multiplies uncoordinated spaces for one and the same need.

The migration architecture chosen

A proof of concept was built on SharePoint to validate the target architecture before industrialisation.

A hub site brings together the subsites corresponding to the folders of the network share.

One site per folder, rather than a single library. Each folder of the share currently carries its own permissions. Creating a dedicated site per folder preserves that granularity as it stands, instead of rebuilding it through broken inheritance inside a single library — a model that quickly becomes unmanageable.

Each site can be associated with a Teams team, which limits the disruption for users accustomed to their current space: the governance changes, their way in does not.

The Sites web part, tested on three pilot sites

Three pilot sites were created under the hub to try out the Sites web part in "all sites in the hub" mode. It adapts to the current user: on the hub home page, each person only sees the tiles matching their actual permissions — with no per-site configuration. The tests were conclusive.

The blocking prerequisite for the migration

Content migration relies on ShareGate, carrying over the existing folder-level permissions, grouped by security group.

The local Active Directory security groups carried by the file server folders must be synchronised to Entra ID before the migration.

The reason is mechanical: ShareGate resolves permissions through the SharePoint people picker, which queries Entra ID and not the local directory. Without that prior synchronisation, automatic group mapping does not work — and the permissions have to be recreated by hand.

The method

1. Pilot on a test structure with a limited scope, but representative of the variety of folders.
2. Daily use over a defined period, to surface the real irritants: ergonomics, habits, complex permission cases.
3. Consolidation of the feedback before any decision to industrialise.
4. Migration of all the subfolders, followed by the permissions.

A point to watch

The "one site per folder" principle answers the need for granularity on the pilot scope. It is worth watching when extending to the whole file server: a larger number of folders could make it necessary to group some sites by business process rather than keep a strict one-to-one mapping — otherwise the risk is recreating on the SharePoint side the sprawl we were trying to correct on the Teams side.

Possible next steps

• Extend the migration beyond the first share, once the method is validated.
• Automatically synchronise the application files — those that third-party software reads and writes — between the file server and SharePoint during the transition, using Power Automate.
• In time, make SharePoint the single entry point for company documentation, file server and Teams included.

Auditing Power Platform applications

Another kind of engagement: reviewing Power Apps and Power Automate applications already in service, or about to be deployed. The themes that come up most often:

Connector reliability. On a field application suffering from dropped connections, the analysis covered error handling, the unification of redundant connectors — thirteen of them brought back to a common definition, through a mapping table and a unified connector delivered to the client — tablet configuration, and reducing the number of calls.

Delegation. The most frequently overlooked point: a non-delegable query is evaluated client-side on the first records only, and the application returns wrong results as soon as the volume exceeds the threshold, with no visible error.

Version and solution layer management. A typical case: an unmanaged layer that reappears on the application after every deployment, silently overriding the properties of the released version. Possible causes are connection binding at import, opening the application for editing directly in production, or sharing carried out outside the solution.

Other recurring themes. Delegation of rights, usage tracking through Power BI, synchronisation with a SQL database, and offline operation for applications used in the field.