Most of what a full license analysis catches was never actually about usage. Grant/deny conflicts, a single privilege quietly requiring more than one license tier, a user holding both a system-administrator role and an ordinary business role at the same time, all of these are visible the moment a security configuration exists. Not after a telemetry window closes. Not once an audit log has enough history to trust. The moment the roles, duties, and privileges are assigned, the question "is this internally consistent" already has an answer. That means it doesn't have to wait for go-live, and it doesn't have to wait for the redesign to be finished, either.
What this kind of check is actually looking for
Three patterns carry most of the weight. The first is a grant/deny conflict: one privilege in a role grants an entry point, another privilege in the same role denies it, and Deny correctly wins from a security standpoint, but license tier gets calculated from the highest permission granted anywhere in the role, even the one being actively suppressed. We've written about this one in detail in a companion piece, so we won't re-explain the mechanics here, only note that it's a pure configuration fact. No usage evidence changes whether the conflict exists.
The second is a privilege that pulls in more than one license tier's worth of requirement at once, usually because two unrelated entry points got bundled into it at some point and nobody separated them back out. The third is a user assigned both a system-administrator role and a day-to-day business role simultaneously, which is a real access-hygiene problem on its own, wide open admin rights sitting on an account that's also doing routine transactional work, and a real cost problem too, since the license requirement gets set by the more expensive of the two regardless of which one the person actually uses. All three are readable straight off the security configuration. None of them need a single row of telemetry.
Why this matters most while remediation is still underway
A redesign doesn't arrive finished. It goes through rounds, batches, corrections, the kind of process described in a companion case study on what phased delivery actually costs. Every one of those rounds is a fresh opportunity to reintroduce exactly the kind of conflict the redesign was supposed to remove. A duty gets cloned from an old role and brings a stale Deny with it. A quick fix to unblock one team quietly re-grants something a Deny elsewhere was suppressing. Nobody does this carelessly, it's the ordinary friction of iterating on a live security model under real deadlines. The question is only ever when you find out about it.
Found two days after a batch ships, it's a conversation: here's what crept back in, here's the one duty to adjust. Found after go-live, once real users are already relying on the roles as delivered, it's a support ticket, a re-open, and a user whose access just changed underneath them without warning. Same underlying issue, wildly different cost, and the only variable that changed is how long it sat unchecked.
Why it can be light
A full license analysis leans on usage evidence throughout, telemetry for what got opened, audit logs for what got written to, both joined against the security configuration to decide what's safe to trim. None of that machinery is needed for the three checks above, because they were never asking "was this used." They're asking "is this configuration self-consistent," and that question is answered entirely by the roles, duties, and privileges as they exist right now. Running it doesn't mean running a smaller, hastier version of the full analysis. It means running the specific slice of the full analysis that was already structural under the hood, the part that was never waiting on usage evidence to begin with, on its own, on whatever cadence actually matches how fast the configuration is changing.
Where we first proved this out
We built this mode originally to answer a narrower question: what will a redesigned role set actually cost once it's deployed to a client's UAT or test environment, before it ever reaches production. That environment has real security configuration, real roles, real duties, real privileges, but no usage history to speak of, so the existing usage-driven pipeline had nothing to run against. Building the lighter path forced us to actually trace which parts of a full analysis were structural all along, and the answer surprised us a little: the large majority of what a client-facing analysis reports on, license cost by role, grant/deny conflicts, circular reference checks, sysadmin overlaps, was already being computed straight from configuration, with telemetry only ever feeding one narrower piece, excluding genuinely inactive users from a couple of downstream counts. Once that was clear, the light mode stopped being a special case for pre-go-live validation and became something worth running throughout remediation, any time security configuration is moving faster than usage evidence can keep up with it.
What this changes, for the client and for us
For the client, it means the redesign in progress gets a live read on whether it's trending toward the problems it was meant to fix or quietly reintroducing them, instead of a single verdict handed over at the very end when the cost of changing course is highest. For us, it means a grant/deny conflict or a sysadmin-plus-business-role overlap gets caught while it's still cheap: one flagged duty, one short conversation, done. Caught in the final report instead, it's work that was supposed to be finished getting reopened, on both sides, after everyone had already moved on to calling it done.
It's the correctly-sized tool for a question that was never about usage to begin with: is this configuration internally consistent, right now, today. The full telemetry-backed analysis still has an irreplaceable job, deciding what's genuinely unused and safe to trim, but that's a different question, answered on a different clock. Running the light check continuously and the full analysis once, at the point where usage evidence actually exists, isn't a compromise between the two. It's matching each question to the evidence it actually needs.
What we'd tell the next client
Don't wait for the redesign to be declared finished before checking it. Run the light analysis after every meaningful batch of security changes, not just once at the end, and treat what it finds as routine maintenance, not a sign anything went wrong. A conflict caught two days after it was introduced is exactly what this process is supposed to catch. That's it working, not failing.
Questions we get asked
Doesn't skipping telemetry mean missing real usage patterns?
No, because this check was never trying to catch those. Usage patterns, what's genuinely unused and safe to trim, are the full telemetry-backed analysis's job, and that job still needs real usage evidence to do well. The light check and the full analysis aren't competing versions of the same thing; they answer different questions, at different points in the engagement, and both are needed.
Why not just run the full analysis every time instead of maintaining two modes?
Because most of what the full analysis does between one check and the next is re-computing usage evidence that hasn't meaningfully changed, telemetry ingestion, audit-log sweeps, the works, for no benefit if the goal is just "did this batch reintroduce a configuration conflict." Running the full machinery for that question is real time and real Fabric compute spent answering something the light check already answers on its own.
Is this only useful before go-live?
No, that's actually where it matters least, comparatively, since production for most clients isn't changing security configuration every few days. It's during active remediation, and afterward during any period of ongoing role maintenance, that the light check earns its keep, because that's when configuration is actually moving fast enough for something to slip back in unnoticed.