Identity and access migration: finding the access nobody listed

Moving identity is the least reversible project a small business will undertake. Mail can run in two places for a month. Files can be copied twice. But once devices have re-enrolled and people have registered new second factors, going back is not a rollback.

It is a second migration performed by an exhausted team. Decide everything that is hard to undo before the point of no return, and keep the old system alive long after you think you need it. A directory export lists only part of what people can do, so the first job is to find the rest.

What to take away

The point of no return is device enrollment, not cutover day. Make the irreversible decisions before it.
Second-factor registrations do not move. The week everyone re-enrols is the week to be most careful.
Keep the old system's logs and one emergency account long after you stop using it.
Access held outside the directory is found by asking its owners, not by exporting a list.

Seven places where access hides

Seven places hold access that a directory export will not show, and each fails in its own way. Find them before cutover, because after device enrollment the way back is gone.

The identifier. If people sign in with an email address and that address changes, every saved credential, every service using it as a login, and every recovery route now points at something that no longer exists. Decide early whether identifiers are changing, because that answer determines the size of the whole project. Keeping the old address as a working alias buys you a great deal of calm.

What breaks in migration

Identifier changes break saved credentials
Second factors do not transfer
Old sessions keep working until ended
Group nesting lost in flat import
App permissions live outside directory

Second factors. Registrations are held by the system that issued them and do not transfer. Everyone re-enrols. Printed recovery codes from the old system stop working, so they have to be reissued and the old ones destroyed, and somebody has to track who has done it.

Sessions on devices. People stay signed in on machines you are not thinking about: a phone, a home laptop, a tablet in a van. Those sessions keep working against the old system until they are explicitly ended, which means the old world stays alive in places nobody is watching.

Group membership. Groups rarely map cleanly. Nesting is where it goes wrong, since a person's effective access can come from three levels up and a flat import loses it. Export effective membership rather than group definitions, because the two are different documents and only one of them is what people actually have.

Permissions held inside applications. A great deal of real access is not in the directory at all. It is an administrator flag inside the accounting package, a role inside the customer system, an approver setting in the payment tool. Changing the login does not move any of it, and each one has a different owner who has to be asked.

Service accounts, keys and integrations. These authenticate against the old system, they have no human to notice, and they fail quietly. Some fail at cutover, some fail when the old system is switched off months later, which is worse because by then nobody connects the two events. The features that remove a decision cover how to keep them visible.

Conditional rules. Policies do not port. They are rebuilt by hand and, critically, they are rebuilt without the history of why each exception exists. Export the old set as text before you start and keep it, because that document is the only record of decisions nobody wrote down.

For configuration discipline in general, the United States National Institute of Standards and Technology's Guide for Security-Focused Configuration Management provides guidelines for organizations responsible for managing and administering the security of federal information systems.

The audit trail. It splits. Everything before the cutover is in a system you are about to stop paying for, and the questions arrive later than the migration does. The incident capabilities a small business needs depend on those records.

Where to look and who to ask

Where it hides	How to find it	Who to ask
Identifier	List every application that uses the address as a login	Each application's owner
Second factors	List who holds a registration and who holds printed codes	Each person, through one tracker
Device sessions	Ask what each person signs in on, including home and mobile	The person, not the directory
Nested groups	Export effective membership rather than group definitions	Whoever administers the directory
In-app permissions	Open each application's own admin screen	The owner of that application
Service accounts and keys	Find what authenticates without a person present	Whoever set up each integration
Conditional rules and audit trail	Export the old rules as text and note the log retention	The current administrator

Work through it in this order

Decide the identifier.Whether addresses change, and what aliases carry forward. Everything else depends on this.
Build the inventory.Every application, its owner, whether it uses the directory, and where its internal permissions live. This is the same list an access review produces, which is why running one first pays for itself twice over. The method is in identity and access reviews.
Stand up emergency access on the new system and test it.Before anything depends on the new system, prove you can get into it when the normal path fails.
Rebuild policies in monitoring or report-only mode, and read what they would have blocked.
Pilot with people who are technically comfortable and who do not handle money.Fix what they find.
Migrate by department, leaving finance and administrators for a deliberate slot of their own, neither first nor last.
Re-enroll devices last within each group, because that is the step that removes your way back.
Dual-run the leaver processuntil you have watched it work end to end on a real departure.

What to keep alive until the inventory is closed

Resist closing these early. Each one is the only copy of something you will be asked about.

The old system's audit and sign-in logs, at least as long as you would want them on the new one. The question you get asked is usually about a date before the move.
An emergency administrator on the old system, until someone other than its author has tested the new emergency path.
Old accounts, disabled rather than deleted, until files, ownerships and integrations have been reassigned. Deletion destroys data and evidence, and often silently breaks a job.
The exported list of old policies and exceptions, until the new set has survived a quarter.
The written leaver runbook, until the automation has been proven on a real departure.

The re-enrollment window is the risky part

For a week or two, every person in the business has been told to expect an unfamiliar sign-in prompt and to approve it. That is the opposite of the habit you spend the rest of the year building.

Re-enrollment window checklist

Announce exact dates via non-email channel
State what you will and won't ask
Move people to stronger methods
Give one named person to check with
Keep payment verification rule untouched
Watch new sign-in log for locations

Announce the exact dates in advance, through a channel that is not email: a meeting, a printed note, a message in whatever chat tool you use. Say plainly what you will ask for and what you will never ask for.

Re-enrollment is also the one moment when moving people onto a stronger method costs nothing extra. The Cybersecurity and Infrastructure Security Agency's More than a Password page says multifactor authentication can make you much more secure. Give people one named person to check with, and make checking normal rather than an interruption.

Then keep the payment verification rule untouched throughout, and say so in the same announcement. Everything else is changing, so the one thing that must visibly not change is how money moves.

The reasoning behind that rule is in business email compromise, and the mail side of a move has its own freeze and cutover order.

Watch the new system's sign-in log during the window, because unfamiliar locations are the one signal that still means something while everything else is unusual.

After the cutover

Do the following while people still remember what they changed. Confirm every person has two registered strong methods, not one. Reissue and record recovery codes.

Review effective group membership against the four lists you would use for an access review, since this is when mappings are most likely to be wrong.

After cutover actions

Confirm two strong methods per person
Reissue and record recovery codes
Review effective group membership
Find integrations still pointing old
Plan shutdown with date and owner
Treat first leaver as timed test

Find the service accounts and integrations that broke and, more importantly, the ones that did not break because they are still pointing at the old system. Check what the old system is still accepting. Then, and only then, plan its shutdown, with a date and an owner.

Treat the first month's leaver as a test rather than a routine event, and time it, using the measure described in identity and access alternatives.

Common questions

Can we migrate everything in one weekend?

Technically sometimes, sensibly almost never. The constraint is not the data, it is the applications with their own internal permissions and the people who own them, and those owners are not available on a Saturday.

A staged migration is slower and finishes; a big-bang cutover ends with a long tail nobody is tracking.

When is rollback still possible?

Until devices re-enroll and second factors are re-registered. After that, going back means doing the same work again in the other direction. Put the go or no-go decision immediately before that step, and give somebody the authority to use it.

Should we tighten policies during the migration?

No. Move first, tighten after, and change one thing at a time so that when something breaks you know which change caused it. Combining a migration with a hardening project produces a fault you cannot attribute.

Who should own the migration?

One named person, with a second named person owning the controls that must keep working during it. The first will be busy and the second must not be. If the same person holds both, the second job is the one that will not get done.