B2B CIAM · User Migration into Orgs
Every user in the right org, without a password reset
We migrate users from your legacy store or current IdP into Keycloak organizations one customer at a time — importing password hashes where possible, recreating memberships, roles, seats and resource grants, and reconciling everything before each org cuts over.
- Password hashes preserved
- Org-by-org cutover waves
- Reconciled across every store
Standards & integrations
- Keycloak Admin REST API
- Password hash import
- User Storage SPI
- OpenFGA
- JSON Schema
- PostgreSQL
Overview
Migration is more than moving passwords
A user record is only useful in context: the organizations it belongs to, its role in each, the seats it holds and the resources it can reach. We normalise every legacy source into one canonical record, import users with their password hashes when the algorithm allows, then create memberships, seats and OpenFGA tuples — each step idempotent, resumable and tagged with its batch, so a wave can be rolled back precisely.
What we deliver
- Canonical migration schema and validation rules
- Migration service with staging database and control API
- Bulk import runner and lazy-migration provider
- Membership, role, seat and OpenFGA linkers
- Reconciliation reports per organization
- Wave plan, cutover runbook and rollback procedure
Capabilities
What User Migration into Orgs covers
Configured, tested and documented on upstream Keycloak — then handed over or operated by us.
Bulk import with hashes
Users arrive with their existing password hashes when Keycloak supports the algorithm natively, such as PBKDF2 and Argon2; other formats get a custom password hash provider.
Lazy migration fallback
When hashes can't be exported, a custom user storage provider checks passwords against the legacy system on first login and migrates the user.
Memberships and roles recreated
Each user joins the right organizations with the right roles before the organization's cutover date.
Careful duplicate handling
Legacy rows for the same person merge into one Keycloak user with several memberships — by verified email only; unverified duplicates go to review.
Resumable, auditable batches
Per-record state machines, retries and a control API let operators pause, retry and roll back any batch.
Reconciliation
Source, Keycloak, entitlement seats and OpenFGA tuples are compared for every organization before and after cutover.
Strategies
Choosing a migration strategy
The right approach depends on whether password hashes can be exported and how long the legacy system stays online.
| Strategy | How it works | Use when |
|---|---|---|
| Bulk import with hashes | Users imported with existing hashes; memberships created before first login | Default, when hashes are exportable |
| Bulk import without passwords | Profiles imported; users set a password or go passwordless | Hashes unavailable or insecure |
| Lazy migration | Custom user storage provider checks the legacy system on first login | Hashes not exportable and the legacy system stays online |
| Hybrid | Bulk for active users, lazy for the rest, a final sweep for stragglers | Large, messy user bases |
How it works
From first call to production
Extract and validate
Legacy data is normalised into canonical records, validated, deduplicated and mapped to organizations and roles in a staging database.
Rehearse, then pilot
A full dry run in a staging realm, followed by two or three friendly customer organizations.
Migrate in waves
Each organization is frozen, delta-extracted, imported, linked, verified and switched over, with a precise rollback per wave.
Use cases
Where teams put it to work
Moving off Auth0, Cognito or a home-grown store
Users move into Keycloak organizations with their passwords and access intact.
Consolidating per-customer user tables
Legacy systems that kept one user row per customer become one identity with several memberships.
Customers moving to SSO
Users of customers with their own IdP are linked on first SSO login instead of receiving passwords.
FAQ
User Migration into Orgs questions, answered
Will users have to reset their passwords?
Not if the legacy hashes can be exported in an algorithm Keycloak supports, or one we add through a custom password hash provider. If they can't be exported, lazy migration checks passwords against the old system on first login.
How are password hashes kept safe during migration?
Hashes are encrypted at rest in staging, access-restricted, and purged once each batch completes.
Can we roll back a customer's migration?
Yes. Memberships, seats and tuples are tagged with their batch, so a wave can be reversed precisely and the organization switched back to the legacy login while issues are fixed.
Ready to roll out User Migration into Orgs?
Walk us through your requirements on a free strategy call. We'll come back with an architecture, a delivery plan and a fixed scope.