> 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.md).

# Coexistence and migration

Running OpenIAM alongside a governance platform you are not replacing yet — who writes, who only reads, where a request lives, how lifecycle crosses the boundary, and how the arrangement ends.

## What this is, and when you need it

Most OpenIAM designs of any size are not greenfield. There is already an identity governance platform, or an access management product, or both, governing part of the estate — and it is not being switched off this quarter. Part 5 is about designing for the period when two platforms are real at the same time, and about ending that period deliberately rather than letting it become the architecture.

**Coexistence here means something specific: two governance platforms in production at once, each accountable for part of the estate, with a dated plan for the arrangement to end.** It is not federation between two organizations that intend to stay separate — that is a decision in this part too, but a different one — and it is not a permanent split of governance between two products, which is a design this part argues against.

You need Part 5 when an acquisition brings a governance platform with it, when a replacement is long enough that "during" is a state to be operated rather than passed through, or when a subsidiary keeps its own tooling while the group standardises. The reader is usually the person who has to explain the arrangement to an audit function or a CIO, in one sitting.

## The rule the whole part rests on

One position runs through every page here and is worth stating before the routing table.

> **Exactly one platform decides and executes for a given application at any moment.** One catalogue entry, one approval policy, one provisioning path, one certification. The other platform may see the resulting access, read-only, for a unified view. Unified visibility is not governance, and it must never become duplicate governance.

Everything else in Part 5 is a consequence of that rule or a case where applying it is not obvious. The pressure to break it is constant and always reasonable-sounding, which is why it belongs in the programme's terms of reference and not only in an architecture document.

A second position runs alongside it and belongs to Parts 2 and 3, but decides outcomes here: **identity lifecycle and governance come before single sign-on.** A person has to be known in OpenIAM and known in the target application before single sign-on to that application can work at all. A coexistence programme that federates first and establishes identity afterwards produces a bridge that appears to work and cannot be evidenced.

## The decisions in this part

| The question in front of you                                                                                                                                     | Page                                                                                                                          | What it turns on                                                                                                                        |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| Which platform governs which application while both are live, and how do we stop that being renegotiated every week?                                             | [Coexisting with an incumbent IGA](/solution-architecture/coexistence/coexisting-with-an-incumbent-iga.md)                    | Connector readiness, population, the certification calendar, and whether the application's entitlements feed other decisions            |
| The audit function wants one screen across both estates. How much of the other platform's access data do we bring in, and how do we keep the copy observational? | [The enterprise view without duplicate governance](/solution-architecture/coexistence/the-enterprise-view.md)                 | What the applications can be read from, whether the correlation key holds, and which of four audit questions you are willing to promise |
| A user needs an application the other platform governs. Where do they ask?                                                                                       | [Where a request lives when two catalogues exist](/solution-architecture/coexistence/where-a-request-lives.md)                | Whether you route the request or route the user — and whether each application has an owner who will accept the approval policy         |
| Someone leaves, or moves between the two organizations. Who detects it, who acts, and what does the other platform owe?                                          | [Lifecycle events across a governance boundary](/solution-architecture/coexistence/lifecycle-across-a-governance-boundary.md) | Which HR feed sees the event, which identifier survives a transfer, and whether the design handles the mutations as well as the joiner  |
| How do people cross between two estates with two identity providers and two sets of identifiers?                                                                 | [Cross-organization federation](/solution-architecture/coexistence/cross-organization-federation.md)                          | Which direction of trust is needed first, and whether the receiving estate learns the population by synchronization or at first sign-in |
| In what order do applications move, how do we prove a wave worked, and when does the incumbent switch off?                                                       | [Planning a wave migration](/solution-architecture/coexistence/planning-a-wave-migration.md)                                  | Risk and dependency, connector readiness, the certification calendar, and whether the plan has an end date                              |

Read them in that order the first time. The first page establishes the rule, the next three apply it to the three things that cross a governance boundary — visibility, requests and lifecycle events — the fifth handles the authentication half, and the last one dismantles the arrangement.

## What these pages assume

**That there is a correlation key spanning both estates.** Without one you cannot assemble an enterprise view, cannot survive a transfer, and cannot federate on anything stable. It is a Part 2 decision with a Part 5 deadline, and it should be settled before the wave plan is drafted. See Part 2, *Identity correlation: choosing a matching key*.

**That the migration has an end date.** If it does not, this is not a migration architecture; it is a permanent federated-governance design, and it should be assessed as one — with both platforms' costs, both operating teams, and both audit conversations counted.

**That lifecycle mutations are normal.** Contractors becoming employees and back, seasonal workers who leave and return, transfers between organizations with different HR systems. A design that handles only the joiner and the leaver will not survive contact with an estate of any size, and in a coexistence programme every one of those mutations crosses the governance boundary.

**That the regulatory framing is honest.** Where the estate operates under a quality framework, the technology supports the controls and produces the evidence; the organization validates the configured process under its own procedures. That boundary is stated on [Planning a wave migration](/solution-architecture/coexistence/planning-a-wave-migration.md) and it should be stated the same way to sponsors.

## Related

* Part 9, *Coexistence with an incumbent IGA* — these decisions assembled into one worked design, with the shape drawn.
* Part 9, *Cross-organization federation* — the same for the authentication half.
* Part 2, *Choosing your authoritative sources* — which feed is allowed to say a person exists, or has left.
* *The certification model* and *Connectors and managed systems* in the Administration Guide — the model these pages apply to a two-platform estate.

*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.md?ask=<question>&goal=<user_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.