At 500 to 5,000 employees, the cost of not having an M365 strategy stops being theoretical. You are running dozens of teams on top of legacy systems and a meaningful cloud spend, and every inefficiency scales with you. The same tenant that quietly absorbs disorder at fifty people starts to generate it at two thousand.
We get called in at the point where that disorder has a name. Teams nobody can find. A SharePoint estate no one has mapped. A Copilot pilot that underwhelmed because the data underneath it was a mess. None of these are platform problems. They are strategy problems, and they are fixable in a particular order.
Three things a strategy has to settle
Before the tooling, a strategy resolves three questions. Skip any one and the other two come undone.
What do we actually have? A usage baseline, pulled from your own admin reports, that separates the active platform from the dormant one.
What are we consolidating, and into what? A migration plan that moves legacy data — on-prem servers, a second cloud, the Dropbox nobody decommissioned — into M365 with a clear home for each kind of file.
What keeps it from sprawling again? Governance: who can create sites, how sensitive data is labeled, what gets retained and for how long.
You cannot migrate what you have not assessed, and governance built on disorganized data just preserves the disorder. The work runs in that sequence for a reason.
Start with what the tenant already tells you
Most of the assessment is sitting in the Microsoft 365 admin center, unread. Before recommending anything, we pull a few reports and read them honestly.
The SharePoint Active Sites report shows where collaboration is actually happening and how many stale sites are quietly accumulating. Teams usage tells you whether the platform is a workspace or a notification channel — low chat and meeting activity across thousands of seats usually points to a configuration or training gap, not disinterest. OneDrive usage is where you spot file hoarding and people routing around Teams for collaboration. And the Adoption Score gives you a rough read on whether the organization’s habits are AI-ready or not.
None of these are vanity metrics. Exported monthly, they become the before-and-after you measure the strategy against. Most of Microsoft’s reports only look back 90 days, so the discipline of pulling them on a schedule matters more than any single snapshot.
Move the data before you govern it
Legacy systems are where mid-sized organizations carry the most weight — on-prem file servers, a rival cloud, archives no one has opened in years. We work through it in a fixed order: inventory what exists, prioritize what is actually current, decide where each kind of file belongs, then move it.
The mapping is the part that pays off later. Personal files go to OneDrive. Project and department files go to SharePoint team sites, ideally linked to the Team that already uses them. Tools like ShareGate make the move itself routine; we still test with a small slice before committing a weekend to the full set. The win is rarely just retired infrastructure. It is that the data finally lives somewhere structured enough for Copilot to reason over.
Governance is what stops the second migration
Sprawl is not a one-time event. Without guardrails, the estate you just cleaned up rebuilds itself within a year. A few decisions prevent most of it:
- Take SharePoint site creation out of self-service and route it through IT or named business owners.
- Use sensitivity labels in Purview to keep confidential material from being shared externally by default.
- Set a retention policy on Teams chat — we usually land around 90 days — so Copilot is reasoning over current context, not years of noise.
- Lock or archive dead sites on a schedule rather than letting them sit.
None of this is heavy. It is a handful of settings and a monthly habit of reading the Active Sites report. The alternative is paying for the cleanup twice.
Phase it, and let each phase earn the next
Trying to assess, migrate, govern, and prep for AI at once is how these programs stall. We run them in three phases, and the order is the point.
Phase one is foundation. Assess usage, consolidate the obvious legacy data, and put the governance guardrails in place. Address Teams sprawl by limiting who can spin up channels and sites, and establish naming conventions before there is more to rename. Pilot the changes with IT and one willing department before touching everyone.
Phase two is adoption. This is where HR carries more of the weight than IT — short, role-specific training beats a two-hour overview every time. Tune the defaults that make Teams livable, whitelist the partners who actually need guest access, and use the Adoption Score insights to see what is moving.
Phase three is AI prep. Label sensitive content so Copilot respects the boundaries you have set, clear out the stale sites, and pilot Copilot with one team whose work you can actually measure. By this point the data is clean enough that the pilot is a fair test rather than a disappointment waiting to happen.
Measuring it without fooling yourself
The same reports that built the baseline tell you whether the strategy worked. A rising Adoption Score, more genuine Teams activity, OneDrive replacing the old file shares, stale SharePoint sites trending down. Read them monthly, review them quarterly, and write down what changed so the next decision has something to stand on.
That is the whole arc: assess what you have, consolidate it somewhere structured, govern it so it stays that way, and only then ask Copilot to do real work. For an organization of this size, that sequence is the difference between owning Microsoft 365 and running it.