Migrate from Microsoft Entra ID to Keycloak: what the move involves
Moving application SSO off Microsoft Entra ID is an integration project, not a data export. A renewal, a licensing change or a residency requirement usually triggers the review, but the work is in re-creating how each application trusts the identity provider, how users reach their directory and how access rules are enforced. Keycloak can take over that role for OpenID Connect, OAuth 2.0 and SAML 2.0 applications, and it can keep Active Directory as the source of accounts through its built-in LDAP and Active Directory user federation. Plan for the migration as a set of application cutovers, each with its own test and rollback path. The work is usually done by the internal identity or platform team, often with an implementation partner for the Keycloak build, hardening and the SAML and OIDC re-pointing. Effort depends mainly on the number of enterprise applications, how many use SAML with custom attribute mappings, how many depend on Entra-specific claims or groups, and how much Conditional Access logic has to be rebuilt as Keycloak authentication flows or a separate MFA product. Ask any partner for a written scope that lists each application, its protocol, its owner and its cutover plan, because that list, not the Keycloak installation, sets the timeline. Confirm the durations with your own inventory rather than with a generic estimate. Microsoft 365 sign-in is a separate decision and should be treated as one. Exchange Online, SharePoint, Teams and other Microsoft clients authenticate against Entra ID, and moving them to a Keycloak-issued sign-in requires federating the Entra domain with Keycloak and meeting Microsoft's provisioning and identifier requirements. Many organizations keep Microsoft 365 on Entra ID and move only their line-of-business applications, which limits the risk. Confirm with Microsoft which licenses still apply to your tenant before you change anything, since Entra licensing can remain even when sign-in for other apps moves away.
Which Entra ID capabilities map to Keycloak, and which need rework
This table maps the Entra ID capabilities that application SSO depends on to Keycloak equivalents, labelled clean, needs rework or gap. Read the status column first, then check the notes against the Keycloak server administration guide for your Keycloak version, because feature details can change between releases. The main takeaway is that app SSO and AD-backed sign-in move well, while Conditional Access and Microsoft 365 sign-in need separate planning.
| Entra ID capability | Keycloak equivalent and status | Notes for the migration |
|---|---|---|
| SAML and OIDC enterprise apps | Clean: Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0 clients | Recreate each app as a Keycloak client, then re-point redirect URIs, signing certificates and claim mappings. Confirm client settings in the server administration guide. |
| LDAP user federation with Active Directory | Clean: built-in LDAP and Active Directory user federation | Keep AD as the source of users and passwords. Confirm bind account, attribute mappings and sync mode for your AD layout before cutover. |
| Groups and group-based app access | Needs rework: Keycloak groups and roles are configured in Keycloak | Group membership can be synced from AD, but app assignments are rebuilt as Keycloak roles or client scopes. Confirm group mapper options in the administration guide. |
| Identity brokering to external IdPs | Clean: Keycloak identity brokering for OIDC and SAML providers | Useful for partners or a staged move. Test first-login account linking and claim handling for each broker. |
| MFA for sign-in | Needs rework: Keycloak supports OTP and WebAuthn-based authentication flows | MFA methods, enrollment and recovery must be rebuilt and tested. Confirm the supported second factors and required action settings for your version. |
| Conditional Access policies (location, device, risk, step-up) | Needs rework: Keycloak conditional authentication flows and privacyIDEA policies | Common policies can be approximated, but risk-based sign-in and device compliance from Entra ID P1 or P2 have no direct equivalent. Document each policy and its owner before cutover. |
| Microsoft 365 and Exchange sign-in | Gap: stays on Entra ID | Microsoft 365 and Exchange clients depend on Entra ID tokens. Keep this in scope separately, and confirm the federation options described in the Keep Microsoft 365 path. |
How Keycloak federates Active Directory over LDAP
Keycloak can keep Active Directory as the system of record for passwords and group membership while it takes over application sign-in. Its built-in user federation connects to existing LDAP and Active Directory servers, so users keep the credentials they already use, and Keycloak brokers the OpenID Connect, OAuth 2.0 and SAML 2.0 flows that your applications see. In this model, a password change, account disablement or group change made in AD takes effect at the next sign-in, and Keycloak does not store a second copy of the password. Before you commit to this design, confirm which federation mode you will use and whether Keycloak imports users locally or queries the directory on each login, because that choice determines how quickly a disabled account stops working in each application.
Attribute and group mapping is where most migrations go wrong. AD attributes such as sAMAccountName, userPrincipalName, mail and department need explicit mappers to Keycloak user attributes, and AD security groups need mappers to Keycloak groups or client roles that your applications read in their tokens. Decide early how on-premises identifiers, such as objectGUID or the ImmutableID value used for Microsoft 365 matching, will be carried into Keycloak, because applications that store a user key will break if that key changes. Also review the sync from AD to Entra ID, typically run by Microsoft Entra Connect, as a separate dependency. Moving application SSO off Entra ID does not turn that sync off, and Microsoft 365 sign-in still relies on it.
Test the whole chain in a separate Keycloak realm before any application moves. Use a test OU or a small group of accounts, confirm group-to-role mapping for each application, check that a disabled AD account is refused, and verify the claims each relying party receives. Record the mapper configuration so the same settings can be reproduced in production. Confirm the exact LDAP connection, bind account and search settings with your directory team, because these determine what Keycloak can read and what it can change.
Migration sequence from inventory to decommission
This sequence moves application sign-in from Entra ID to Keycloak in stages, so each app is proven on the new identity provider before its Entra configuration is retired. Every step ends with a artifact the team can review and roll back from.
Inventory apps, registrations and Conditional Access policies
Export the user list from the Entra admin center and list every enterprise application, app registration, SAML and OIDC configuration, group claim, and Conditional Access policy that applies to them. Record which Microsoft 365 services depend on Entra ID and which are plain application SSO. The output is a dependency register that names each app, its protocol, its owner, the claims it expects, and the Conditional Access rules that gate it. Confirm with each owner that the register is complete before moving on.
Map Conditional Access rules to Keycloak controls
For each Conditional Access policy in the register, decide whether Keycloak conditional authentication flows, a second factor from an MFA provider, or an application-side check will carry the same intent. Mark any rule with no equivalent, such as risk-based sign-in signals that depend on Entra ID P2, so the owner accepts the gap in writing. The output is a control mapping document that security and identity leads sign off before any app is migrated.
Build a pilot realm with LDAP federation
Stand up a non-production Keycloak instance and create a pilot realm. Configure user federation against the on-premises Active Directory over LDAP, keeping AD as the source of user accounts and passwords. Register one OIDC client and one SAML client for low-risk test applications. The output is a working pilot realm, a tested sign-in path for both protocols, and a realm export kept under version control, with the team confirming that the export and import steps behave as documented before relying on them.
Run a parallel period with both providers
Keep Entra ID as the active provider for production apps while the pilot apps and selected production apps also accept sign-in through Keycloak. Compare group mappings, token claims and session behavior between the two providers for the same test users. Record every difference in a gap log and fix each one in the realm configuration. The output is a gap log with every item closed or accepted by its owner, and a cutover runbook that lists the steps, checks and owners for each app.
Cut over applications one at a time
Move one application at a time by changing its redirect URIs, metadata or SAML endpoints to point at Keycloak, following the cutover runbook. Test sign-in, sign-out, token refresh and role-based access before users are moved. Keep the Entra configuration for that app in place but disabled from new use only after the owner confirms success. The output for each app is a signed cutover record and a tested rollback plan that restores the Entra configuration within the change window.
Stop the operations that need Entra ID
Confirm which Microsoft 365 sign-in paths remain on Entra ID, such as Exchange, Teams and SharePoint, and document their licensing and conditional access dependencies. Ask Microsoft or your licensing partner to confirm what remains required for those services. The output is a retained-services statement that tells auditors and service owners exactly what still depends on Entra ID, so no one disables a service that Microsoft 365 still needs.
Decommission Entra enterprise applications
After every migrated app has run on Keycloak through an agreed observation period, remove the Entra enterprise applications and app registrations that are no longer used. Export their configuration first and store it with the dependency register. Remove the related groups and policies only when no retained service depends on them. The output is a decommission record listing each removed object, the export kept for audit, and a final review confirming that all in-scope applications sign in through Keycloak.
What data moves, what gets rebuilt and what exports cover
Entra ID gives you a documented user list export, but most of the SSO configuration does not leave the tenant as data. Keycloak has its own realm export, which is useful for configuration but is not a backup. Read each card as a line between what you can carry across and what you must recreate.
Entra user list CSV
The Entra admin center lets you download the user list as a CSV from Users, All users, Download users. The default columns include userPrincipalName and mail, and the preview download lets you add department and on-premises identifiers. Use these fields to match accounts against the directory later, not as a credential source. Confirm which attributes your tenant exposes before you rely on the file for mapping.
Password hashes are not exported
The Entra CSV contains no password hashes, so Keycloak cannot inherit credentials from it. Active Directory stays the password source: Keycloak federates to AD over LDAP, and users keep their existing AD passwords. Plan for the cloud-only accounts that have no AD object, because those users need a different credential path or a reset before they can sign in.
App registrations and enterprise apps
Entra app registrations, enterprise application settings, redirect URIs, claims mappings and SAML signing certificates do not come out as a portable file. Each one has to be recreated as a Keycloak OIDC or SAML client, then tested against the application. Inventory every app first, with its protocol, owner and the claims it expects, because the claims are where re-pointed apps usually break.
Groups, roles and Conditional Access rules
Groups, dynamic group rules, app role assignments and Conditional Access policies are configuration in the Entra tenant and must be rebuilt in Keycloak as groups, roles and authentication flows. Conditional Access has no import path, so each policy needs a written equivalent and an owner who signs off on it. Treat this as a design task, not a copy task.
Keycloak realm export as JSON
Keycloak exports and imports realms as JSON files with the kc.sh export and kc.sh import commands. The official guide warns that this process has limitations as a backup and restore mechanism, and that all nodes must be stopped while it runs. Use it to capture realm configuration for review or rebuild, and back up the database separately with your normal backup process.
What stays in Entra and AD
Microsoft 365 sign-in, Exchange and Teams identities, and the Entra objects that Microsoft services depend on remain in Entra ID. Active Directory keeps the password, the account lifecycle and the on-premises identifiers that Keycloak reads. Document which accounts and services still authenticate through Entra before you change any application, so the cutover does not break mail or Office clients.
How the move differs by starting point
This is the most direct path. Keycloak can federate the existing Active Directory forest over LDAP as a user federation provider, so people keep their directory passwords and group memberships while sign-in moves to Keycloak. The work concentrates on the handful of SAML service providers, which need new metadata, new signing certificates and attribute mappings that match what each application expects.
- Federation first: Configure the LDAP user federation and confirm that group and attribute mappings return the claims each app uses today.
- Metadata swap: Export the current Entra ID SAML metadata for each app, then build matching Keycloak clients and test each one with a single pilot user.
- Certificate handling: Plan new signing certificates and their expiry dates before cutover, since each relying party must trust the new key.
- Cutover by app: Move one application at a time and keep the Entra ID enterprise app in place until the Keycloak version has worked for real users.
- Ownership: Keycloak administration, patching and backups become your team's job, so decide who holds the admin role before go-live.
Confirm with your application owners which attributes each SAML app reads, because a missing claim is the most common reason a migrated app fails at first sign-in.
This path takes longer because the work is in the policies rather than the connections. Each OIDC application needs a Keycloak client with the right redirect URIs, scopes and token lifetimes, and custom Conditional Access rules must be rebuilt as Keycloak conditional authentication flows, with MFA handled by a separate tool where needed. Inventory comes first, since the Entra ID portal shows which apps exist but not always which rules they depend on.
- Rule inventory: List every Conditional Access policy, its scope, its grant controls and its exclusions, then mark which ones have a Keycloak equivalent and which do not.
- Client standardization: Group OIDC apps by library and redirect pattern so the Keycloak client templates can be reused.
- Policy rebuild: Rebuild location, device and risk rules as Keycloak flows or as an MFA product's policies, and record what is lost.
- Parallel testing: Run a test realm or a separate client set so that policy changes can be checked without touching production users.
- Operating model: Assign owners for each policy after migration, because policy drift is harder to see without a central Entra ID policy view.
Ask for a written list of Conditional Access controls that will not carry over before you commit to a timeline with your security team.
When Microsoft 365 stays, the goal narrows to app sign-in. Microsoft 365 clients and Exchange, Teams and SharePoint sign-in still depend on Entra ID, and Keycloak does not replace that dependency. The practical design is to federate the Entra domain to Keycloak over SAML 2.0 so that Keycloak authenticates users for Microsoft 365, while Entra ID still holds the tenant, licenses and the sign-in record that Microsoft clients expect.
- Identity anchor: Confirm the ImmutableID and source anchor values are set correctly, because federation breaks if they do not match the directory object.
- Client coverage: Check which Microsoft clients the SAML route supports in your version of Microsoft 365, and test each one before changing the domain.
- Licensing: Keep the Entra ID licenses that Microsoft 365 requires, and confirm which features still need them.
- Provisioning: Decide whether user lifecycle stays in AD Connect or moves to another process, since both directions touch the same accounts.
- Split responsibility: Microsoft handles the tenant, and your team handles the Keycloak side, so write down which party owns each fault.
Verify the current Microsoft federation and client requirements in Microsoft's documentation before planning, since these conditions change over time.
For isolated networks or organizations with strict data location requirements, Entra ID is not an option because it is a cloud service. Keycloak runs entirely inside your own network, and the directory is usually FreeIPA or Samba AD rather than a cloud tenant. The sequence changes because there is no Entra ID to federate from, so the directory itself becomes part of the design and must be built or migrated first.
- Directory first: Decide between FreeIPA and Samba AD for the source of identities, since Keycloak will federate from whichever one you choose.
- Offline operations: Plan patching, certificate renewal and container image delivery without internet access, and confirm the update path with your vendor or internal mirror.
- Database placement: Choose a supported production database, such as PostgreSQL, and place it inside the enclave with its own backup target.
- Evidence: Document where identity data sits, who can read it and how changes are logged, since auditors will ask for it.
- Ownership: Every component is yours to operate, so staffing and on-call responsibility must be settled before the design is final.
Confirm with your security and data protection teams which data may leave the enclave and which must stay, since that decision sets the rest of the design.
What drives cost and duration in an Entra ID to Keycloak move
This table lists the components of an Entra ID to Keycloak move, who carries the work, whether the cost is one-time or recurring, and what to ask for in a written scope. Use it to compare vendor and partner quotes line by line. The main takeaway is that the number of applications, the protocol mix and the Conditional Access rules to rebuild matter more than the Keycloak software itself, which is open source under Apache 2.0.
| Driver | Why it changes cost or effort | One-time or recurring | What to ask for in the scope |
|---|---|---|---|
| Enterprise app count and protocol mix | Each OIDC or SAML application needs a client, redirect URIs, claim mappings and a cutover test. SAML apps with custom signing or encryption settings take longer than standard OIDC clients. | One-time | A per-application inventory with protocol, owner, claims needed and cutover window, plus the number of apps in each wave |
| Conditional Access rules | Entra ID Conditional Access policies must be translated into Keycloak authentication flows or a separate policy engine such as privacyIDEA. Policies without a direct equivalent need a documented decision to accept, compensate or drop them. | One-time, with ongoing review | A mapping of every existing policy to its replacement, the policies with no equivalent, and who approves each gap |
| LDAP attribute and group mapping | Keycloak federates Active Directory over LDAP, so user attributes, group membership and role mappings must match what applications expect. Nested groups and on-premises identifiers often need extra mappers. | One-time, then recurring as attributes change | The LDAP mapper configuration, the group-to-role matrix and a sample of users tested against each application |
| High availability design | A single cluster, optionally across availability zones, or a multi-cluster design each need a synchronously replicated database. The database and its failover tests usually add more cost than the Keycloak nodes. | Initial build is one-time, then recurring for hosting and database licences or support | The chosen HA architecture, the database engine and version (PostgreSQL 14 to 18 is listed as supported), and the failover test results |
| Operator and upgrade approval | The Keycloak Operator documentation strongly recommends manual approval for operator updates. Keeping upgrades under change control means someone must review each minor release, which Keycloak now ships four times a year. | Recurring | Who approves upgrades, the test environment used before each one, and the rollback path for a failed release |
| Testing of each application | Every app needs login, logout, token refresh, role checks and failure handling tested before cutover. Apps that cache Entra tokens or use the Microsoft authentication library need separate changes. | One-time per app, with regression tests recurring after changes | Test scripts per application, the acceptance criteria, and the named business owner who signs off each cutover |
| Microsoft 365 sign-in and Entra licensing | Microsoft 365 sign-in, Exchange and Teams stay on Entra ID, so Entra licensing continues. Work on those services is separate from the Keycloak project and should not be counted as a saving. | Recurring Microsoft licensing continues | A written statement of which Microsoft services remain on Entra ID and which licences stay in place after cutover |
| Support and operations after cutover | Keycloak is community supported in its open-source form. Production support from a vendor, a partner retainer or in-house staff is a recurring cost that depends on how many people carry the pager. | Recurring | Support hours, escalation path, patch cadence, backup and restore tests, and whether the support model covers upgrades |
What usually goes wrong and how to prevent it
Most migrations off Entra ID fail at the edges: rules that never made it across, identifiers that changed under users, and upgrades nobody scheduled. The cards below cover the failures we see most often in application SSO moves to Keycloak, each with a check to run before and during cutover.
Conditional Access rules silently dropped
Entra ID Conditional Access policies do not export as a file that Keycloak can import, so rules such as MFA for administrators or location blocks can disappear without an error. Build an inventory of every policy, its scope and its grant or block control before cutover, then map each one to a Keycloak conditional authentication flow or an equivalent policy. Test each rule with a named account that should be blocked and one that should pass.
Group-based access broken by mapping changes
Applications that read group claims from Entra ID often expect specific group object IDs or names, and Keycloak issues those claims from its own group model. A mapper that emits a different claim name or a flat list instead of full paths can silently remove access. Document every group claim each app consumes, reproduce it with a Keycloak protocol mapper, and compare token contents for the same test user in both systems.
SAML certificate and metadata mismatches
Re-pointing a SAML enterprise app means the service provider must trust the new Keycloak signing certificate, and the entity ID, ACS URL and NameID format must match what the app expects. A stale certificate in the app or an old metadata file typically fails only at cutover, when the old trust is removed. Keep the Entra ID configuration available for rollback, export the Keycloak metadata for each client, and verify signature validation in a test environment before changing DNS or routing.
Users locked out by MFA re-enrollment
Users who registered authenticators in Entra ID do not carry those registrations into Keycloak, so they reach a new enrollment prompt or a helpdesk queue on their first sign-in. Plan the enrollment window, decide which second factors you accept, and confirm how the helpdesk verifies identity before resetting an authenticator. Pilot with a small group so you can measure the lockout volume before the full user base moves.
Keycloak upgrades applied automatically
Keycloak migrates its database schema at startup by default, so a container image update can change the database before anyone has tested the new release. The project releases four minor versions a year and says breaking changes in minor releases are opt-in, but operators still need a tested path. Pin the image version, rehearse upgrades on a copy of the production database, and for the Operator use manual approval mode so upgrades are scheduled rather than automatic.
Microsoft 365 sign-in broken by incomplete domain plan
Moving application SSO does not move Microsoft 365 sign-in, and changing the identity provider for a verified domain can break Exchange, Teams and other Microsoft clients for users who are not ready. Before any domain change, list every verified domain, the Entra ID sign-in method for each, and every Microsoft client in use. Confirm with Microsoft which federation path your licenses and clients support, and keep Entra ID as the sign-in authority for Microsoft 365 unless that path is validated end to end.
What has to stay on Entra ID for Microsoft 365 sign-in
Microsoft 365 and Azure sign-in depends on Microsoft Entra ID, and moving application SSO to Keycloak does not remove that dependency. The decision in this migration is about where your business applications authenticate, not where Microsoft 365 authenticates. Exchange Online, SharePoint, Teams, the Microsoft 365 admin center and Azure portal sign-ins will keep issuing tokens from the Entra tenant, so the tenant, its licensing and its administrative accounts remain in place after the cutover. Before you commit to a timeline, list every Microsoft workload your users open daily and confirm with Microsoft which sign-in paths each one uses in your tenant.
Keeping Entra ID for Microsoft 365 does not have to mean keeping every enterprise app on it. Keycloak can take over SAML and OIDC registrations for line-of-business apps, with Active Directory as the user source through LDAP federation. Plan for two identity paths running in parallel: Entra ID for Microsoft services and Keycloak for the applications you move. Each application needs its own client definition, redirect URIs and attribute mappings, and the admin roles that manage the tenant must be tested separately from user sign-in. Record which apps stay on Entra ID so the change log shows the final split.
Federating an Entra domain to Keycloak is a different pattern. In that route, Entra ID still handles Microsoft 365 sign-in but delegates authentication for a verified domain to Keycloak over SAML 2.0. It brings its own requirements, including the ImmutableID attribute that links cloud and on-premises accounts, and provisioning that must keep both directories consistent. Confirm with Microsoft which clients the SAML route supports and what Entra licensing still applies before you choose it. The sibling page on keeping Microsoft 365 while replacing Entra ID sign-in covers that route in detail.
Questions buyers ask before moving off Entra ID
How much effort does moving application SSO off Entra ID take?
Effort depends mainly on how many applications you move, which protocols they use and how many of them rely on custom claims, groups or Conditional Access outcomes. Each SAML or OIDC enterprise app needs its client, redirect URIs, attribute mappings and certificates rebuilt in Keycloak, and each one needs testing with real users before cutover. Federating Keycloak with Active Directory over LDAP is usually a smaller piece of work than the app inventory itself. A useful first step is an inventory of every enterprise app, its protocol, its owners and the policies that apply to it, because that inventory sets the scope you should ask for in a written quote. No fixed effort figure is supplied for this move, so ask any provider to base its estimate on your inventory.
How long does a migration from Entra ID to Keycloak take?
Duration depends on scope rather than on a standard timeline. The number of applications, the number of user sources, whether you run a high availability cluster across availability zones, and how many policies need redesigning all change the schedule. Keycloak's own high availability designs require a synchronously replicated database, so infrastructure readiness can set the pace before any application work begins. Plan for a parallel period where Entra ID and Keycloak both serve sign-in for different apps, then move apps in waves with a rollback path for each one. Ask for a timeline tied to a written scope and deliverables, and treat any single duration quoted before the inventory is complete as unverified.
What does the internal team need to contribute?
The internal team needs to own decisions that only the organization can make, and to provide access and testing time. In practice that means an application owner for each enterprise app who can confirm redirect URIs, required claims and test accounts, a directory owner who approves the Active Directory LDAP bind account and attribute mappings, and a security owner who signs off on MFA, session lifetimes and any access rules that replace Conditional Access. Someone also needs to own the Keycloak platform after go-live, including database backups, certificates and upgrades. Without named owners for these roles, cutover dates tend to slip, so confirm them before the engagement starts.
Can we do the Entra ID to Keycloak migration in-house?
Many teams can do it in-house if they already run Linux services, a supported production database and an identity directory, and if they have engineers who understand OIDC and SAML. The harder parts are usually not the initial install. They are rebuilding per-app SAML and OIDC configuration, testing edge cases such as nested groups and token claims, designing a high availability setup, and writing runbooks for backup and restore. Keycloak's export and import of realms is documented with limitations as a backup mechanism, and all nodes must be stopped while it runs, so the backup design needs to be deliberate. If your team lacks this capacity, a fixed-scope engagement with written deliverables is one option, and DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms in your own infrastructure. Ask any provider to show how it will hand over documentation and knowledge.
Does Microsoft 365 sign-in have to move to Keycloak too?
No, not necessarily. Keycloak can take over application SSO while Microsoft 365 sign-in stays on Entra ID, which is the usual starting point for application-focused migrations. Microsoft 365 and Azure depend on the Entra tenant, so the tenant, its licensing and its Microsoft clients stay on Microsoft's service. If you want Microsoft 365 sign-in to use Keycloak as the identity provider, that is a separate federation project that involves a SAML 2.0 domain federation, ImmutableID and provisioning requirements, and continued Entra licensing for the Microsoft services you use. Confirm which Microsoft clients the SAML route supports before you plan that work, and keep the two paths separate in your scope.
What happens to Conditional Access rules after the move?
Conditional Access does not move automatically, and Entra ID rules have no one-to-one copy in Keycloak. Each policy needs to be mapped to something you build or configure, such as Keycloak conditional authentication flows, a step-up MFA policy or an access check in the application. Common cases such as MFA for administrators or requiring a second factor for sensitive apps can be rebuilt, but risk-based sign-in policies that depend on Entra ID P2 signals do not have a direct equivalent in Keycloak. Export your current Conditional Access policies, record which users and apps they cover, and decide for each one whether to rebuild it, replace it or accept the gap in writing before cutover.
How are Keycloak upgrades handled without breaking applications?
Keycloak upgrades are handled as a planned change with a testing stage. The Keycloak project says that, since version 26.0, it plans four minor releases a year and a major release every two to three years, and that breaking changes in a minor release will be opt-in. The upgrading guide also explains that the database schema migrates automatically at startup by default, and that administrators can apply the SQL manually, which the guide suggests for large deployments. The current release is 26.8.1, published October 13, 2026. Test each upgrade against a copy of your realm and database, read the upgrading guide for each target version, and if you run the Keycloak Operator, the operator documentation strongly recommends manual approval mode for updates to avoid unintended automatic upgrades.
What should we ask for in a written quote?
Ask for a scope that lists each application, protocol, user source and policy in scope, with the deliverables for each and what is excluded. A useful quote states the target architecture, including whether high availability is needed and which database will be used, and the test plan, cutover approach and rollback steps. It should also name who does application testing, who signs off, what documentation and runbooks are delivered, how backups are handled, and what post-go-live support is included or offered as a separate retainer. DeployOpen does not publish a price list, and a quote follows from the written scope, so the quality of your inventory directly affects the quality of the quote.
How DeployOpen scopes and runs the migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted Keycloak inside your own infrastructure, whether that is your cloud accounts, your data centers or an isolated network. For an Entra ID exit, the work usually splits into a few clearly bounded pieces: standing up the Keycloak deployment and its database, federating the Active Directory source over LDAP, re-pointing each SAML and OIDC application, and rebuilding the access rules that Conditional Access enforces today. Each piece has its own acceptance checks, such as confirming that group membership and account state from AD reach Keycloak correctly and that every re-pointed application completes a full sign-in and sign-out test. Decide early which applications are in the first wave and which stay on Entra ID, because that boundary determines the scope.
Most engagements are fixed-scope. Before any work starts, the scope, deliverables, timelines and responsibilities are agreed in writing, including which applications, realms, environments and Microsoft 365 sign-in paths are covered and which are out. A quote follows from that written scope, so the figures you receive should map to named components rather than to a generic per-user rate. Ask the proposal to separate one-time work, such as build, integration and cutover, from recurring items, such as hosting, database operations, upgrades and support. Ask how the Keycloak Operator or your chosen install method will be updated, and whether manual approval of updates is part of the handover.
After cutover, ongoing support, upgrades and continuous security testing are available as retainers. This matters for Keycloak because its release cadence means minor upgrades arrive regularly, and the project recommends that breaking changes be opted into deliberately. A retainer lets the team that built the deployment keep it current, test each upgrade against your re-pointed applications and keep the documentation and evidence for compliance assessments up to date. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue any audit reports or certifications. Confirm with your assessor which evidence they expect before the cutover date is set.
