Every chapter in Part I has produced a decision: what to gather, what the facts weigh, what destination they point to, how to defend it, what it costs. This chapter is where Part I closes, and it closes on the decision most projects skip because it does not look like one:
Which rules will the destination enforce, and who owns each of them on the day the first wave lands?
Skip it and the migration still ships governance. It ships the governance you already have, the one that grew by accident: the sharing defaults nobody chose, the sites nobody owns, the permissions nobody can explain. Copying content copies all of it, and the new platform's better controls arrive configured by your old habits.
A rule is a sentence with an owner
Write governance as rules, one claim per rule, before any content moves. Not a policy document; a list of sentences that can each be checked against evidence:
| The sentence | What checking it needs |
|---|---|
| Every site has at least two owners, and one is a person | the owner list, with groups counted as a floor, not a number |
| The default sharing link is not the Anyone link | the site's default, read per site, never from a bulk enumeration |
| The default link hands out reading, not writing | the default link permission, the second default beside the first |
| A classification means a control, not a word | the label behind the string, where only a string exists |
| A library the platform cannot manage is known before it moves | the item and unique-scope counts against the documented limits |
Each row is a rule somebody can own, evidence somebody can collect, and a check that can run again next quarter. The right-hand column is the part that makes it governance rather than aspiration: a rule nobody can check against evidence is a preference, and preferences do not survive contact with a deadline.
The basis of a rule decides how hard you can push it
Not every rule in your list carries the same authority, and pretending otherwise is how governance documents lose their readers. Sort your rules into three piles:
- Documented limits. The platform stops working past this point, whoever disagrees. A library past 100,000 items where inheritance can no longer be broken is not a policy debate; the number is on Microsoft's own limits page.
- Documented guidance. Microsoft writes the recommendation in plain words and permits the alternative. The default sharing link type is the canonical example: the page exists to tell you to set it to something more restrictive.
- Your conventions. Two owners per site. Ninety percent of quota. A year of inactivity. These are yours: defensible, written down with their reasons, and honestly labelled as choices. A convention wearing the costume of a vendor requirement is the fastest way to lose the argument you will eventually have about it.
The pile a rule sits in decides its enforcement conversation. A documented limit needs no meeting. Documented guidance needs one meeting, with the page open. A convention needs an owner willing to defend the reason, which is why every convention in your list must carry one.
Decide the target state, not the cleanup
The instinct is to clean the source before moving: fix the owners, retire the stale sites, unpick the permissions. Some of that is worth doing, and Chapter 13 tells you which parts change the plan. But the governance decision is about the destination:
- What does a compliant site look like there? Owners, label, sharing posture, storage expectations, written as the rule list above.
- What happens to a site that cannot comply? It still has to go somewhere: an archive, an exception list with an expiry date, a wave of its own. "We will fix it later" is not a state; it is the current estate's origin story.
- Who says yes? Every rule needs the person who can grant an exception, because exceptions will be requested in week one. A rule whose exceptions nobody can grant gets ignored; one whose exceptions anybody can grant is not a rule.
We recommend deciding this as a table of target states before the first wave, for one reason from the field: the first wave sets the precedent. Whatever lands in week one, in whatever state, becomes the answer to "but you let them do it" for the rest of the project.
Enforcement is collection, on a schedule
A rule list enforced by memory decays in a quarter. The enforcement that survives is the one that reuses the machinery you already built in this Part: the same evidence collection that measured the estate, run again, against the rules, on a calendar.
This is the discipline the governance engine this guide crosses was built around, and the principle holds with or without that tool: evidence is collected read-only, the rule judges the evidence, and the finding names the rule version and the collection moment. What it buys you in a migration is specific: when a stakeholder asks in month three why their site was flagged, the answer is a rule with a written basis and a dated reading, not a recollection.
Two honesty requirements carry over from the measurement chapters, because they are where enforcement quietly rots:
- Unknown is an answer. A site whose evidence could not be read is not compliant and not violating; it is unread, and the report must say so. The alternative is the confident wrong answer, and a governance report that guesses is worse than none.
- A bound is not a count. "At least 6,100 scopes" fails a 5,000 recommendation and says nothing about a 50,000 ceiling. Enforcement that rounds bounds into numbers will eventually approve something the platform refuses.
When governance-first misleads
The failure mode of this chapter is governance as a gate that nothing can pass. A rule list written by the most cautious person in the room, applied retroactively to an estate that grew for a decade without it, flags everything and therefore prioritises nothing. If more than a quarter of the estate fails a rule, that rule is not describing an exception; it is describing your organisation, and its remediation belongs in the plan as a workstream, not in the wave gate as a blocker.
The other failure is symmetrical: adopting the destination's defaults as governance because they arrived pre-configured. Defaults are somebody's general answer. Chapter 4 said a recommendation should survive a product update; governance adopted from defaults changes whenever the vendor's defaults do, which means it was never yours.
Out of scope
Records management, retention policies and eDiscovery are governance, and they are not this chapter: they need their own owners and usually their own project. Identity governance beyond site ownership, conditional access and device posture belong to the identity workstream. This chapter is the governance a migration cannot proceed without; it is deliberately not everything the word can mean.
Before you continue
- Governance is written as rules: one sentence, one owner, one evidence check each
- Every rule is sorted by its basis: documented limit, documented guidance, or your convention with its reason written down
- The target state of a compliant site is defined, and so is what happens to a site that cannot comply
- Every rule has the person who can grant its exception, by name
- Enforcement is scheduled collection against the rules, not memory
- Unknown is reported as unknown, and bounds are reported as bounds
- No rule flags more than it prioritises; what most of the estate fails is a workstream, not a gate
Download chapter 6 (PDF)Same text, same tables, same sources as this page.