What proves a Keycloak migration is complete before the old cluster is retired?
A new Keycloak cluster can pass an interactive login test while less visible dependencies still point at the old issuer or endpoints. Realms, clients, scopes, roles, identity providers, authentication flows, required actions, service accounts, keys, themes, LDAP federation, sessions, and event listeners can also move unevenly. A low-frequency application may not reveal its old discovery URL or pinned certificate for weeks.
A useful cutover gate could compare effective realm configuration, exercise every grant and identity-provider path, verify token claims and signing-key rollover, test logout and refresh flows, and inspect traffic on both clusters during an observation window. Backups and database recovery should be tested separately from realm export. The old cluster could remain read-only or isolated but recoverable until connection logs and token validation show no late clients.
What evidence do Keycloak operators require before shutdown? Which state is commonly missed by exports, and how do you find applications that cache discovery documents, JWKS, sessions, or credentials longer than expected?