The slow way to ship a Dynamics 365 security redesign is months of staging and user acceptance testing. We have now taken two very different clients live straight to production without the shipped configuration ever going through a UAT pass of its own: a smaller US manufacturer and a larger fresh-produce distributor. The surprising part is not the go-live day, which in one case was a matter of hours. It is where the real work and the real testing actually happened, which was weeks earlier, in the data collection. You do not skip the test when you do this. You move it earlier, onto real usage.
Be precise about what this proves. Neither go-live on its own proves that skipping UAT is always safe. One client had been live barely a day when we wrote this; the other never put a user on its new roles, and the structure it did put live was later found to have defects that harmed no one only because nobody was assigned to them. What the two engagements show is something narrower and more useful: when the evidence collection is done right, a go-live carries far less risk than people assume, and the risk that remains is known, bounded, and reversible.
The slow way, and why it exists
Most redesigns are deployed carefully: stage the new roles in a test environment, run a UAT pass, watch for breakage, then promote to production weeks later. That caution is earned. Getting security wrong means someone cannot do their job on Monday morning, so the instinct to test everything twice is sound. The usual framing is careful versus fast: run a long UAT and deploy slowly, or move fast and gamble. The whole point of this article is that this is a false choice when the preparation is right.
What actually took the time, and it was not the go-live
Here is the first thing that surprises people. The hands-on build of a redesign like this, fitting the roles to the evidence, settling the approvals, importing, and checking the result, is on the order of three to four focused person-days once clean data is in hand. The go-live day itself is shorter still: in the measured case, the time from final package to a released cutover was a matter of hours.
So where do the weeks go? Into the data collection that happens before any of that. The evidence window, the stretch of time over which we watch what people actually do, is the long pole, and it should be. Our target is a usage window of around sixty days that includes a month-end. That is the real duration of the project, and it is mostly waiting and watching, not building.
The effort figures here are an estimate for a well-prepared next engagement, not a guaranteed result. First-time data problems are real and have cost days at more than one client. The point is not a precise number. It is the shape: the time sits in the preparation, and the build and go-live are the short tail.
The data collection is the test you are actually running
A UAT pass asks a handful of testers to exercise a handful of scripts for a week and tells you what those testers happened to touch. Weeks of production telemetry and audit history ask every real user the same question continuously, and tell you what the whole organization actually did. That is a far stronger test of whether a role fits a person, and it is running long before go-live.
The unit of evidence is small and concrete: one privilege, held by one user, through one role. Two independent streams decide whether that privilege is really used:
- - Telemetry: whether the person actually opened the menu item that privilege unlocks, during the window.
- - The audit log: whether the person actually created or changed records in the tables those menu items write to.
Two disciplines keep this honest. The first is that most access will show no evidence of use, and that is normal: expect more than nine in ten privileges across an estate to come back with no recorded use. The second is the rule for what to do about it: remove access only where the audit log could have seen use and did not, with the client approving each removal by name. A privilege the audit log cannot observe at all is never removed on a guess. It is kept, and flagged for a human decision. This is why the length of the window, and whether it captures a month-end, matter so much: they are what turn "no evidence" into something you can safely act on.
Two estates, same method, two honest outcomes
The same method ran at two clients that could hardly be more different, and it produced two different answers on purpose. That contrast is the proof that the method is disciplined rather than optimistic.
| A smaller US manufacturer | A larger fresh-produce distributor | |
|---|---|---|
| Business users | Fewer than a hundred | Several hundred |
| Evidence window | About two weeks, no month-end | About ten days with a gap, no month-end |
| Go-live | Additive cutover, then staged revocation | Additive cutover; revocation deliberately held |
| Cost outcome | A real saving, concentrated in a single role | Held flat by choice; the window was too thin to cut responsibly |
| What it shows | Evidence can find concentrated, bankable excess | Discipline: do not claim a saving the evidence cannot carry |
Neither of these two windows reached the roughly sixty-day target with a month-end inside it, and that is precisely why, at both clients, we cut nothing the evidence could not observe and staged every removal behind a sign-off. These two engagements illustrate the discipline of the method; they are not the full sixty-day ideal run end to end, and we are careful not to claim otherwise.
At the manufacturer, the evidence pointed clearly enough that we went to a cutover and then removed excess access in separate, signed-off steps. Most of the saving turned out to be concentrated in a single role carried by a group of operators, the kind of finding a discount negotiation never surfaces. At the distributor, the window was shorter, had a gap in it, and missed a month-end. The responsible call there was not to cut cost at all yet. We shipped the cleaner structure, took nothing away, and told the client plainly that a longer extraction covering a month-end is needed before any saving can be claimed. Holding a saving we could not yet defend is not the method failing. It is the method working.
Why the go-live can be bold without being reckless
The reason a straight-to-production cutover is defensible comes down to how it is sequenced and controlled. The cutover is additive: it installs the new role structure on top of what people already have and takes nothing away on day one. That single property removes the classic failure mode, because a cutover that revokes nothing cannot lock anyone out, no matter how good or bad the new structure is.
On top of that, a short list of controls does the rest of the work:
- - The import adds only; the old roles stay in place until a separate step removes them.
- - Every assignment and restriction is checked after the import and before anything is revoked.
- - Revocation is done later, in reviewed tranches, with the client signing off row by row.
- - Revocation sets access to disabled rather than deleting it, so every removal is reversible.
- - Integration, ISV, and administrator roles are handled on their own track and confirmed by name.
- - Hypercare runs through the first month-end, and the platform's own license report is read right after the import.
The weeks of evidence collection are the real test. Get that right and the go-live is a short, controlled event, and the risk that remains is back-loaded: it lands at the first month-end, the first rare setup task, and the first role-based workflow, not on day one. That is precisely where the staged, reversible revocation and the month-end hypercare are aimed. Skimp on the preparation and no amount of go-live-day care will save you.
What "done right" actually requires
"Go live in days" is a consequence of preparation, not a shortcut around it. The preconditions are specific, and all of them are about the data:
- - Clean data first. Bad or partial extracts are where the days get lost.
- - A usage window long enough to be meaningful, ideally around sixty days, and including a month-end so periodic work is seen.
- - Two independent evidence streams, telemetry and the audit log, not job titles.
- - A firm rule to keep whatever the evidence cannot observe, rather than cut it on a guess.
- - Additive sequencing at cutover, so day one cannot hurt anyone.
- - Staged, reversible revocation with named approvals, which is where the saving and the real validation of the fit both happen.
- - Hypercare through the first month-end.
Do those, and the fast go-live is not a gamble. It is what preparation looks like when it has been done properly: 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 within reach.
Frequently asked questions
Are you saying companies do not need UAT?
No. By default we would still run a UAT pass of the shipped build, and we would recommend it. The narrower, more useful point is that most of the testing value can be captured earlier and more completely by watching real production usage for weeks, and that a cutover built additively from that evidence does not carry the day-one risk people assume. UAT becomes a confirmation step rather than the thing the whole go-live rests on.
How can the build take only a few days?
Because the slow part, the weeks of evidence collection, happens before the build starts. Once clean data is in hand, fitting the roles, settling approvals, importing, and checking is on the order of three to four focused person-days. That is an estimate for a well-prepared engagement, not a guarantee; first-time data problems can and do add days.
What if the usage window missed something a person needs?
That is exactly what the design expects, which is why nothing the evidence cannot observe is cut on a guess, why the cutover removes nothing on day one, and why real removals are staged, reversible, and watched through a month-end. Anything the window missed surfaces at the first month-end or the first rare task and is caught there, with an undo in reach, rather than locking someone out at go-live.
Did this actually save money?
At one of the two clients, yes: a real saving, concentrated in a single role. At the other, we deliberately held any cost reduction because the evidence window was too thin to support it responsibly. In both cases the saving comes from the staged revocation that follows the cutover, not from the cutover itself, and we do not publish a savings percentage until it is confirmed against the client's actual invoice rather than list prices.