How much work is a Red Hat SSO 7.6 migration to Keycloak?
Moving from Red Hat Single Sign-On 7.6 on JBoss EAP to the Red Hat build of Keycloak is a planned platform change that touches the database, the deployment, providers, themes and every client that signs users in. The effort depends mainly on how many realms, clients, user federations and custom extensions your installation has accumulated, and on how many of those applications must keep working through the cutover. A team with one realm and a handful of OpenID Connect clients faces a very different job from a team running several realms, LDAP or Active Directory federation, brokered identity providers and hand-written authenticators. Count these before you estimate anything. Export the realm configuration, list every client with its protocol, redirect URIs and token settings, and record each federation link and custom JAR. That inventory is the input for any quote, and a partner should be able to explain how it will build one from your environment.
Red Hat build of Keycloak is Red Hat's supported distribution of the open source Keycloak project, and it replaces Red Hat Single Sign-On. The move is therefore to a different runtime and deployment model. Sign-in no longer runs inside JBoss EAP, so the server, its configuration, its build and startup steps, and its container or OpenShift deployment all change. Red Hat's product page listed version 26.6 as the latest release at the time of research, so confirm which target version you will deploy against. Confirm the exact supported upgrade path in Red Hat's current migration guide for the Red Hat build of Keycloak. Check which source versions can move directly, which need intermediate steps, and which configuration items the guide says must be changed by hand. Your plan should follow that guide, and any deviation should be reviewed with Red Hat support or your partner before it reaches production.
The database decision affects effort early. Keycloak supports several production databases, including PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database, Amazon Aurora PostgreSQL and Azure SQL, while the dev-file database is for development only. If your Red Hat SSO deployment uses a database that is not on the production list for your target version, the migration also includes a database change. Keycloak migrates its schema automatically at startup by default. The upgrading guide suggests manual migration, where administrators apply the SQL themselves, for large deployments. That choice changes your change-control steps, your rollback plan and who must approve each step, so decide it before the test plan is written.
Custom providers and themes are the most likely source of rework. Authenticators, event listeners, user storage providers and themes written for the old runtime must be rebuilt and retested against the new server, and their interfaces may differ. Client configurations also need review, including redirect URIs, token lifetimes and logout behavior. Test each application for sign-in, token refresh and logout before cutover. If your target is the Keycloak 26.8 line or later, review its upgrade notes first. They cover enforced SMTP StartTLS without plaintext fallback, mandatory signature validation of backchannel logout tokens from external providers, and login failures persisted to the database by default. Each of these can break a working integration if your settings or partners rely on the old behavior.
Which Red Hat SSO 7.6 features map to the Red Hat build of Keycloak?
This table pairs each Red Hat SSO 7.6 capability with its closest equivalent in the Red Hat build of Keycloak and notes whether it usually carries over, needs rework, or must be re-verified against the target version. Treat the notes as a starting checklist, and confirm each row against Red Hat's migration documentation before you assume it carries over.
| Source capability (RH SSO 7.6) | Target equivalent (build of Keycloak) | Migration notes |
|---|---|---|
| Realms | Realms with their own users, clients, roles and settings | Usually carries over. Re-verify token lifespans, password policies and other realm-level settings in the target admin console. |
| OIDC and SAML clients | OpenID Connect and SAML 2.0 clients in each realm | Usually carries over, but redirect URIs, client secrets and SAML signing keys need re-verification. Confirm the client settings with Red Hat's guide. |
| LDAP, Active Directory and Kerberos federation | User federation providers for LDAP, Active Directory and Kerberos | Needs rework review. Re-verify bind credentials, sync schedules, mappers and Kerberos keytab settings before assuming they carry over. |
| Identity brokering and social providers | Brokering with OIDC, OAuth and SAML providers, plus social providers such as Google and Microsoft | Usually carries over, but redirect URIs and first-login flows must be re-tested. Confirm each provider's configuration in the target guide. |
| OTP and WebAuthn | OTP policies, W3C WebAuthn, passkeys and recovery codes | Re-verify required actions and enrolled credentials. Confirm how existing OTP and WebAuthn registrations behave after the move. |
| Admin console and REST API | Admin console and the Administration REST API | Needs rework for scripts and automation that call the API. Re-test them, and serve the admin console on a separate hostname from public URLs. |
| Themes and custom providers | Themes and custom provider packaging for the target distribution | Needs rework. Rebuild and retest custom providers and themes against the target version, since packaging and APIs may differ. |
| Database | Supported production databases, including PostgreSQL 14 to 18 | Re-verify the schema migration. Keycloak migrates the schema at startup by default, or administrators can apply the SQL manually for large deployments. |
Which documented import and migration paths can teams use?
Four documented paths can move Red Hat Single Sign-On 7.6 configuration and data toward the Red Hat build of Keycloak, and each moves a different part of the system. Most migrations combine them: the migration guide sets the order, realm import or Operator resources declare configuration, and the database step changes the schema.
Red Hat migration guide for 7.6
The Red Hat migration guide covers the path from Red Hat Single Sign-On 7.6 to the Red Hat build of Keycloak and should set the order of your steps. Use it to identify which configuration, database and provider changes apply to your 7.6 deployment. Red Hat's product page lists 26.6 as the latest build version, so confirm that the guide matches the version you plan to deploy and check each step against it before scheduling work.
Realm import with KeycloakRealmImport
When the Keycloak Operator manages the target deployment, a KeycloakRealmImport custom resource can import a realm definition exported from the source. Test it on a non-production copy to see which realm settings, clients, roles and groups arrive intact. Confirm whether users, credentials and client secrets are included in your export for the target version, since these usually need a separate plan for passwords, hashes and secret values.
Database schema migration at startup or by SQL
Keycloak migrates its database schema automatically at startup by default. The upgrading guide suggests manual migration for large deployments, where a database administrator reviews and applies the SQL outside the startup window. Schema migration changes the structure of the database you already use and does not copy data to a new one. Confirm whether 7.6 requires intermediate upgrade steps, back up the database first, and rehearse the change on a copy.
Operator client resources for OIDC and SAML
The Keycloak Operator manages KeycloakOIDCClient and KeycloakSAMLClient resources, so teams can declare client definitions in version control instead of recreating them by hand in the admin console. These resources define clients you rebuild, but they do not carry over existing client secrets or runtime state from the 7.6 server. Confirm which fields each resource supports in the Operator version you install, and set the Operator to manual approval for updates.
Assets none of the paths move
None of these paths moves custom providers, themes or other deployed code. Expect to rebuild custom providers and retest themes against the target distribution, and plan the review of any extension that depends on removed or changed behavior. Password hashes, client secrets and signing keys also need explicit handling. Inventory custom code, secrets and certificates before the migration starts, and confirm with the migration guide and your export which of them carry over.
What changes in Keycloak 26 that affects a migrating team
Moving from Red Hat SSO 7.6 to Red Hat build of Keycloak crosses more than a product name. The upstream project changed its release model with Keycloak 26.0. Since then it has planned four minor releases a year and a major release every two to three years, and it states that breaking changes in a minor release will be opt-in. Behavior changes can therefore arrive in a release your team adopts deliberately, or in one it adopts on a routine schedule without reading the notes. Treat the target version as a decision with its own test cycle, and read the upgrade notes for every minor release between your current baseline and the one you choose.
Plan the migration against the build your subscription covers. The current upstream release is 26.8.1, published October 13, 2026, but the Red Hat product page showed 26.6 as its latest version when this was researched. Red Hat may trail upstream, so the upgrade notes you read must match the build you will actually run. Confirm with Red Hat which build version your subscription includes, whether that build is the one you will deploy, and how long your chosen line receives fixes. Record the answer in the migration plan before any test environment is built.
The 26.8 upgrade notes show the kinds of change to test for. First, SMTP StartTLS is enforced with no plaintext fallback, so any realm mail settings, relays or scanners that assume unencrypted delivery will break password reset and verification emails. Second, mandatory signature validation now applies to backchannel logout tokens from external providers, so every brokered identity provider that sends logout tokens needs its signing keys and metadata checked before cutover. Third, login failures are persisted to the database by default, which adds write load and table growth that your database sizing and retention settings must account for.
The fourth item is the recommendation to move from the deprecated multi-site feature to the stateless feature. If your current deployment spreads sites with a separate Infinispan cluster per site, record that decision early, because it shapes database replication, cache design and the Operator resources you build. Keycloak's high availability guidance says its supported designs need a synchronously replicated database. Confirm with Red Hat's documentation for your build how the stateless feature is supported there before you commit to a target architecture.
Run each item against a copy of production configuration before cutover. Send a test email through the production relay with StartTLS enforced, trigger a logout from each external provider that sends logout tokens, and generate failed logins at a representative rate to measure database growth. If your target build is older than 26.8, these changes may not appear yet, but the same settings will be tested again when you move up within the 26 line, so record the results now.
How should a team sequence inventory, pilot, parallel run and cutover?
This sequence moves a Red Hat Single Sign-On 7.6 estate to Red Hat build of Keycloak through five gated stages, each producing a record the next stage depends on. Each stage ends on a decision that an accountable owner signs off, so cutover happens only after the team has tested what it will switch.
Inventory realms, clients and custom code
The team lists every realm, client, user federation link, identity broker, authentication flow, custom provider, theme and piece of custom code on the 7.6 server. It also records the database engine, its size and its backup state, and confirms that a recent backup can be restored. The output is a migration inventory with an named owner for each client and a decision for each custom artifact: carry over, rebuild or retire. The step ends when application owners have signed the inventory.
Stand up a pilot realm on the target
The team picks one non-critical realm and recreates its configuration on a Red Hat build of Keycloak environment kept separate from production. Clients, roles, authentication flows and, where policy allows, an exported set of users are copied across. Custom providers and themes are rebuilt and tested against the target before anyone relies on them. The step ends when sign-in, token issuance and administrative tasks pass a written checklist and the team can reproduce the pilot configuration from an export.
Run both systems in parallel
The 7.6 server and the target stay active at the same time, and test copies of each client are pointed at the target. The team runs login with each enabled authentication method, password reset, token refresh, front-channel and back-channel logout, and claim mapping, then compares the tokens each system issues for the same user. It also checks identity brokers and user federation sync. The team agrees in writing how user changes made during the run are handled. The step ends when every in-scope client passes the test matrix.
Cut over with proxy and issuer updates
The team switches DNS or the reverse proxy to the target, then updates redirect URIs and issuer references in each application's configuration. The administration console and Administration REST API stay on a separate hostname or path from public frontend URLs, with TLS on all traffic. The rollback plan names the trigger conditions, the person who decides to roll back, and the steps to point traffic back to the 7.6 server. Confirm with the DNS or proxy owner how quickly the change propagates. The step ends when sign-in and logout succeed for every in-scope client on the live path.
Retain the old system, then retire it
After cutover, the 7.6 system stays online in read-only mode for a retention period agreed before cutover, set by your records and audit policy. The team keeps a final database backup, a configuration export and the cutover records in a location the old system no longer serves. When the period ends, the team removes the DNS records, service accounts and credentials that pointed at the old system, then archives the retirement record. The step ends with a signed retirement record that names the owner and the date.
Database, OpenShift and high availability decisions before cutover
Start by confirming that the database behind your Red Hat SSO 7.6 deployment appears on Keycloak's supported production list. That list includes MariaDB, Microsoft SQL Server, MySQL, Oracle Database, PostgreSQL 14 to 18, EnterpriseDB Advanced, Amazon Aurora PostgreSQL and Azure SQL. Check your exact engine version against the range as well, because a supported engine on an older version still needs a plan. If your current database is outside the list, the move is also a database migration and should be scoped as one. The default dev-file database is for development only, so every production test environment should run against a supported database from the first day. Confirm with Red Hat which database versions the target release supports, since your subscription documentation determines what Red Hat will support in production.
Next, decide who applies database schema changes. Keycloak migrates its schema automatically at startup by default. It also supports manual migration, where administrators apply the SQL themselves, and the upgrading guide suggests manual migration for large deployments. Automatic migration keeps the procedure short, but the schema change then runs during a pod start that your change window may not have planned for. Manual migration gives your database administrators a reviewable script, a clear rollback point and a window that matches your change calendar. Whichever you choose, take a verified backup, rehearse the migration on a copy of the production database and record the schema state before and after. Review the upgrading guide for every schema change between your 7.6 baseline and the target release, because that list is what your database administrators will need to sign off.
Choose a high availability architecture before you size the database or the cluster. Keycloak documents three. The first is a single cluster, optionally spread across availability zones. The second is multi-cluster deployment (v2), which does not use an external Infinispan cluster. The third is multi-cluster v1, which uses a separate Infinispan cluster per site and is deprecated. Both supported designs require a synchronously replicated database, so the database topology must be settled during cutover planning. Confirm that your database platform can provide synchronous replication across the zones or sites you intend to use, and test failover of that replication before you rely on it. The 26.8 upgrade notes recommend moving from the deprecated multi-site feature to the stateless feature, so if your 7.6 design used multi-site, plan that change within the migration window.
On OpenShift, the Keycloak Operator is the path most teams take. Install it through Operator Lifecycle Manager, which is the recommended method, or with kubectl. An experimental Helm chart also exists, so confirm its support status with Red Hat before using it for a regulated production cutover. The Operator manages Keycloak, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient custom resources, so realm and client definitions can live in version-controlled manifests. Set the Operator subscription to manual approval mode. The Operator documentation strongly recommends this to avoid unintended automatic upgrades, and it means each Keycloak version change passes through your change board. Decide the namespace layout, the handling of database credentials in secrets and the owner of Operator upgrades before the first deployment is built.
Before cutover, turn the production guidance into a checklist that reviewers can test. First, use TLS on all communication, including traffic between Keycloak and the database and between Keycloak and the reverse proxy, with certificates your team can rotate. Second, place a reverse proxy with path restrictions in front of Keycloak so that only the paths your applications and users need reach the public hostname. Third, expose the admin console and Administration REST API on a separate hostname or context path from public frontend URLs, and limit that hostname to administrator networks. Test each item from outside the trusted network and keep the results as evidence. This evidence helps prepare for a compliance assessment, but independent auditors and certification bodies issue the assessment itself.
What drives the cost and duration of a Keycloak migration
This table lists the factors that change the scope of a move from Red Hat Single Sign-On 7.6 to Red Hat build of Keycloak, with what each one means and what to ask for in a quote. Use it to inventory your current deployment before requesting a proposal. DeployOpen does not publish prices, so a quote follows from the written scope, and the main takeaway is that a complete inventory of realms, custom code and database state makes that scope easier to agree.
| Driver | Why it matters | What to ask for in a quote |
|---|---|---|
| Realms, clients and protocol mix | Each realm and client needs mapping, testing and sign-off. SAML clients and OIDC clients follow different configuration and test paths. | A count of realms and clients by protocol, a named owner for each, and the test cases included per client type. |
| User federation and brokering links | LDAP, Active Directory, Kerberos and external identity brokers each need connection settings, mapper checks and login tests after the move. | Confirmation of every federation provider and identity broker in scope, plus whether directory connectivity is tested from the target network. |
| Custom SPI providers and themes | Custom providers and themes written for the Red Hat SSO build may need rebuilding and retesting against the Red Hat build of Keycloak packaging. | A list of each provider and theme with its source location, build method, and whether the work includes rebuild and regression testing. |
| Deprecated client adapters still in use | WildFly, servlet and Spring adapters must be replaced with standard OpenID Connect libraries. This work usually sits in the application teams and can run in parallel with server work. | Which applications still use adapters, whether application code changes are in scope or left to your teams, and who tests token handling. |
| Database size and migration approach | Schema migration runs automatically at startup by default. Large databases may need manual SQL review, backups and a rehearsed rollback. | Database engine and version, data volume, the chosen migration method, backup and restore testing, and the maintenance window assumptions. |
| High availability design | Clustered and multi-site designs need a synchronously replicated database. The multi-cluster v1 design is deprecated, and the 26.8 notes recommend moving from multi-site to the stateless feature. | The target topology, whether a move to the stateless feature is in scope, and the failover tests included in the work. |
| Number of environments | Each environment needs its own configuration, secrets, realm exports and sign-off. Promotion between them is often the largest repeated effort. | The count of environments in scope, how configuration is promoted (manual or operator-managed), and which environments receive full test runs. |
| Monitoring and logging integrations | Metrics exposed at /metrics on the management interface and log pipelines must be reconnected and checked after cutover. | Which monitoring and logging tools are in scope, whether dashboards and alert rules are rebuilt, and who owns them after handover. |
| Logout and token handling tests | The 26.8 notes make backchannel logout token signature validation mandatory for external providers. Logout and token behavior need explicit test cases per application. | The number of applications covered by logout and token tests, the test environments used, and whether test evidence is delivered in writing. |
What usually goes wrong in an SSO migration and how to prevent it
Most SSO migration failures trace to a few decisions made too late: which clients still depend on old adapters, which URLs and issuers change at cutover, and where user data is written during the move. Each card below names one failure pattern for this migration and the prevention step that belongs earlier or later in the sequence.
Applications still on deprecated adapters
Applications that still use the deprecated Keycloak WildFly, servlet or Spring adapters are likely to break once the server changes, so they should not be carried into the target unchanged. Inventory every client before cutover and record the adapter, framework and version each one uses. Move those applications to standard OpenID Connect libraries in a staging realm, and test token validation and logout there before the server upgrade begins.
Redirect URIs and issuer URLs
Redirect URIs, web origins and the issuer URL stored in each client usually change when the hostname, path or reverse proxy changes at cutover. A client that validates the issuer against an old stored value will reject tokens from the new server, and a redirect URI that does not match exactly will stop sign-in. Production guidance keeps the admin console and Administration REST API on a separate hostname or path from public frontend URLs, so confirm which address each client should see. Prepare the new values in advance and rehearse the change in staging.
Custom providers and unplanned upgrades
Custom authenticators, user storage providers, event listeners and themes built for the older server may fail to load on the target until they are rebuilt and retested. Confirm each provider in a staging deployment before cutover. Also set the Operator update mode before go-live, because the Keycloak Operator documentation strongly recommends manual approval to avoid unintended automatic upgrades. Record the target version in the change plan so a later update cannot move the server without review.
Sign-in failures after credential or MFA changes
Users who enrolled OTP or WebAuthn credentials on the old server may face unexpected required actions or policy differences on the new one. Verify sign-in with a pilot group that includes users with OTP, passkeys and recovery codes. Confirm which required actions and authentication flows the target realm applies, and keep a support path for locked accounts. Announce any enrollment window to users before cutover, because a policy change affects every user at once.
Backchannel logout from external providers
The Keycloak 26.8 upgrade notes make signature validation of backchannel logout tokens from external providers mandatory. A partner that signs with a key the realm does not trust, or sends a token in a format the realm rejects, will cause logout to fail. Before cutover, collect the signing keys and token details from each external provider, load them into the target realm, and test logout from every connected application. Keep the existing logout path available until those tests pass.
Replica lag and rollback data
Both supported high availability designs need a synchronously replicated database, and an unsynchronized replica can serve out-of-date user or session data during the move. A rollback also fails when users, sessions or credentials were written only to the new system, because the old server cannot read them. Freeze user-data changes during the window, confirm replication is current before cutover, and decide in advance what a rollback would discard. Take a database backup before the schema migrates, since migration runs at startup by default unless you choose manual migration.
What do buyers ask before they hire help for a Keycloak migration?
What drives the cost of a Keycloak migration engagement?
Cost follows the written scope. The main drivers are how many realms, clients, identity sources and custom providers or themes must move, and how much testing and cutover support the plan requires. DeployOpen works under fixed-scope agreements, so the quote lists deliverables, responsibilities and timelines before work starts.
Separate two cost types when you compare bids:
- One-time: planning, configuration move, custom provider work, testing and cutover support.
- Recurring: ongoing support, upgrades or continuous testing, which DeployOpen offers as a retainer.
Internal costs also count: staff time from identity and application teams, test environments, and infrastructure you already pay for. Ask every bidder to itemize who performs each task, what is excluded, and what triggers a change request.
How long does a Keycloak migration from Red Hat SSO take?
Duration depends on the scope drivers, so no single timeline fits every Keycloak estate. The biggest factors are the number of applications to re-test, how many identity sources are federated, whether custom providers need rebuilding, the target database and deployment platform, and how many change windows your organization allows for cutover.
Your team's availability for reviews and test cycles also sets the pace. Ask for a plan with milestones, dependencies on your teams and the number of test cycles built in. The written plan is where the timeline is confirmed, and any scope change should trigger a revised timeline before work continues. Treat any estimate given before the configuration inventory is complete as provisional.
What does our team need to provide during a Keycloak migration?
The work depends on your people and access as much as on your budget. Four items matter most:
- Inventory access to the current deployment, including realms, clients, identity providers, user federation settings, themes and custom code.
- Test users and test applications that reflect real sign-in paths, including logout.
- Change windows for staging and production cutover.
- Named owners for identity and for each application that depends on Keycloak.
Identity owners approve configuration decisions, application owners verify token handling and logout, and someone must have authority to make the go or no-go call at cutover. Confirm these owners and access points in the written scope, because the plan cannot proceed without them.
Can our own team migrate Keycloak without an outside partner?
Yes, if your team already has working Keycloak and database skills and a written test plan. In practice, that means people who can read and change realm, client and provider configuration, who understand how your chosen production database is administered, and who can run the upgrade in staging and reproduce the result.
Your test plan should cover sign-in and sign-out for every client, token claims, federated and brokered logins, admin console access, and a tested rollback procedure. If a skill area is thin, a partner can cover that task alone, such as inventory, custom provider rebuilds or cutover support, without taking over the whole migration. Decide this area by area during planning.
Does DeployOpen issue audit attestations for Keycloak migrations?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.
During a migration, useful evidence includes configuration baselines before and after the move, access control settings for realms and admin roles, authentication policy records, change logs for each cutover step, and test results tied to your requirements. Ask in the written scope which evidence will be delivered, in what format, and who keeps it. Your compliance lead should confirm with your assessor which artifacts they expect before the migration starts, so evidence is captured as the work happens.
What should a written Keycloak migration scope include?
A written scope should name every item the work covers and every item it excludes. List the current deployment and target platform, the production database, each realm with its clients and identity sources, custom providers, themes, scripts or extensions, and the applications that must be re-tested.
Add the migration approach, including whether the database schema migrates automatically or manually, the cutover and rollback plan, and the test cycles. State deliverables, acceptance criteria, client responsibilities, named owners, meeting cadence, and how scope changes are priced and approved. Also list the documents you will receive, such as runbooks and configuration records. A scope without these items makes quotes hard to compare.
Should we let Keycloak migrate its database schema automatically at startup?
Keycloak migrates its database schema automatically at startup by default. It also supports manual migration, where administrators apply the SQL themselves, and the upgrading guide suggests manual migration for large deployments.
Automatic migration is simpler for smaller estates, but problems surface during startup, when you have less room to review them. Manual migration gives your database team review time and a chance to test the SQL against a copy of production data. Choose the approach during planning, record it in the runbook, and rehearse it in staging with a database copy that matches production as closely as your policies allow. The choice affects your cutover window, rollback procedure and who signs off the change.
How DeployOpen works on this
DeployOpen scopes the move from Red Hat Single Sign-On 7.6 on JBoss EAP to Red Hat build of Keycloak as a written, fixed-scope engagement, with the target version, database, deployment model and provider inventory agreed before work starts. Delivery covers the build, testing, documentation and handover inside your own infrastructure, and ongoing support is available as a retainer.
How we scope
- The written scope lists the 7.6 realms, clients, federation links, themes and custom providers in play.
- Scope also fixes the target Red Hat build of Keycloak version, confirmed with Red Hat before the build starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- Database steps use one of Keycloak's supported production databases, with the schema migration rehearsed first.
- The deployment design follows Keycloak's high availability options, with a synchronously replicated database for clustered setups.
- OpenShift deployments use the Keycloak Operator, with manual approval mode for operator updates.
How we hand over
- Handover covers configuration exports, runbooks, the migration record and verification results.
- Production hardening follows Keycloak's guidance: TLS everywhere, a reverse proxy with path restrictions, and a separate admin hostname.
- Prometheus-format metrics are enabled at /metrics on the management interface for your monitoring team.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after cutover.
- Post-cutover planning covers the 26 line's four minor releases a year and the opt-in handling of breaking changes.
- Upgrade notes for each release are reviewed, including the 26.8 changes to SMTP StartTLS and backchannel logout validation.
