6 posts tagged with "migration"

A slow migration moves users from a legacy system into Keycloak one at a time, as each of them logs in. It goes by other names too: lazy migration, just-in-time (JIT) migration, trickle migration. Nobody gets a password reset email, there is no cutover weekend, and users who never come back are never migrated.

The other side is a fast migration: a bulk import that moves every user into Keycloak at once, before or at cutover. It is quicker to finish and easier to reason about, but it needs something a slow migration doesn't, usually the users' password hashes.

Keycloak doesn't ship slow migration. You add it with a user storage provider, and the one almost everyone uses is open source on GitHub: daniel-frak/keycloak-user-migration. This post covers how slow and fast migrations work, where the code lives, how to choose, and how to combine the two so a slow migration doesn't drag on for months.

Azure AD B2C's end of sale means Microsoft stopped selling it to new customers on 1 May 2025 and committed to supporting it until at least May 2030. It is not being shut down. Existing customers keep their tenants, can still create new ones, and keep the SLA, the security updates and the compliance posture. What ended is the roadmap.

One other date is doing a lot of damage. Premium P2 was discontinued on 15 March 2026 for all customers, and tenants moved to P1. That is a pricing-tier retirement, not a tenant retirement — but it has been reported often enough as "B2C shuts down in March 2026" that it is worth saying plainly: your tenant is fine, and you have roughly four years to make a decision rather than four months to execute one.

Four years is enough time to make a good decision and short enough that the one you make now is the one you live with. Here is what the three realistic destinations actually cost.

The login page is the most attacked page on an online store, and it is rarely the one anyone designed for attack. Homegrown e-commerce login usually starts as a users table, a bcrypt column and a session cookie, and it grows a password reset, a mobile API, a trade-account flag and a social button over the years. What it almost never grows is a defense against credential stuffing: automated replay of email and password pairs leaked from other sites, aimed at whichever of your customers reused one. Replacing homegrown login with Keycloak gives a store one identity service for web, app and back office, with social login, B2B accounts and branded pages built in, and you can move customers onto it without asking anyone to reset a password. It does not make the login page safe on its own. The defaults leave doors open that attackers look for first, and the rest of this post covers both halves: what you gain, and what has to be layered on top.

Migrating from Okta to Keycloak is not a user migration. The users are the easy part: Okta's Users API hands you profiles and group membership, and Keycloak's partial-import endpoint takes them. Two other things decide how long this takes. Okta will not give you password hashes — they are an import-only field, so every user either resets a password or authenticates through Okta one last time while you drain. And every SAML and OIDC application has to be re-pointed by hand, one at a time, because the assertion consumer URL, the entity ID and the signing certificate all change when the identity provider does.

So the schedule is set by the app inventory, not by the user count. A thousand users is one afternoon. Forty SAML apps is a quarter. Everything below was run against Keycloak 26.8.1 in start-dev, and the Okta side is from Okta's published API specification, read on 2026-10-19.

Migrating from Auth0 to Keycloak is three separate jobs wearing one name. Profiles move easily — Auth0's export job gives you newline-delimited JSON and Keycloak's partial-import endpoint takes it. Passwords do not move at all: Auth0 hashes with bcrypt, Keycloak 26.7.4 ships four password-hashing providers and none of them is bcrypt, so you either reset every password or stand up a bridge that verifies against the old hashes on first login. Your Rules and Actions have to be rewritten, because there is no equivalent runtime — some of them become authentication-flow configuration with no code at all, and some become a Java SPI.

The part that costs people a weekend is none of those. It is that Keycloak's admin API answers 201 Created to three different malformed migrations and then quietly loses the data. Everything below was run against Keycloak 26.7.4 on PostgreSQL 16.

A few quarters ago you got handed a single-line ask: "we need enterprise SSO and directory sync by the end of the quarter." Maybe the deal was a Fortune-500 logo. Maybe it was a Series B requirement. Either way you found WorkOS, wired in their SDK in a long weekend, shipped the deal, and got the high five.

Then the renewal came in. The seat-based pricing, that sounded harmless when you had two customers using SSO, looks different when you have forty. Suddenly there's a line item on a board slide that scales linearly with your enterprise revenue — a parasite that eats into the very margin that the enterprise tier was supposed to fund. The CFO walks over and asks you to "fix it."

Here is the awkward truth nobody tells the engineer-on-the-spot: the WorkOS feature set has had a fully open-source equivalent for years. Keycloak handles SSO. Phase Two's organizations extension handles multi-tenant orgs. The identity provider wizard handles the same admin-portal flow your customers see in WorkOS today. The catch is that nobody wanted to spend the runway to migrate.

We've now built the tool that turns that "we'll deal with it later" debt into an afternoon of work. Why? Because WorkOS customers are starting to wake up to Keycloak, and they're coming to us in droves.