Migration

Getting onto it without a big-bang cutover

The migration people brace for is a flag day: one evening, every permission replaced, and a queue of locked-out engineers in the morning. This is not that. The access your team holds today stays exactly where it is until you decide, group by group, to move it.

Day one: stand it up

Install it in your environment, connect the first directory, and point it at a couple of throwaway test groups. Then hammer it: request a package, watch the membership land, watch it expire on schedule, watch the removal land. Do that until it is boring.

This is a day of work, at most, and it is worth being deliberate about the boring part. The half of this product that matters is the removal path, so the thing to satisfy yourself about on day one is not that grants arrive — it is that they leave, on time, without anyone doing anything.

The escape hatch: map today's groups to legacy packages

Before you model anything new, take the groups you have and wrap each one in a package that grants exactly what that group grants today. Nothing is scoped down. Nothing is improved. It is a mirror.

That mirror is the single most useful thing in the whole migration, because it is an emergency lever. If someone hits a wall — something you did not know that group was used for, at the worst possible moment — they request the legacy package and they are back exactly where they were, in seconds, without a ticket to you and without anyone reversing the migration. The difference is that this time the access expires on its own and is written down.

Two things fall out of that:

• Nobody can be blocked by your migration. The worst case is a person taking the old access for four hours. That is a dramatically better worst case than the one everybody is quietly afraid of, and it is what lets you move without negotiating with every stakeholder first.
• Some applications never need more than this. There is always a set of systems too small, too legacy or too close to retirement to be worth re-modeling. Leave them as legacy packages. They are now time-bound and audited, which is most of the benefit, and you retire them next year instead of designing around them this year.

Budget a couple of days. Almost none of it is engineering — it is deciding which groups map to what, and getting the first team to agree.

One 30-minute session with the first group

That is the training budget, and it covers two things:

1. What changes today. Your access now comes from a package, it expires, and here is the legacy package if anything is missing. Nobody loses anything.
2. Where this goes. Over the next few weeks we replace that mirror with scoped packages: a read-only one that covers most of the job and is approved instantly, and narrower ones for the things that write.

Then let them use it. The feedback from a real team in a real week is what tells you where the scoped packages actually need to sit — which is a better input than any amount of modeling in advance, because the gap between what a role is documented to do and what it does on a Tuesday is where every access model goes wrong.

While they test, stage the rest

The first group's week is not idle time for you. That is when you work through the remaining groups: what each one grants, who is actually in it, and which of them are three groups pretending to be one. Then they move over one at a time.

The part that doubles as an access review

To model a group as a package you have to look at what that group actually grants, and who is actually in it. That is the same work an access review is, done with the same care, and it leaves the same artefact: a written record of what each group confers and a decision, per person, about whether they should still have it.

Teams routinely discover during this that a group grants more than anyone believed, or that a third of its members left the team two reorganisations ago. That is not a migration problem — it is the finding the review was supposed to produce, arriving as a side effect of work you were doing anyway. See what access creep is for why it accumulates in the first place, and why the annual review does not stop it.

What actually happens by the third group

You stop pushing. Somewhere around the third team, other teams start asking when their turn is — and it is worth understanding why, because it is not enthusiasm for governance.

It is the read-only package. Most engineers have quietly accepted a small daily tax: they cannot see the thing they need to see, so they ask someone, or file a ticket, or just guess. An auto-approved read-only package removes that tax on day one, and it is the first time a security control has ever made their afternoon shorter. Word of that travels faster than any internal announcement you could write.

Where it ends up

The end state is scoped, targeted packages: a read-only tier covering the bulk of the work with nothing in its way, narrower packages for the writes, and approvals concentrated where a second pair of eyes is worth something. No standing access, and an audit trail that answers "who could have done this, and when" as a query. Our story describes what that looked like when we ran it, including the 90% number that surprised us.

There is no fixed edge to this, either. Because it works on groups and roles — the primitive every system with an API already exposes — the same machinery extends to whatever you connect next, including the systems nobody has thought to govern yet. We are still finding new places to point it.

What we help with

We have run this migration ourselves, several times, and we will help you plan yours: the group mapping, the shape of the tiers, and which systems to leave as legacy packages until they retire. Every piece of advice above is something we learned by doing it — including the parts we got wrong the first time, which is where the escape hatch came from.