Microsoft 365 platform ownership

The problem

Everything else on this site is an application. This is the platform many of them run on: a Microsoft 365 tenant serving more than 7,000 employees, with three administrators responsible for the whole of it.

With three people for the tenant there is no one further up to hand a hard problem to. Governance, site provisioning, permission architecture, the app catalogue, storage and the escalations from every department land on the same three desks. Self-service and automation are therefore not preferences.

What I did

I administer the tenant: governance and provisioning, the security groups behind the permission model, storage across the tenant, and every custom component in the app catalogue. Several of those components are mine. I build the newsletter builder and the navigation extension, release them, and deploy them to the tenant I administer, so for that layer I am the developer, the release manager and the platform owner.

I plan, run and teach the company's move off mapped network drives onto SharePoint and OneDrive. The largest so far is the sales department's hub, one site serving the whole of sales. A file-share move is not a copy: a folder tree that grew for fifteen years has to become an information architecture, with decisions about what is a site, what is a library, what becomes metadata instead of a folder level, and what is personal data that belongs in OneDrive.

The teaching is half the work and it decides whether a migration succeeds. People who have worked in a mapped drive for a decade want their files where they left them. Co-authoring, version history, sharing links instead of attachments and search instead of remembered paths are adopted only when someone stands in front of the department and shows them.

When the tenant's storage pool was filling, I ran the analysis and the remediation, audited all sites and reclaimed storage. That work has its own page.

A decision and its cost

After the cleanup, I recommended in writing that the next gain should come from policy rather than another cleanup. Trimming version history is a one-off gain bought with a recurring cost; server-side version limits are a one-off cost for a permanent gain. I also showed that the tenant's capacity follows a published formula tied to licences, so there was nothing to negotiate with the vendor, and that personal data leaving the file server should land in OneDrive, where it is effectively free, rather than on team sites.

Version limits are the slower route: they cost a policy change and a conversation with every site owner, where a cleanup needs only the administrators. The report marked its own reconstructed capacity figures as unverified, with the commands to check them, so the recommendation could be checked rather than taken on trust.