What an authentik migration involves
A migration to authentik moves more than user accounts. The work covers identities, groups and group membership, stored credentials, MFA enrollments, and the protocol configuration of every application that relies on the current identity platform. Each relying application has its own client IDs, redirect URIs, signing certificates, claim mappings, and token lifetimes. Those settings must be recreated as authentik providers and applications, and each one has to be tested against a real sign-in. An export of users alone leaves most of the work undone.
The usual triggers are a license cost change or renewal at Keycloak, Okta or Auth0, the end of support for the current platform version, a plan to consolidate a legacy LDAP directory, or a decision to leave a SaaS tenant for infrastructure the organization controls. Each trigger sets a different deadline and a different risk appetite. Confirm early which dates are fixed, which applications can tolerate a parallel run, and whether any application still binds to LDAP directly, since those bind flows need their own plan.
Teams with prior identity work can often handle parts of the migration in house, such as inventorying applications, mapping groups to roles, and building authentik flows for a pilot app. Cutover planning and password handling are where outside help usually pays off. Passwords cannot be copied between most platforms in a readable form, so the team must decide whether to migrate hashes, force resets, or use a staged approach, and each choice affects users and rollback. Ask any partner to show how they would plan the cutover order, the fallback path for each app, and the evidence they will keep for each step.
What the migration work includes
The migration breaks into seven work packages, each with a defined output. Together they move users, groups and application integrations from the source platform to authentik without a single unplanned cutover.
Source inventory and mapping
We list every realm, tenant, client, scope, group and LDAP bind account on the source platform, then map each one to an authentik provider, application, flow or policy. Unmapped clients are the most common cause of late surprises, so the inventory is signed off by application owners before any data moves. Check that the inventory includes clients that no longer appear in active use.
User and group import with identifiers preserved
Users and groups are imported with their original subject identifiers, usernames and email addresses where the target allows it, so applications that key accounts on those values keep working. Group memberships are rebuilt as authentik groups and checked against the source. Confirm early which identifier each relying application stores, since changing it breaks existing account links.
Credential migration approach
Password hashes are imported where the source exports them in a format authentik can verify, so users keep their passwords. Where hashes cannot be exported, the team chooses between progressive migration, which upgrades each hash at the next successful login, and a forced reset. Ask the source vendor which hash algorithms and export methods apply to your tenant or realm.
Protocol remapping for OIDC, SAML and LDAP
Each client is rebuilt as an authentik OAuth2/OIDC, SAML or LDAP provider with the redirect URIs, scopes, claims, signing certificates and attribute names the application expects. Claim and attribute mismatches are the usual reason a migrated app fails after sign-in appears to work. Test each client against a non-production copy of the application before cutover.
Staged application cutover
Applications move in waves, starting with low-risk internal tools and ending with customer-facing or regulated systems. Each wave has a go or no-go check, a defined window and named owners for sign-in testing. Keep the source platform running in read-only or parallel mode until the final wave is stable, and confirm that the source does not revoke sessions or tokens mid-wave.
Rollback runbooks
For each cutover wave, a runbook states the trigger for rollback, the DNS, client or proxy changes needed to return traffic to the source, and how user changes made during the window are reconciled. Rollback is rehearsed before the first production wave. Ask how long the source platform will remain available after go-live, because that period sets how far back a rollback can reach.
Handover documentation and admin training
The client receives the mapping register, the migration runbook, cutover and rollback records, and training notes for administrators who will run authentik after the project closes. Training covers flows, providers, outposts and the upgrade process so the team can maintain the configuration without the migration team. Confirm which documents are delivered in your engagement scope before work starts.
What drives cost and duration
This table lists the factors that most change migration effort, why each one matters, and what teams can do before the build starts to keep them under control.
| Driver | Why it moves effort | How to keep it down |
|---|---|---|
| Users and groups | Every user, group and membership must map to authentik objects, and nested or duplicated groups multiply mapping and test work. | Clean duplicate accounts and stale groups in the source before export, and agree a group-to-role model first. |
| Applications and protocols | Each app needs its own provider, redirect URIs, scopes and cutover test, so effort grows with app count and protocol mix. | Consolidate retired apps, group apps by protocol, and fix a cutover order before any provider is built. |
| Source platform export | The effort depends on how much configuration the source can export as data and how much must be rebuilt by hand. | Run a configuration inventory early and confirm with the vendor which realms, tenants, flows or rules export cleanly. |
| Password storage and hash import | If password hashes cannot be exported in a usable format, users must reset passwords or sign in through a bridge, which changes rollout and support load. | Confirm hash export format and algorithm with the source vendor, then decide between hash import, forced reset or staged sign-in. |
| Custom claims and mappers | Token claims, attribute mappings and scripts in the source must be rewritten as authentik property mappings and tested per application. | List every claim each application reads, remove unused mappers, and document the expected token contents for each app. |
| MFA methods and enrollment state | Existing factors may not move with the user, so enrollment rules, recovery paths and help desk steps need design and testing. | Decide which factors carry over, plan re-enrollment windows, and write recovery procedures before cutover begins. |
| Number of environments | Development, test and production each need their own configuration, secrets and validation, and drift between them adds rework. | Keep configuration reproducible across environments and promote changes through the same path each time. |
| Compliance evidence needs | Assessors may ask for access reviews, change records, audit logs and proof of MFA enforcement, which adds documentation and test runs. | Agree the evidence list with your assessor at scoping, and capture it during the build rather than reconstructing it later. |
| Enterprise-only integrations | Entra ID and Google Workspace connectors are listed as Enterprise features, so dependence on them affects licensing and build scope. | Confirm the edition needed for each connector during scoping and include the licensing decision in the written quote. |
Migration phases and outputs
The sequence moves applications from the source provider to authentik in controlled stages, with a named output at each phase so every cutover can be verified and reversed.
Inventory sources and applications
Document every Keycloak realm, Okta or Auth0 tenant, or legacy LDAP directory, along with each client or application, its protocol, redirect URIs, claims, group-based access and dependent users. Your team and DeployOpen review the inventory together. Done when every application has an owner, a protocol and an agreed cutover method in the written scope.
Design the authentik target
Map each source client to an authentik provider (OAuth2/OIDC, SAML, LDAP, proxy or another type), group applications, and design flows for login, MFA and recovery. Decide where outposts run for proxy or LDAP traffic. Output: a target design document listing providers, applications, flows, outposts and rollback paths, approved by your security owner.
Set up the PostgreSQL and hosting baseline
Size the authentik server and worker containers and the PostgreSQL database on infrastructure you control. The Docker Compose guide targets test and small-scale production, with a documented minimum of 2 CPU cores and 2 GB of RAM. For Kubernetes, the Helm chart's bundled PostgreSQL is for demonstration and testing, so production should use a separately managed PostgreSQL. Output: a tested backup and restore.
Import and test users, groups and credentials
Import users and groups into a non-production authentik instance, mapping attributes and group membership from the source. Move password hashes only where the source export allows it and the hash format is supported. Otherwise, plan forced resets or staged enrollment, and confirm the options with the source vendor. Output: a reconciled user count and a signed-off sign-in and MFA test log per application.
Cut over a pilot application
Move one low-risk application first by updating its client settings, redirect URIs and claims to point at authentik. Test sign-in, token refresh, logout and role mapping with a small group of users. Output: a runbook with a tested rollback to the source provider and a go or no-go decision recorded by the application owner.
Cut over applications in staged groups
Move the remaining applications in groups that share risk and dependencies, such as internal tools first and customer-facing or regulated systems later. Each group has a change window, a named rollback owner and monitoring of authentik event logs. Output: a cutover record per group listing completed applications, open issues and the source left in place for rollback until the group is stable.
Decommission the source and hand over
Disable source sign-in for migrated applications, then retire the source tenant, realm or LDAP bind once no traffic and no rollback need remains. Confirm audit log retention, remove unused secrets and service accounts, and transfer runbooks and admin access. Output: a handover pack covering configuration, backups, upgrade ownership and the decommission record.
What goes wrong and how to prevent it
Most authentik migrations stall on identity data and application details rather than on the software itself. Each risk below has a specific check and a prevention step that belongs in the cutover plan.
Password hashes that cannot be exported
Some source platforms do not export password hashes in a form authentik can verify, so users may need a forced reset at cutover. Confirm with the source vendor which hash formats and export options your tenant or realm supports. Prevent surprise lockouts by planning a reset path, a communication schedule and a parallel run where feasible.
Claim and attribute mismatches
Applications often match users on subject identifiers, email addresses or group names, and authentik may produce values that differ in case or format. A mismatch can silently create duplicate accounts or strip permissions. Prevent this with identifier mapping tests that compare each application's expected claims against authentik output for sample users before cutover.
Redirect URIs and signing key differences
Each relying application has registered redirect URIs and trusts specific signing keys or SAML certificates from the old provider. Missing or altered URIs cause login loops, and a changed signing key breaks token validation. Prevent this by inventorying every redirect URI and certificate per application and staging their replacements in the checklist.
MFA enrollment gaps
Users enrolled in the old MFA factors may not carry over, and some factors may need re-registration in authentik's flows. Without a plan, administrators face a flood of help requests or accounts without a second factor. Prevent this by defining which factors migrate, how users enroll, and which high-risk groups must enroll before cutover.
Applications with hard-coded LDAP or SAML metadata
Some legacy applications store LDAP server addresses, bind settings or SAML metadata in local configuration, so they keep pointing at the old identity source after the move. Inventory these applications early, because they often need a configuration change or a vendor-supported update. Prevent surprises with a per-application cutover checklist that names the exact settings to change.
PostgreSQL connection limits under new workload
The 2025.10 release notes warn of roughly 50% more PostgreSQL connections after upgrading, because authentik moved caching, tasks, sessions and WebSocket work into PostgreSQL. Connection limits sized for a previous platform can cause errors under login peaks. Prevent this by load testing against your planned connection limits and reviewing pooling before cutover.
Untested or data-dependent rollback
A rollback plan fails if it was never rehearsed or if users changed data in authentik after cutover that the old platform cannot receive. Define a rollback window during which the source platform stays available, and document how changes made in that window are handled. Rehearse the rollback in a non-production environment before go-live.
What teams keep in-house and what they outsource
This table shows who usually owns each migration task and the skills it needs, so you can decide which parts to keep internal and which to scope with a partner under a fixed-scope agreement.
| Work part | Usual owner | Skills required |
|---|---|---|
| Application owner decisions on claims and session length | Kept in-house: application owners decide, with security sign-off | Knowledge of each app's required claims, roles and session limits; OIDC and SAML basics |
| Identity data cleanup | Kept in-house: identity or HR team, with partner scripts if scoped | Directory data quality, duplicate account rules, user lifecycle and group membership analysis |
| Source platform export and access | Often handed to partner under a fixed-scope agreement, with in-house admin accounts | Keycloak realm export, Okta or Auth0 admin API access, LDAP directory extraction, password hash formats |
| authentik provider design | Often handed to partner, reviewed by the in-house platform team | Provider types (OAuth2/OIDC, SAML, LDAP), flows, property mappings and claim design in authentik |
| Password handling approach | Decided jointly by identity and security teams, with partner advice | Hash migration or forced reset options, password policy, password history; confirm which edition includes it |
| Outpost and PostgreSQL hosting | Kept in-house if the platform team already runs PostgreSQL; often partner-supported otherwise | PostgreSQL operations, backup and restore, container or Kubernetes hosting, outpost placement near applications |
| Cutover scheduling with business owners | Kept in-house: project manager and business owners | Change management, application dependency mapping, user communication and service desk preparation |
| Security review of flows and admin access | Often handed to partner for an independent review, with in-house approval | Flow and policy review, admin MFA design, secret handling, outpost token management |
| Post-cutover support | Often covered by an ongoing retainer or in-house on-call rotation | Log triage, user support runbooks, release tracking, monitoring of server, worker and outposts |
How the work differs by starting point
Keycloak migrations start from realm exports, so the first check is how complete the export is for your setup. Map each realm to an authentik tenant or a deliberate separation plan, then rebuild clients and mappers where protocol details differ.
- Realm and client export: confirm which realms, clients, roles and groups your export covers, and record redirect URIs and client secrets that must be reissued.
- Mapper translation: list each protocol mapper and the claims it emits, then rebuild them as authentik property mappings and check every token claim against the consuming application.
- Custom authenticators and SPIs: identify custom authenticators, event listeners and user storage providers. These do not carry over automatically and each needs an equivalent flow stage or an external service.
- Credentials: ask your Keycloak administrator whether password hashes can be exported in your deployment, and plan forced resets if they cannot.
Okta exports are organized around groups and assignments, so most of the effort sits in access rules and application assignments rather than in user records.
- Group rules: list every group rule and its expression, then decide which become authentik groups, expression policies or static membership, since rule logic does not transfer as-is.
- App assignments: map each assigned user and group per application, including the sign-on policy that applies to it.
- SAML and SCIM apps: collect entity IDs, ACS URLs, signing certificates and attribute statements for each SAML app, and confirm which SCIM connections must be rebuilt on the authentik side.
- Export limits: confirm with your Okta administrator what the user, group and application exports include and whether any export is capped or paginated in your tenant. Reconcile record counts against the source before each cutover.
- Password and MFA: confirm with Okta whether password material can be exported for your tenant. If it cannot, plan resets or staged enrollment and re-enroll MFA factors.
Auth0 tenants combine users, connections and extensibility code, so the migration starts by separating configuration from custom logic.
- Tenants and environments: inventory each tenant and environment, and decide whether each maps to its own authentik instance, a shared instance or a separate deployment.
- Rules and actions: review every rule and action for logic that changes claims, enforces MFA or calls external services, then rebuild each one as a flow stage, policy or property mapping.
- Connection types: list database, social and enterprise connections, and confirm which upstream identity providers can be federated in authentik and which users must re-authenticate.
- Password hash export: Auth0 places restrictions on password hash export, so confirm with Auth0 what your plan and tenant allow before choosing between hash import, forced resets or a staged fallback.
- Metadata fields: check user metadata and app metadata that drive authorization, since each field needs an explicit property mapping.
A legacy LDAP setup usually has no administrative console to export from, so the work starts with the directory schema and the applications that depend on it.
- Schema mapping: map object classes and attributes for users, groups and memberships to authentik fields, and document any custom attributes that applications read.
- Bind accounts: list every service account used for binds, along with its permissions and password policy, and plan replacement bind accounts with only the search permissions they need.
- Applications that bind directly: identify applications that bind to LDAP themselves. Confirm whether each can point at an authentik LDAP outpost endpoint or must move to OIDC or SAML.
- Outpost placement: decide where LDAP outposts run relative to applications and the directory source, and confirm network paths and TLS settings for each.
- Staged cutover: move applications one at a time and keep the legacy directory reachable so each application can roll back.
The deployment environment changes the build sequence more than the identity mapping does, so confirm these points early.
- Air-gapped transfer: move container images, Helm charts or Compose files, and any upgrade packages through your approved media process before cutover, and confirm that PostgreSQL backups are available offline.
- Bundled database in Kubernetes: the authentik Helm chart bundles PostgreSQL for demonstration and test environments, so plan a separately managed PostgreSQL for production.
- Import in restricted networks: if source exports must be pulled from a connected staging network, confirm how they cross your controlled boundary and who approves the transfer.
- Ingress and outpost networking: check ingress, DNS and outpost connectivity from every application before importing users, since these paths are harder to change once cutover starts.
- Rollback paths: keep the legacy identity source running during each staged cutover, and verify that rollback works within your network controls.
What the client needs to provide
Before scope is fixed in writing, the client provides the access, inventory, owners and decisions that a migration depends on. DeployOpen confirms each item against your environment during scoping, so gaps show up before any cutover date is set. The list below covers what we expect to need from you.
Source and target access. For the source platform (Keycloak, Okta, Auth0 or a legacy LDAP directory), you need an administrator account with export rights for users, groups, roles, client applications and credentials where the platform allows them. On the target side, provide hosting in your cloud account, data center or air-gapped network, a PostgreSQL decision (a managed service or a self-run cluster you operate), DNS records and TLS certificates for each authentik hostname, and read access to LDAP or the source database where a legacy directory feeds user data.
Application inventory and owners. Provide a list of every application that signs users in through the source platform, with its protocol (OAuth2/OIDC, SAML or LDAP), redirect URIs, signing certificates, a named technical owner and a business owner. Also list a test tenant or sandbox for each application so cutover can be rehearsed. Confirm which applications rely on custom claims or group-based access, since those mappings need explicit design.
Decisions and approvals. Name the business owners who approve each cutover window and can accept user impact. Decide the password approach: whether password hashes can be migrated, whether users reset passwords at first sign-in, or whether a staged bridge is used. Decide how MFA enrollment will be handled and who can approve exceptions. Name a rollback owner with authority to stop a cutover and direct the reversal, and confirm that person is available during each window.
Frequently asked questions about authentik migration
Can users keep their passwords when moving to authentik?
It depends on what the source platform will export. Passwords move without a reset only when the source provides password hashes in a format authentik can verify, and when its license and terms allow that export. Export options differ between Keycloak, Okta, Auth0 and legacy LDAP setups, and some managed services do not expose hashes at all. Confirm the export path for your exact source and version before the plan is written. If hashes cannot move, the scope should name the fallback, such as a staged reset or a login-time migration.
How is the cost and duration of an authentik migration set?
The written scope sets both. Cost follows the number of applications, their protocols (OIDC, SAML, LDAP or proxy), the number of users and groups, the custom flows and property mappings needed, the password handling approach, and how many cutover waves are planned. Hosting and PostgreSQL are separate costs that you carry. DeployOpen does not publish a price list, so ask for a fixed-scope quote. The quote should separate one-time migration work from any recurring support, and it should state any authentik subscription you buy separately.
Can our own team migrate to authentik without a partner?
Yes, for a simple estate. A small number of applications using standard OIDC or SAML, with clean user data and few custom flows, is within reach of an experienced internal team. Planning and testing support is often advisable once you have many applications, mixed protocols, legacy LDAP binds or tight cutover windows, because failure modes multiply and are easy to miss. Build a full inventory of integrations first. That inventory shows which group your estate falls into.
What does a migration need from our team?
Mainly access, named owners and cutover windows. You need administrator access to the source platform and the target hosts, plus exports, client configurations and lists of redirect URIs for each application. Every application needs a named business owner who signs off testing and cutover. Your change process must reserve cutover windows, and a staging environment is needed for rehearsals. Agree in advance who can approve a rollback during each window. Missing owners often stall cutovers more than technical issues do.
Do we need an authentik Enterprise license for our connectors?
Only if a connector or feature you need is listed as enterprise-only. Compare your application inventory with the enterprise-only feature list on the authentik pricing page. That list includes Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history, enhanced audit logging and ticket-based support for larger subscriptions. Confirm each provider you rely on against the current pricing page and the license in the enterprise directory, because editions and their contents can change.
How does rollback work if an application cutover fails?
Rollback is planned for each application before cutover starts. Keep the source platform running and its configuration unchanged until the application has been verified on authentik. To roll back, point the application to its original client settings and redirect URIs, and record the exact steps and timing in a runbook. Users who signed in to authentik during the window need a defined path, such as forced re-login. Decide in advance who can trigger a rollback and how long you can wait before doing so, and rehearse the rollback in staging.
How DeployOpen runs authentik migrations
DeployOpen plans and runs authentik migrations from Keycloak, Okta, Auth0 or a legacy LDAP setup as fixed-scope work inside infrastructure you control, with user data, password handling, protocol mappings and application cutover agreed in writing before the build starts. Each application moves in a staged, reversible sequence so your teams can keep signing in while the rest of the estate is migrated.
How we scope
- We inventory source users, groups, applications, protocols and custom login logic in Keycloak, Okta, Auth0 or LDAP.
- We agree in writing how password hashes, password resets and MFA enrollment will be handled during the move.
- We map each application to an authentik provider type, such as OAuth2/OIDC, SAML or LDAP, and record the agreed cutover order.
How we build
- We stand up authentik in your environment, with PostgreSQL as the only data store and the hosting model agreed in the scope.
- We build user and group import jobs, property mappings and application providers, then test them in a non-production environment.
- We run each application cutover in stages with a documented rollback path, checking sign-in, token claims and group-based access.
How we hand over
- We deliver configuration as code or exported blueprints so the environments stay reproducible and reviewable by your team.
- We provide runbooks covering cutover steps, rollback steps, outpost setup, backup and restore and day-to-day administration.
- We document open items, such as users who could not be migrated and applications that still depend on the source platform.
How we support
- Engagements are fixed-scope, and the written scope sets the deliverables, the acceptance checks and the timeline.
- Ongoing support, upgrades to supported authentik release lines and post-cutover fixes are available as a retainer.
- Confirm with DeployOpen which authentik edition, and which enterprise features, your scope requires before the quote is finalized.
