A client deployed a full security-role redesign as a production cutover without the shipped configuration ever going through a user acceptance testing pass. The first business day of live use went by with nothing reported to us. That is worth examining, but not for the reason you might expect, because a quiet first day proves less than it looks like it does.
Most security redesigns are deployed the careful way: stage the new roles in a test environment, run a user acceptance testing (UAT) pass, watch for breakage, then promote to production weeks later. It is slow, and it is sensible, because getting security wrong means someone cannot do their job on Monday morning.
So it is worth paying attention when a client does not do that and nothing breaks. On a recent engagement with a smaller estate, fewer than a hundred licensed users, the client deployed a roughly seventy-role redesign straight to production as a single cutover. We want to be precise about what "no UAT" means here, because it is more specific than it sounds. There was a test environment. It just held an earlier, superseded version of the design, not the package that shipped. The configuration that actually went live had never been through a functional UAT pass of its own. By any normal standard, that is a bold way to deploy. The first business day of live use went by with nothing reported to us.
Before anyone reads too much into that, two caveats. First, a few hours of one quiet business day is an early signal, not a proven outcome, and it is our own observation rather than a long-run result. Second, and more importantly, a quiet first day was the expected result here. It does not mean what people usually assume it means.
Why the quiet day was expected, and what it does not prove
Here is the honest core of this story. The redesign shipped as an additive change. It added the new, cleaner role structure, and it removed nothing. On day one, not a single user lost access they had, and not a single user's license tier changed. The redesign was cost neutral at cutover: the same bill before and after, because nothing had been taken away yet.
Now think about what a quiet first day can and cannot tell you. The classic way a security change breaks people is that it revokes something a person quietly needed, and their work stops. If the cutover removes nothing, that failure mode is off the table on day one, no matter how good or bad the new structure is. A perfectly fitted design and a sloppy one would both produce an identical quiet first day, because in both cases the old access is still sitting underneath the new roles. So the quiet day proves exactly one thing: that the additive cutover was safe, as it was built to be. It does not prove that the new, evidence-fitted structure is correct. That proof comes later, and it is a different test.
This is the part that makes a straight-to-production cutover defensible rather than reckless. The deployment was engineered so that the worst case on day one was "no change anyone can feel," not "someone is locked out." Where the shipped roles did not cover some access a user already held, that access was deliberately left in place through their original roles rather than stripped, tens of thousands of existing privilege grants kept exactly that way. A strict check confirmed the restriction rules shipped to precisely the right people: everyone who should have gained a restriction did, nobody who should not have did, and nothing anyone held was silently lost. The only access granted to people who did not already have it went to a few named users, each signed off in advance.
The evidence behind the structure, and the window it did not see
A cutover that removes nothing is safe, but it is only worth doing if the new structure is actually right. That is what the method is for, and it is why we judged the cutover low risk.
Every access decision in the redesign was built from two independent streams of real evidence, not from job titles:
- - Telemetry: which screens and entry points each person actually opened, over a usage window.
- - The audit log: which records each person actually created or changed, mapped back to the privileges that allow those actions.
Together, per user, these describe what a person demonstrably does rather than what their role nominally permits, and the design is fitted to that.
Two things keep this honest, and the article would be overclaiming without them. The first is the window. The usage window here was short, about two weeks, and it did not include a month-end. Month-end is exactly when periodic work surfaces, the closing tasks and run-once jobs people touch a few times a year, so a short window that misses it has not seen everything. The second is the rule for what the window cannot see. Not every privilege is even observable: on the Dynamics 365 platform, write-evidence can see roughly 89% of screens, about 22% of report outputs, around 7% of in-page actions, and none of the in-form controls. That split is a property of the platform, close to constant across estates. For anything the evidence cannot prove is unused, the rule is strict: a privilege you cannot prove is unused is never removed on a guess. It is kept, and flagged for a human.
Put those two together and you see why the cutover was additive on purpose. The design does not assume the window saw everything, so it does not strip access based on a short, partial record. It installs the right structure and keeps what it is unsure about. The thin window is not a hole in the story. It is the reason the deployment was sequenced the way it was.
Where the real test, and the savings, actually are
If the cutover removes nothing, where is the payoff, and where is the real validation of the fit? Both come next, and this is the careful part by design.
The excess access, the privileges the evidence says nobody is using, is removed after the cutover, in separate, signed-off revocation steps, not in a blind flip. Each tranche is reviewed, approved, applied where the evidence and the client agree, and is reversible. This is the step that actually tests whether the fitted structure was right, because it is the first time access is taken away. A quiet cutover tells you the additive change was safe; revocation tranches that run without stopping anyone's work are what tell you the fit was good.
And things do get caught at that stage, which is the honest part. When the first removals were applied, a handful of privilege grants that had shown some recorded use were taken out across a few users, and one of those was explicitly flagged to re-enable if it turned out to still be needed. That is not a failure of the method. It is the method working: the risky act, taking access away, is done slowly, with a name attached and an undo, precisely because the evidence is a floor and not the whole truth. That is also why the short window does not sink the design. The window informs the structure; the staged, reversible revocation is where anything the window missed gets caught before it bites.
What this actually means
The usual framing is careful versus fast: run a long UAT and deploy slowly, or move fast and gamble. This engagement shows that is a false choice when the build is right. You can be bold where it is safe, installing a clean, evidence-fitted structure that takes nothing away, and careful where it counts, removing access only in reviewed, reversible steps. The combination of telemetry and the audit log is what makes the structure close enough to reality to be worth shipping, and the additive sequencing is what makes shipping it, even straight to production, something other than a gamble.
A blind production cutover that passes its first day quietly is not a stunt, and it is not proof that a design is perfect. It is what it looks like when the one thing you do without a safety net is the one thing that cannot hurt anyone, and everything that can hurt someone is done slowly, with the evidence in front of you and an undo in reach.
Frequently asked questions
Are you recommending everyone ship a build that never had its own UAT pass?
No. We would still run a UAT pass of the shipped build by default, and this engagement still owed a few checks afterward, such as confirming a couple of removed operator tasks really were unused. The narrower, more useful point is this: when a redesign is built additively from real usage evidence, a cutover does not carry the risk people assume, because it cannot remove anyone's access on day one. That is what made going straight to production a call we judged reasonable here rather than a gamble.
If the cutover saved nothing, what was the point?
The cutover installs the correct structure safely. The savings, and the real validation that the structure fits, both come from the revocation steps that follow, done in reviewed, reversible tranches. Separating the two is deliberate: prove the structure runs, then remove the excess with a human sign-off, rather than doing both blindly at once.
How do you know the configuration was close to what people need?
It was fitted to two independent records of what people actually did, their telemetry and their audit trail, rather than to their job titles, and anything the evidence could not observe was kept rather than cut. The usage window was short and did not cover a month-end, which is exactly why the design keeps what it cannot see and why the removals are staged and reversible. The quiet first day is an early, encouraging sign about the safety of the cutover; the revocation tranches running clean are what will actually confirm the fit.