Migrate from Keycloak and stop operating your own identity server
The Skycloak Platform is built to let you migrate from Keycloak by importing a realm's users with their passwords, MFA and passkeys, and by serving Keycloak-compatible addresses and token shapes so your applications keep working. Nobody resets a password on the day of the move, and a tenant can be exported back to a Keycloak realm file, so the move can be reversed.
Why teams move off a Keycloak server they run themselves
Keycloak is a capable open source identity server, and many teams start with it because it covers sign-in, single sign-on and user management in one place. Running it in production is a different job, because someone has to apply security patches, plan major version upgrades, size the servers and look after the database it depends on. That work never stops, and it usually lands on engineers who were hired to build the product. When the identity server turns into a part-time job for one or two people, moving to a service starts to make sense.
The Skycloak Platform is Skycloak's own multi-tenant sign-in engine, run by Skycloak as a service, so the upgrades, the database and the patching are no longer your team's job. A Keycloak realm maps to a tenant, which has its own users, settings and sign-in address. Tenants run in the United States or the European Union, and the region is fixed when the tenant is created, so you choose where your users' records live. The console that configures tenants holds no end-user data and sign-in never waits on it, so sign-in keeps working even if the console is down.
What the import carries over and how applications keep working
The Platform is built to import a realm's users together with their password hashes, their multi-factor authentication (MFA) settings and their passkeys. A password hash is the scrambled form of a password that an identity server stores instead of the password itself, and importing it lets users keep signing in with the password they already know. Because MFA and passkeys come across too, users do not have to enrol a second factor again, and nobody has to reset a password on the day you switch. Passkeys are tied to the domain they were created for, so decide early which sign-in domain your users will see after the move.
Your applications talk to Keycloak through addresses such as its authorization and token endpoints, and they read tokens with a particular set of claims. Claims are the fields inside a token, such as the user's ID or roles. The Platform serves Keycloak-compatible addresses and token shapes, so an application that worked against your realm can keep working once you point it at the tenant, without rewriting its token checks. You still test each application before the switch, but the work is mostly configuration rather than code.
How to plan the cutover and keep the move reversible
A cutover is the moment your applications stop using the old server and start using the new one. A careful plan imports the users into a staging tenant first, points a test copy of each application at it and checks sign-in, MFA, passkeys and token checks from end to end. Once that works, you import production, switch each application's configuration and keep the old server available for a while in case you need to switch back. Users who change their password between the import and the switch need the most attention, so keep that window short or run the import again just before you switch.
The Platform is built to export a tenant back to a Keycloak realm file, the same format Keycloak uses to import and export a realm. That makes the move reversible: if the Platform turns out not to fit, you can take your tenant back to a Keycloak server you run yourself. The import, the compatible addresses and the export are all on the Platform's plan, and a demo is the place to see which of them you can use today.
Frequently asked questions
Will my users have to reset their passwords?
No. The Platform is built to import a realm's users with their passwords, MFA and passkeys, so they keep signing in with the credentials they already have.
Do I have to change my application code?
In most cases you change configuration rather than code. The Platform serves Keycloak-compatible addresses and token shapes, so an application mainly needs to be pointed at the tenant. Test each application against a staging tenant before you switch.
See the Skycloak Platform for yourself
Book a demo and we will walk you through the Platform with your own sign-in flows in mind.