> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/solution-architecture/programme/phasing-a-rollout.md). # Phasing a rollout What belongs in the first phase of an OpenIAM rollout, how to choose the applications that go in it, what to defer without leaving the phase incoherent, and how to tell whether the phase actually fini ## What this is, and when you need it A phase plan is where an identity programme is won or lost, and the mistake is nearly always the same shape: the first phase is scoped by what is *visible* rather than by what everything else depends on. The result is a programme that demonstrates well for two quarters and then spends a year discovering that its identity data was never true. This page is about what a first phase contains, which applications belong in it, and what can safely wait. It assumes the sequencing position in [Sequence: lifecycle before SSO](/solution-architecture/programme/sequence.md) has been accepted — that lifecycle comes before federation — and works out what that means for a plan. You need it when a delivery plan is being written, when an application team is lobbying to be first, or when a phase is being declared complete and you want a definition that is not "the configuration was saved". ## The decision | Way of scoping phase one | What it buys | What it costs | | -------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | **One population, end to end** (recommended) | Joiner, mover and leaver proved for a real group of people, across a real directory, with evidence. Everything later is repetition rather than discovery | Nothing users can see. The phase's output is correctness, and correctness does not demo | | **Many applications, shallow** | Breadth. A slide with a lot of logos on it | Every application is integrated against an identity model that has not been proved, so every one of them is re-worked when it is | | **One application, deep** | A complete vertical slice including governance | Only useful if the application covers the whole population; otherwise the lifecycle is proved for a subset and the subset is not representative | | **By organizational unit** | A clean communications story and one sponsor | Cuts across applications rather than along them, so shared applications end up half-integrated | **Scope phase one as one population, end to end, across one directory, with a small number of applications attached.** The phase's job is to make the identity data true for a group of real people and to prove that the leaver path works. Everything after that is scaling a proved pattern. ## What a first phase contains Seven things. A phase missing any of them is not a phase, it is a pilot with a deadline. **One authoritative source, connected and reconciled.** The feed that is allowed to say a person exists, with its correlation key proved present, unique and stable across the population it covers. This is the Part 2 work, and phase one is where it stops being a design and becomes data. **One directory, provisioned and reconciled.** Not read-only. The phase has to include writing to a real target and reconciling the result, because reconciliation is what tells you the identity model is right. A phase that only reads has proved nothing. **Joiner, mover and leaver for that population.** All three, and the mover case deliberately — a design that handles only the joiner and the leaver will not survive an estate of any size, and the transitions that break designs are the ones in the middle: a contractor becoming an employee, a transfer between units with different feeds, a seasonal worker returning. Choose a population that exercises at least one of them. **A small set of applications**, chosen by the criteria below, with their catalogue entries, approval policies and connectors. **One certification campaign, run for real.** Narrow, on the population you just onboarded. Its purpose is not coverage; it is proving that reviewers resolve, that notifications arrive, that decisions record, and that a revoke reaches the target system. Every one of those four fails somewhere the first time, and you want that to happen in phase one on a hundred people rather than in phase three on fifty thousand. **The evidence path, exercised once.** Take one access grant and follow it end to end: the request or the rule that caused it, the approval if there was one, the provisioning operation, the connector reply, the account in the target, and the audit record of each step. If any link is missing, it is missing for everything, and now is when it is cheap to fix. **A decision on the scheduled work.** Several shipped batch tasks that a design commonly assumes are running are **disabled as shipped**, including the population-wide business-rule recalculation, the revocation of end-dated access, and the approver reminder and escalation pair that certification reminders depend on. Which of them your design needs, who enables them, and what runs the first time they fire are phase-one decisions, not installation details. See Part 4, *How access gets granted*, for what each one changes. ## Choosing the first applications Five criteria, in order. The first two are non-negotiable and the rest are trade-offs. **A shipped connector, proved against a non-production instance.** An application whose integration has to be written is not a phase-one application; it is a development task with an application attached. Put it in a backlog with the connector work and let it join a later phase once the connector has run. **An owner who will accept the approval policy.** Not an owner named on a list — an owner who has agreed what the approval flow is and will answer when it routes to them. An application with no engaged owner fails at the first request and at the first campaign. **A large share of the population.** The first applications should touch most of the people you onboarded, because that is what exercises the identity model. An application used by forty specialists proves the connector and nothing else. **A simple entitlement model.** Few roles, flat structure, no nested inheritance, no local sub-administration. Complexity in phase one is complexity you debug while also debugging the identity model, and you will not know which is which. **A target you can reconcile.** You need to be able to read the application's own state back and compare it with what OpenIAM believes. Without that, a phase-one integration is an assertion. Two applications that people reach for first and should not be first: **the highest-risk system**, because the process has not been proved and the blast radius is wrong; and **the loudest application team**, because their enthusiasm is not evidence that their application is a good first case. Put the high-risk system in the second or third wave, deliberately — early enough that it matters, late enough that the process works. ## What to defer Deferring is only safe when the deferred thing does not silently change the design of what ships first. These do not. | Defer | Why it is safe to wait | What to do in phase one instead | | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------- | | **Segregation-of-duties enforcement** | Enforcement over an estate you have not measured blocks legitimate work. The measurement has to come first anyway | Encode a handful of conflicts and run them in shadow, so the backlog is known by the time enforcement is proposed | | **A full role catalogue** | Role design is analysis work that needs evidence about who currently holds what, and that evidence is a phase-one output | Ship birthright access and a small set of obvious roles; start measuring | | **Risk scoring** | It consumes catalogue quality — owners and risk ratings — that does not exist yet | Require an owner and a rating on every role created, so the input exists when you want the output | | **Complex approval routing** | Multi-step conditional routing is easy to add and hard to debug alongside everything else | One or two steps, resolved from the objects the catalogue already carries | | **Self-registration and customer identity** | A different population with different governance; it shares almost nothing with workforce lifecycle | Nothing. Keep it out of the phase entirely | | **The access gateway for legacy applications** | It is a separate architecture with its own network and security review | Federate what already speaks a federation protocol; leave the header-injection and proxy cases for a dedicated phase | | **Non-human identities** | Service and privileged accounts need their own ownership model, and attaching them to a workforce lifecycle half-designed makes both worse | Inventory them; decide their model in the phase that owns them | Two things are often deferred and should not be. **The leaver path** is not a later phase; a lifecycle that only joins people is not a lifecycle. And **the correlation key** cannot be deferred at all — every account created before it is settled becomes a re-matching task, and the cost grows with every integration. ## Knowing whether the phase finished A phase is complete when you can demonstrate five things, none of which is a screenshot of a configuration screen. | Claim | What demonstrates it | | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | The feed is authoritative and the key holds | A reconciliation of the source against OpenIAM with the exceptions explained, not just counted | | A joiner works | A real person, joined by the feed, with accounts in the target, inside the agreed time | | A mover works | A real transition — a status or unit change — with entitlements added *and* removed | | A leaver works | A real termination, with the account state confirmed in the target system rather than in OpenIAM's record of what it asked for | | Access can be evidenced | One grant traced end to end, and one campaign closed with its revokes confirmed in the target | The distinction that matters in three of those five is between what OpenIAM asked the target to do and what the target did. Confirming the second is the whole point of a first phase. ## What we recommend **Make phase one about correctness, and say so to the sponsor before it starts.** Agree in advance that its success criterion is a proved leaver, not a visible feature — otherwise the criterion will be renegotiated in month three, and it will be renegotiated downwards. **Choose a population that exercises a mutation.** Contractors, seasonal staff, or a unit that transfers people. A phase-one population of permanent employees who never move proves the easy half. **Pick applications by connector maturity and owner engagement, not by importance.** Importance decides which wave; readiness decides which phase. **Run a real campaign in phase one, however small.** It is the cheapest way to discover that the catalogue has no owners. **Decide the disabled scheduled work explicitly**, and test each task you enable against a bounded population before it runs across the estate. **Keep a written deviation list.** Applications federated ahead of their lifecycle, entitlements granted by hand because the mechanism was not ready, populations out of scope. The list is short in phase one and it is the honest answer to what the phase did not cover. The circumstance that changes this advice is a hard external deadline — a divestment, a decommissioning, a regulatory date. There the phase is scoped by the deadline rather than by the design, and the right response is to reduce the *population* rather than the phase's contents: fewer people, still end to end, still with a proved leaver. A phase that drops the leaver path to hit a date has not hit the date; it has moved the work into an incident. ## What OpenIAM does not do here * **Several shipped batch tasks that designs assume are running ship disabled**, including the population-wide business-rule recalculation, the revocation of end-dated access, and the approver reminder and escalation pair. Nothing warns you that a control is inert. * **There is no phase or rollout state in the product.** OpenIAM does not know that an application is in scope, out of scope, or federated ahead of its lifecycle. That record is yours to keep. * **Reconciliation reports drift; it does not fix it.** Deciding what to do about each class of discrepancy is a design decision made before the first run, not a result you react to. * **There is no comparison of one reconciliation run against another.** Proving that a phase changed nothing it should not have is something you assemble from the run outputs. ## Related * [Sequence: lifecycle before SSO](/solution-architecture/programme/sequence.md) — the ordering position this plan implements. * [Operating in a regulated environment](/solution-architecture/programme/regulated-environments.md) — what a phase must produce as evidence where a quality framework applies. * Part 4, *How access gets granted* — the disabled scheduled work, and what each task changes. * Part 5, *Planning a wave migration* — phasing when an incumbent platform is being retired at the same time. *Applies to OpenIAM 2026.8.1. Last reviewed 7 August 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/solution-architecture/programme/phasing-a-rollout.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.