> 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/coexistence/coexisting-with-an-incumbent-iga.md). # Coexisting with an incumbent IGA The single-writer rule — exactly one platform decides and executes for a given application at a time. What that buys, what it forbids, and how to decide which platform owns which application during th ## What this is, and when you need it You are putting OpenIAM into an estate that already has an identity governance platform, and that platform is not going away this year. The question the programme has to answer before it does anything else is not which product is better and not what the end state looks like: it is **who decides, and who executes, for each application, while both platforms are live**. This page settles that question with one rule and its consequences. You need it from the moment two governance platforms are in production at once — after an acquisition, during a long replacement, or in a group structure where a subsidiary keeps its own tooling for a while. ## The decision | Ownership model | What it buys | What it costs | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **One write owner per application** — one platform holds the catalogue entry, the approval policy, the provisioning path and the certification for that application, and the other may read | A single accountable platform per application at every moment; deterministic reconciliation; a clean evidence boundary at each wave | Users must go to two places during the transition; every request to "just do this one in the other platform" has to be declined | | **Split by function** — one platform approves, the other provisions | Lets each platform do what it is currently better at; feels like a compromise everyone can accept | No single record of a grant. The approval lives in one audit trail and the change in another, and when they disagree there is no arbiter. This is the model that fails first | | **Dual write** — both platforms provision the same application | Nobody has to change how they work | Two reconciliation loops with different models of correct. One removes what the other restores, on a schedule, forever. Recovery means switching one off and rebuilding the truth by hand | | **Freeze** — no access changes to the application at all until it migrates | Simple, and genuinely correct for a short, dated window | Unworkable for more than a few weeks. Business change does not stop for a migration, and a frozen application accumulates a backlog of manual exceptions that nobody governs | **Choose one write owner per application.** The rest of this page is what that means in practice and how to decide, application by application, which platform it is. ### The four things that travel together The rule is precise, and its precision is the point. For each application, at each moment, **one platform holds all four of these**: | | What it is | Why it cannot be split off | | --------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | The catalogue entry | Where a user asks for the access | A second catalogue entry means two request records for one grant, and no way to answer "was it asked for?" | | The approval policy | Who decides, and on what basis | An approval recorded in a platform that cannot then act is an opinion, not a control | | The provisioning path | The connector, or the human task where there is no connector | The platform that changed the account is the only one that knows what it changed | | The certification | Who attests to the resulting access, and what a revoke decision does | A revoke decision the platform cannot enforce produces evidence that is worse than none | An arrangement that separates any of these is not coexistence. It is a distributed decision with no owner, and it fails the first time the two platforms disagree — which they will, because they were configured by different teams from different sources of truth. ## What the rule buys **One answer to "who was accountable".** A regulator, an auditor or an incident review asks who approved a grant, on what date, under which policy. With one write owner per application there is exactly one platform to ask and exactly one answer. This is the benefit that justifies the inconvenience, and it is worth stating in those terms to the people who will find the inconvenience irritating. **Reconciliation that converges.** Reconciliation compares what a platform believes with what the application contains, and acts on the difference. Two platforms reconciling the same application each treat the other's changes as drift. The result is not a race condition you can tune away; it is two correct systems each undoing the other. One write owner removes the possibility rather than managing it. **A clean seam at each wave.** When ownership moves, it moves as a set. You can state what the incumbent held on the day before and what OpenIAM held on the day after, and the two lists are the same four things. A partial transfer has no such boundary, and nothing to validate against. **A defensible position under change pressure.** Programmes of this kind are subjected to constant, reasonable-sounding requests to make an exception. Having the rule written down — in the programme's terms of reference, not only in the architecture — converts each of those into a scheduling conversation about which wave the application belongs in, which is a conversation that has an answer. ## What the rule forbids It is worth naming the specific proposals the rule rules out, because each of them arrives with a good argument attached. * **A role in one platform that grants access in an application owned by the other.** This is the most common request and the most damaging, because it looks like ordinary role design. It splits the approval from the provisioning by construction. * **Raising a request in the platform the user already knows.** Users will ask for this and managers will support it. The answer is that the user crosses to the other platform; the request does not. See [Where a request lives when two catalogues exist](/solution-architecture/coexistence/where-a-request-lives.md). * **Reaching across for terminations only.** Termination feels like a special case where speed beats process. It is not: a removal performed by a platform that does not own the application has no approval record, no certification context, and no reconciliation loop that expects it. See [Lifecycle events across a governance boundary](/solution-architecture/coexistence/lifecycle-across-a-governance-boundary.md). * **Certifying the other platform's applications.** Campaign scope must stop at the ownership boundary. A campaign that collects revoke decisions OpenIAM cannot execute is a control that does not exist. * **A "temporary" second connector while the wave is prepared.** Preparation is reading, simulating and reconciling. It is not writing. What the other platform *may* do is **see** the access. Observation is not governance, and it is the whole subject of [The enterprise view without duplicate governance](/solution-architecture/coexistence/the-enterprise-view.md). ## Deciding which platform owns which application The default is that **the incumbent keeps everything it currently governs until a dated wave moves it**, and OpenIAM starts with what only OpenIAM can do — the acquiring population's HR-driven birthright access, and applications the incumbent never covered. Departing from that default needs a reason, and these are the reasons that hold up. | Consideration | Points to the incumbent | Points to OpenIAM | | ---------------------- | -------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Connector readiness | A working, proven integration exists and has been reconciling for years | The connector exists in OpenIAM and has been proved against a non-production instance of the target | | Population | The application is used almost entirely by the population the incumbent's HR feed describes | The application is used across both populations, or mainly by the population OpenIAM's feed describes | | Certification calendar | A campaign for this application is open, or opens before the candidate wave date | The next campaign is far enough out that the transfer and its validation complete first | | Entitlement dependency | Other applications' access decisions read this one's entitlements, and those applications have not moved | This application consumes entitlements from applications OpenIAM already owns | | Correlation | Accounts in this application cannot yet be matched to OpenIAM identities with acceptable orphan volume | Accounts correlate cleanly on the workforce identifier | | Fulfilment | Nothing changes | The application has no connector, and governing it through OpenIAM's manual fulfilment — an approved request becoming a human task — is acceptable to its owner | The last row deserves a caution. Manual fulfilment lets OpenIAM be the write owner for an application it cannot provision, which is genuinely useful and is how badge systems, key cabinets and vendor portals get governed. It is a poor reason to move an application the incumbent is already provisioning automatically: you would be trading an automated control for a human one to hit a wave date. Correlation is the precondition for all of it. If the identifier that links an account in that application to a person does not exist or is not trusted, nothing else on this page is available to you. That decision belongs to Part 2, *Identity correlation: choosing a matching key*, and it should be settled before the wave plan is drafted. ## The life of one application's write ownership Read this as the sequence a single application passes through. The state that matters is the middle one: between the incumbent releasing ownership and OpenIAM assuming it, nothing governs the application. ```mermaid stateDiagram-v2 [*] --> IncumbentWrites IncumbentWrites --> Quiesced: incumbent stops approving and provisioning Quiesced --> OpenIAMWrites: OpenIAM assumes catalogue, approval, connector and certification OpenIAMWrites --> [*]: incumbent retired IncumbentWrites --> IncumbentWrites: OpenIAM reads for the enterprise view OpenIAMWrites --> OpenIAMWrites: incumbent reads, if it still needs the view ``` Keep the quiesced state short, plan it deliberately, and do not let it span a certification period or a month-end. Everything else about that transition — how to order the applications, how to validate one, what evidence it leaves — is in [Planning a wave migration](/solution-architecture/coexistence/planning-a-wave-migration.md). ## Nothing in the product enforces this The single-writer rule is an operating discipline. Both platforms can be configured to write to the same application and neither will object. What OpenIAM gives you is not enforcement but **visibility and containment** — three levers that make an accidental write either impossible or obvious. **Simulation on the managed system.** A managed system can be set to capture selected provisioning operations instead of dispatching them. The operations available are Add, Save, Update, Enable, Disable, Lock, Delete, Login, Set Password, Reset Password, Send Single Provision Operation, Direct Delete Connector Request and Sync Password From Source. A captured operation is written to the simulation request list and recorded under the `SIMULATE_PROVISIONING` audit action, and an administrator reviews it and either applies or deletes it. Selecting every operation is the closest thing OpenIAM has to a per-application "do not write" switch, and it has the useful side effect that the request list becomes a record of exactly what OpenIAM *would* have done — which is the dry run the wave needs anyway. **Reconciliation responses.** A reconciliation configuration maps each of the four situations — OpenIAM \[exists] with target \[exists], OpenIAM \[exists] with target \[not found], target \[exists] with OpenIAM \[not found], and OpenIAM \[deleted] with target \[exists] — to a response. Configuring only the responses that write into OpenIAM, and none that write to the application, makes the reconciliation observational by construction. The detail is on [The enterprise view without duplicate governance](/solution-architecture/coexistence/the-enterprise-view.md). **The synchronization's provisioning flag.** A synchronization carries a **Provision to target systems?** setting. Cleared, the feed updates OpenIAM's own records and sends nothing outward. None of the three is a substitute for the rule. They are what makes a breach of it visible on the day rather than at the next audit. ## What we recommend **Adopt one write owner per application, and write it into the programme's terms of reference.** The architecture document is not where an exception request gets settled; the governance forum is, and it needs the rule in its own language. **Treat the four things as indivisible in every conversation.** When someone proposes an arrangement, ask which platform holds the catalogue entry, the approval policy, the provisioning path and the certification. If the four answers are not the same name, the proposal is a split. **Default to the incumbent keeping what it has, and justify every departure.** Moving an application early because it is easy is how a programme ends up having moved the applications nobody cares about and none of the ones the auditor asks about. **Put every incumbent-owned managed system into full simulation in OpenIAM from the day it is configured.** It costs nothing, it makes an accidental write impossible, and the accumulated request list is free evidence when the wave arrives. **Settle correlation before ownership.** An application whose accounts you cannot match to identities cannot be governed by OpenIAM and cannot be represented in the enterprise view either. That is a Part 2 decision with a Part 5 deadline. **Do not accept "split by function" as a compromise, even temporarily.** It is the arrangement most likely to be proposed as a way to move faster, and it is the only one on the decision table with no recovery path short of rebuilding the application's access record by hand. ## What OpenIAM does not do here * **OpenIAM does not integrate with another governance platform as a platform.** There is no connector to a governance product's own object model. Everything OpenIAM knows about the incumbent's estate it learns by reading the *applications*, as it would read any other managed system. * **Nothing prevents two platforms writing to the same application.** The product has no notion of an external write owner and no lock. The rule is enforced by people and made visible by configuration. * **There is no per-managed-system read-only flag.** Read-only is a property you assemble from the simulation list, the reconciliation responses and the synchronization's provisioning setting — three settings on three screens, each of which can be changed independently. * **There is no cross-platform approval routing.** A request raised in one platform's catalogue cannot be approved in the other's task inbox. * **A transfer of write ownership is not a product operation.** There is no migration mode, no ownership field and no report of which platform owns what. The wave plan is the record, and it lives in the programme, not in the product. ## Related * [The enterprise view without duplicate governance](/solution-architecture/coexistence/the-enterprise-view.md) — what the platform that does not own an application is allowed to know about it. * [Planning a wave migration](/solution-architecture/coexistence/planning-a-wave-migration.md) — how ownership actually moves, and in what order. * Part 2, *Identity correlation: choosing a matching key* — the precondition for everything on this page. * *Simulation mode* and *Configure reconciliation* in the Administration Guide — the mechanisms behind the three containment levers. *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/coexistence/coexisting-with-an-incumbent-iga.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.