Where identity debt hides in a migration

Every Data Center to Cloud move is also an identity migration, whether or not anyone planned it that way. The estate you are moving has been accumulating permissions for as long as it has existed, and the move is the first time anyone has to write down what those permissions actually are.

That is not a reason to avoid the migration. It is a reason to treat the identity work as its own workstream with its own owner, rather than as a task that falls to whoever is doing the cutover on the day. What follows is where the debt usually surfaces, in roughly the order a project meets it.

1. Accounts that belong to people who left

The first inventory is always longer than expected. A Data Center instance that has run for eight years holds accounts from contractors, from an acquisition, from a pilot that never wound down, and from integrations that were set up by someone who has since moved teams.

Nine in ten organizations had a successful identity-related breach in the last twelve months, according to the Palo Alto Networks 2026 Identity Security Landscape, which surveyed 2,930 respondents. Dormant accounts are a large part of why. They hold real permissions, nobody watches them, and they survive exactly the kind of reorganization that makes them invisible.

The migration forces the question because you are billed per user on the destination. That commercial pressure is useful. It is the one moment when finance and security want the same thing.

2. Service accounts nobody can name an owner for

Human accounts are the easy half. The harder half is the accounts that authenticate as a human but are not one: integration users, scripted admins, the account that runs the nightly sync, the token that a monitoring tool has been using since before the current team arrived.

The ratio has moved fast. There are now 109 machine identities per human in the enterprise, up from 45 to 1 two years earlier, and seventy-nine of those 109 are agents (Palo Alto Networks, 2026 Identity Security Landscape, 2,930 respondents). Meanwhile 92 percent of security leaders say they lack full visibility into the machine identities already running in their environment (2026 CISO AI Risk Report, 235 large-enterprise leaders).

In a migration, an unowned service account produces a specific failure: the integration breaks at cutover, nobody knows what it did, and the fastest fix is to grant the replacement account broad permissions so the thing starts working again. That is how a migration ends with more privilege than it started with.

3. Groups that outlived their project

Groups are created for a reason and almost never retired for one. A regulated healthcare organization we worked with had groups named for a system that had been decommissioned two years earlier, still carrying members, still granting access through a permission scheme nobody had opened since.

Group sprawl matters at migration time because groups are usually how permission schemes are expressed. If the groups are wrong, the schemes you carry across are wrong, and you have re-created the problem in a place that is harder to unpick because it is now also live.

4. Permission schemes that encode an argument

Open a mature Jira instance and you will find permission schemes that differ in one line from each other. The difference usually records a disagreement between two teams that was settled by giving each of them their own scheme.

Only 16 percent of security leaders say they govern access to their core platforms effectively; the rest are managing it by exception (2026 CISO AI Risk Report, 235 large-enterprise leaders). Scheme proliferation is what managing by exception looks like after a few years.

The migration decision here is not technical. It is whether you are willing to standardize, which means telling some teams that their exception is going away. Projects that duck that decision carry every scheme across and then discover that Cloud makes them harder to maintain, not easier.

5. Nested groups that hide their real membership

A group inside a group inside a group is legible to a directory and illegible to a person. The effective membership of a nested structure is rarely what anyone intended, and it is almost never what the access review assumed.

This surfaces in migration when the directory mapping runs and a group that was supposed to have forty members turns out to have four hundred. The temptation is to fix the number and move on. The better move is to flatten the structure so that the next person to look at it can answer the question without running a query.

6. Admin rights granted for a Tuesday

Someone needed to change a workflow, the change was urgent, and the fastest path was to grant site admin for the afternoon. The afternoon ended; the grant did not.

Eighty-one percent of security leaders worry about excessive access held by non-human identities (Okta Global CISO Insights, 2026), and the human equivalent is just as common and easier to find. A migration surfaces it because the destination makes admin a more consequential role than it was on Data Center, where a lot of teams treated it as a convenience.

7. External collaborators with internal access

Contractors, agency partners, and customers in a service desk all end up somewhere in the identity model. On Data Center they were often handled by a local account because it was quicker than doing it properly.

Cloud changes the economics of that shortcut. External users are a different licensing and security posture, and the migration is when you have to decide which of those local accounts becomes a governed external identity and which one should never have existed.

8. Tokens and keys held outside the directory

API tokens, personal access tokens, and app passwords sit outside most access reviews because they are not accounts. They still authenticate, they still carry the permissions of whoever created them, and they usually outlive that person's need for them.

This is the category most likely to break silently after a migration and most likely to be fixed with a broad grant. Inventorying tokens before the move, and deciding which ones become properly provisioned service identities, removes a whole class of cutover surprises.

9. Agents that inherit whatever the humans had

The newest category, and the one growing fastest. Rovo now has more than five million monthly active users (Atlassian Q2 FY26 shareholder letter), which means agent capability is table stakes and governance is the differentiator.

Only 23 percent of organizations report having an identity strategy that covers agents at all, and only 18 percent of security leaders are confident their identity management can handle agent identities (Cloud Security Alliance and Strata, 2026). In practice an agent gets access because a person granted it, which means the agent inherits that person's accumulated permissions rather than a scope designed for it.

If you are migrating now, this is the cheapest moment you will ever have to give agents their own identity model, because you are already rebuilding the identity model for everything else.

What to do about it

The pattern across all nine is the same. Each one is cheap to fix while it is still an identity problem and expensive to fix once it has become a migration incident, an audit finding, or an agent doing something nobody authorized.

The practical sequence is to inventory before you plan, decide standardization before you build, and map identities before you cut over. Treat the access review as a deliverable of the migration rather than something the security team does afterward, and the destination is a platform someone owns rather than the same estate at a new address.