There is a phrase that appears in nearly every migration plan I have read in the last decade. It says, in some variant: "identity will be addressed in a later phase." Sometimes the phrase is honest and sometimes it is hopeful, but the consequence is the same. By the time the later phase arrives, the architecture has been built around assumptions that identity should have been making, the access patterns have set, and what was supposed to be a redesign becomes an exercise in retrofitting. The window in which identity is cheap to get right has already closed.
This is the part that experience teaches and reference architectures rarely emphasise. Identity is not a control you bolt on at the end. It is the boundary that everything else is implicitly drawn around — whether you treated it that way or not. The choice is not whether identity will be the architecture; it will be, by default, the day after cutover. The choice is whether you designed it that way deliberately, or inherited a version of it shaped by whatever was easiest at the time.
Look at the two pictures. Same workloads, same data, same operations function — but in the left-hand version, the implicit boundary is the network. The perimeter is the line you defend, identity is something you tack on once the boxes are in place, and trust flows from "is this packet inside the wall" rather than "is this actor allowed here." In the right-hand version, identity is the boundary, and everything — network segmentation, data access, audit, operations — is arranged around what it permits. The components are the same. The architecture is profoundly different.
The reason the left-hand version remains so common is not ignorance. It is sequencing pressure. A migration has dates, and identity work is slow — every legacy system carries inherited assumptions about who-can-do-what, every business function has hidden integrations, every directory has groups whose original purpose nobody remembers. Putting identity first means slowing the migration down to interrogate things that look settled. Most programmes cannot bear that, so identity gets deferred, and the architecture is shaped by what was easier to defer.
Why the addendum is never the same shape
The intuition many teams hold is that identity can be retrofitted later — same destination, different sequencing. In practice it cannot, and the reason is worth being precise about. When identity is designed first, every downstream decision is made in its light. Network segmentation is drawn to reinforce who-can-talk-to-whom. Data access is granted to roles that already mean something. Audit trails capture identity context naturally, because the identity context existed before the audit logging was specified.
When identity is designed last, all those decisions were already made — and they were made on whichever proxy was available at the time. Maybe network location stood in for identity. Maybe a service account did, because service accounts were the path of least resistance. Maybe a shared credential because somebody needed it and the meeting was running long. By the time the proper identity layer arrives, it has to map onto a world that has already learned to live without it, and the map is full of edge cases. Each edge case is a place where the new model has to make an exception, and exceptions are how identity architectures decay.
Identity designed first is a few opinionated decisions that shape years of behaviour. Identity designed last is a series of negotiations with what other people already did.
What it actually determines
The other reason identity-as-addendum keeps happening is that the cost of getting it wrong is genuinely invisible during the migration. Everything works. Workloads run. Users can log in. The platform looks correct in every demo. The trouble is that what identity quietly determines is not whether things work at cutover but what shape the system has when stress arrives later.
The cascade is what makes identity load-bearing. The identity decision tells you how to draw network segmentation — because segments only mean something if you know who the actors are. It tells you how to grant data access, because data access policies need roles that survive longer than a project. It tells you what your audit can answer, because audit logs are only useful when they tie an action to a person rather than to a session token nobody can trace. And taken together, those three determine whether year two is calm or whether it is a rolling sequence of access reviews that should have been one design decision two years earlier.
A useful exercise: take any frustration with a platform that is more than eighteen months old — a slow access review, an audit finding, a service that broke because a credential rotated, a team that cannot debug their own application because they cannot see the logs. Walk it backwards through the chain. In almost every case, it terminates at an identity decision that was never deliberately made.
What "first" actually means
Saying identity must come first is easy. Doing it is the part that takes discipline, because "first" is not a calendar instruction; it is a sequencing one. It means that before the first workload moves, you have answered a small set of questions and answered them deliberately. What is the source of truth for who a person is, and is it one source or several? How are non-human identities — services, automation, devices — modelled, and are they first-class or are they assumed away? What is the unit of access — a role, an attribute, a group, a project — and which of those is allowed to be created without architectural approval? How does identity from acquisitions, partners, and outsourced operations enter the system, and what happens to it when they leave?
None of these questions are exotic. They are the questions identity architects have been asking for twenty years. What is different about treating identity as the architecture is that you refuse to start the migration until they are answered, in writing, with the people who would otherwise spend two years working around the absence of those answers. That refusal is uncomfortable for programme leadership. It is often one of the highest-leverage decisions a migration makes.
The framing I find useful is this. Every architecture has an implicit boundary — the line everything else is drawn relative to. For a long time that boundary was the network perimeter, and the discipline was to harden it. As workloads moved to environments where the perimeter dissolved across cloud and partner and edge, the boundary moved with them. The boundary is identity now. It has been for years. The organisations that operate calmly are the ones that admitted this and designed accordingly. The ones still in pain are mostly still pretending the boundary is somewhere else.
Identity is not the addendum to your architecture. It is the architecture. The only question worth answering is whether you intend to design it on purpose, or accept the version that emerges by default. The two are never the same shape, and the difference shows up exactly when the system is under the most stress to be different.