Migrate from Okta to authentik

Migrate from Okta to authentik: what the move involves

The migration is a planned rebuild of applications, policies and directory links, not a copy of Okta's data. Okta does not hand over its configuration in a form authentik can import, so each sign-on integration, group rule, authentication policy and MFA setting has to be recreated as an authentik provider, application, flow or policy binding. Users are the easier part. A user list can be pulled from Okta's reports or the List Users API, but passwords and enrolled MFA factors do not move, so plan for password resets or re-enrollment for each user population. Most smaller teams run this with an internal platform or identity group, often with an implementation partner for the design and the cutover. The effort is driven by the number of applications, the mix of SAML, OIDC and legacy apps, and how many Okta policies are actually in use. Risk is moderate and concentrated in the cutover window, where a missed redirect URI or claim mapping can lock users out of a business application.

The free edition is MIT licensed outside its enterprise directory, so the core server, providers and proxy authentication can be run without a license fee. The authentik EE License applies only to code in the enterprise directory, and features there, such as the Google Workspace and Microsoft Entra ID integrations, are sold on a per-user subscription. Confirm which of your current Okta integrations fall into that Enterprise set before you commit to the open-source edition, because those integrations are the ones with no free replacement. Support on the free edition is community only, so decide who will own patching, backups and upgrades, and check the supported version list in the authentik security policy before you pick a release to deploy.

Which Okta capabilities map to authentik, and which need rework

This table maps each Okta capability in your tenant to its authentik provider or flow and marks it as clean, needs rework or gap. Use it as a checklist, then confirm every row against your own Okta configuration, because authentik's feature set and edition terms change between releases. The main takeaway is that SSO, LDAP and RADIUS map well, while Access Gateway replacement, lifecycle automation and several integrations need design work or the Enterprise edition.

Okta capability	authentik equivalent	Status	Notes for your migration
OIDC and OAuth 2.0 apps	OAuth2/OIDC provider with an application entry	clean	Re-register redirect URIs and client secrets, then confirm claims and scopes against each app's expectations.
SAML 2.0 apps	SAML provider with an application entry	needs rework	Rebuild signing certificates, entity IDs and attribute mappings, and confirm each service provider accepts the new metadata.
Groups and app assignments	Groups, bindings and policies on each application	needs rework	Okta assignments do not transfer automatically. Recreate group membership and bindings per application and test with a pilot user.
Sign-on and MFA policies	Authentication and authorization flows with policy bindings	needs rework	Okta policy rules must be translated into authentik stages and policies. Confirm conditions such as network zones and device checks against your own tenant.
LDAP interface	LDAP provider and outpost	clean	Suits applications that bind to a directory. Confirm bind accounts, base DNs and group attribute mapping before cutover.
RADIUS for VPN and network devices	RADIUS provider and outpost	clean	Covered by the free edition. Confirm shared secrets, supported MFA prompts and client device compatibility.
Access Gateway for header or legacy apps	Proxy provider with an outpost in front of the application	gap	Not a one-to-one replacement. Each legacy app needs a proxy configuration, and Kerberos or unusual header scenarios need separate testing.
SCIM provisioning to downstream apps	SCIM provider	needs rework	Confirm each target app's SCIM schema and attribute handling. Lifecycle triggers that Okta Workflows covers need separate automation.
Google Workspace and Entra ID integrations	Enterprise provider types	gap	These require the Enterprise edition under the authentik EE License. Confirm licensing with authentik before planning them.
mTLS client certificate authentication and privileged access management	Enterprise features	gap	Listed as Enterprise-only on the authentik pricing page. Confirm whether your current Okta suite uses these before excluding them from scope.

What exports from Okta and what must be rebuilt

Okta gives you a user list through a few documented paths, but the configuration that makes the tenant work does not come with it. The cards below separate what you can pull out of Okta from what you must recreate in authentik and what users must do again after cutover.

Password Health report CSV

The Admin Console can produce a CSV of active users from the Password Health report. It is the simplest export for a one-time user list, and it is available without API scripting. Check that the columns you need, such as login, email, names and department, are present, because the file contains only what the report includes. Use it as a starting point for the authentik user import and reconcile the row count against the active user count in the Admin Console before you rely on it.

List Users API with a filter

Okta's List Users API can return users that match a filter, for example only users in an active status. Scripted pulls give you repeatable output and let you record the query and timestamp for the migration file. Confirm which profile attributes and custom attributes your tenant returns, and plan separate calls for anything the default response leaves out. Store the output in a restricted location, because it holds personal data and must not sit in a shared folder.

Rockstar extension as a third option

Rockstar is a community browser extension that Okta documents as a third way to export active users. It is not an Okta product, so its code, permissions and update history are your responsibility to review. Run it under a named administrator account with the narrowest role that works, and compare its output with the Password Health report before you use it for an import. Record which version you used so the migration evidence is traceable.

Policies and sign-on rules

Authentication policies, sign-on rules, network zones and MFA requirements are configuration, and they are rebuilt in authentik as flows, stages, policies and bindings. Write down every rule that decides who can sign in, from where and with which factor, and map each one to an authentik flow before cutover. Test the sequence with a pilot group, because a rule that looks equivalent can change the order of prompts users see.

App integrations and group logic

Okta app integrations, their SAML and OpenID Connect settings, assignments and group-based rules do not export as a package. Recreate each one as an authentik provider and application, then bind it to the groups that should reach it. Inventory every app with its redirect URIs, signing certificates, attribute mappings and owner. Group membership in authentik must be driven by the source you choose, so confirm which group data comes from your directory and which you maintain in authentik itself.

Password hashes and MFA enrollments

Password hashes and MFA enrollments generally do not move from Okta, so plan for users to set a new password where needed and enroll their factors again in authentik. Ask Okta in writing what, if anything, your contract and tenant allow you to extract. Schedule re-enrollment in waves, provide a support path for users who lose their device, and confirm which factor types authentik supports for each group before you retire the Okta factors.

The migration sequence from inventory to decommission

This sequence moves Okta-protected applications to authentik one group at a time, with a pilot, a parallel run and a rollback path at each stage, so that Okta is retired only after every application has been verified on authentik. Each step produces a written artifact that a named owner signs off before the next step starts.

Inventory applications, policies and identities
Start by listing every Okta app integration, its protocol (OIDC, SAML, SWA, or header-based access through Access Gateway), its owner, its user groups and the sign-on and MFA policies that apply to it. Pull the user list from the Admin Console or the List Users API, and record which attributes each downstream app actually reads. The output is an app register with one row per application, its owner, its risk rating and its dependencies. The step is done when the application owners have confirmed the register in writing.
Build the mapping sheet for flows and policies
Translate each Okta policy into an authentik equivalent before any configuration starts. For every application, record the provider type (OAuth2/OIDC, SAML, LDAP, RADIUS or proxy), the authentication flow, the authorization and MFA stages, the attribute mappings and the group bindings. Mark each row as a direct match, a partial match or a gap, and note where the Enterprise edition would be needed for a feature you rely on. The output is a mapping sheet that reviewers can check line by line. Confirm current feature availability with authentik before you commit to a design.
Stand up a non-production authentik instance
Deploy authentik in a test environment that matches your target production topology, using the server and worker containers and PostgreSQL that the architecture documentation describes. Confirm that the host meets the sizing in the Docker Compose guide for test use, and plan production sizing separately, since the Compose guide positions that setup for test and small-scale production. Configure a backup and restore test for the database before any real user touches the system. The output is a tested instance with a documented backup and restore run and a list of the versions you chose, checked against the security policy's supported releases.
Run a pilot with a few low-risk applications
Choose three to five low-risk applications with a small, willing user group, and configure them in authentik following the mapping sheet. Test sign-in, MFA enrollment, group-based access, logout, token lifetimes and the attributes each app receives. Have application owners run scripted test cases and record results. The pilot is complete when every test case passes and the owners sign off, and the rollback plan for each pilot app is written down: which Okta app stays live, how users switch back, and who makes the call.
Operate a parallel run with both providers
Keep Okta and authentik serving logins at the same time, with each application assigned to one provider at a time so that no user is ambiguous about where to sign in. Track sign-in success rates, MFA failures, helpdesk tickets and access-denied events for each application, and compare them with the Okta baseline. Decide in advance which thresholds trigger a rollback. The output is a parallel run log and a go or no-go decision for each remaining application group, approved by the identity owner and the application owner.
Cut over applications in groups
Move applications to authentik in waves, ordered by the risk rating in the app register, starting with those the pilot proved stable. For each wave, update the redirect URIs, client secrets or SAML metadata in the application, switch the relevant DNS or proxy routing for proxy-protected apps, and retain the Okta configuration in read-only state so that rollback is a configuration change, not a rebuild. Record the cutover date and the verification results in the register. A wave is closed when its owners sign off and the rollback window that you agreed in the plan has passed without a reversal.
Decommission Okta and archive the evidence
Once every application runs on authentik, export the final Okta configuration, policy definitions, logs and user lists for retention under your records policy, then revoke Okta API tokens and disable the Okta sign-in for each app. Remove any remaining Okta agents, SCIM connections and proxy components, and cancel the Okta subscription only after your contract terms and data retention requirements are met. The output is a decommission record listing every removed integration, the archive location and the sign-off from the identity owner. Ask your Okta account team to confirm the exact export options available under your contract.

How the authentik proxy outpost replaces Access Gateway

authentik's proxy provider replaces Access Gateway's job of putting legacy apps behind the identity provider, and the outpost is the component that does the work. A proxy provider sits in front of an application and enforces authentication through authentik, which suits apps that accept identity from a header or that have no SAML or OIDC support of their own. The free edition includes the proxy provider, and the embedded outpost runs inside the server container, so a small deployment needs no extra service to start. Separate outposts are a design choice for placing a gateway closer to the application, and that choice is worth making deliberately before go-live.

Before cutover, confirm what each legacy app actually needs. Header-based apps must accept the identity headers authentik sends, and the reader should test whether the app trusts those headers only from the proxy path. URL-based apps need the correct external hostname and path rules, and apps that set their own cookies or redirect to internal hostnames often need configuration changes. Kerberos-protected apps are a separate case: the proxy provider covers web access, but Kerberos delegation and keytab handling must be tested against the directory the app uses, and the reader should not assume it carries over from Access Gateway. Also map the network path from users to the outpost, including VPN, reverse proxy, TLS certificates and firewall rules, because a gateway that works on the internal network can fail for remote staff.

If Okta stays for other applications, replacing Access Gateway becomes a separate design decision rather than a side effect of the identity migration. Keeping Access Gateway in place means the legacy apps still depend on Okta, while moving them to authentik removes that dependency but adds a gateway you operate. Decide per application, record who owns each proxy configuration, and confirm with the vendor and your own tests how the outpost behaves under your load and failure scenarios. A short pilot with one header-based app and one Kerberos app usually shows which path your estate needs.

What drives cost and duration in this migration

This table lists the cost components of moving from Okta to authentik and the drivers that change effort in each. Read it as a checklist for scoping: the drivers in the first rows usually matter most, and the cost components show who is paid and whether each cost recurs. Use it to frame the questions you put to a quote.

Driver or component	Why it moves cost or effort	How to keep it down
Internal staff time for inventory and testing	Your team must confirm which Okta apps, groups and policies are still in use and test each one against authentik flows. This is largely one-time effort but it is usually the largest internal share.	Run an export of active users and app assignments early, retire unused apps before migration, and agree a test matrix per application.
Number of applications	Each OIDC, SAML, LDAP, RADIUS or proxy integration needs its own provider, application and test. Effort grows with the count of distinct protocols and redirect configurations, not only with the count of apps.	Group apps by protocol and by owner, and migrate low-risk apps first to build a repeatable pattern.
Custom sign-on policies and authentication flows	Okta policies map to authentik flows, stages and policies by hand. Complex conditions, device or network rules, and step-up logic take design and review time.	Document current Okta policies in plain language before mapping, and remove rules that no longer reflect how people sign in.
Legacy header, Kerberos or URL-based apps	These apps often need proxy outposts, hostname changes and session handling tests that Okta Access Gateway previously covered. Each one is a separate piece of work.	Confirm which legacy apps need the proxy provider, and ask whether a native OIDC or SAML option exists before building proxy rules.
Directory size and source of identities	The number of users and the presence of Active Directory or LDAP sources change the sync design, attribute mapping and cutover checks. Okta-only users with no directory source need a different plan.	Clean up attributes and duplicate accounts before import, and decide early which directory is the system of record.
MFA re-enrollment	Users may need to enroll new factors in authentik, and password or MFA secrets exported from Okta are generally not portable. Help desk load rises during the enrollment window.	Confirm with Okta and your own records what can move, schedule enrollment in waves, and prepare help desk scripts.
Compliance evidence	Access reviews, change records, logging and configuration evidence for auditors must be rebuilt for the new platform. Evidence gaps often appear late in a project.	Map existing Okta control evidence to the authentik equivalents and agree the evidence list with your auditor before cutover.
PostgreSQL and hosting	authentik stores all configuration and data in PostgreSQL, so database sizing, backups, high availability and the hosting platform are recurring costs you carry. The 2025.10 release notes also warn of roughly 50% more PostgreSQL connections after upgrading.	Size the database for your user count and connection pool, and ask for a quote that separates one-time setup from monthly infrastructure.
Enterprise subscription (if needed)	The free edition covers OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos and proxy providers with community support. Entra ID or Google Workspace integrations, privileged access and ticket support require Enterprise. Per-user list prices appear on the authentik pricing page, and any quote should be checked against that page.	Confirm whether you need Entra ID, Google Workspace or privileged access before choosing an edition, and request a written quote from the authentik pricing page.
Ongoing operations and patching	A self-hosted authentik instance needs upgrades, security patches on the supported release lines, monitoring and on-call coverage. This recurs for as long as you run the service.	Assign an owner for upgrades, subscribe to security notices, and ask whether a retainer covers patching and monitoring.

How the migration differs by team size and starting point

A small team with a few dozen modern OIDC or SAML applications and no header-based legacy apps usually has the simplest path. The main work is inventorying applications, recreating each as an authentik provider and application, and moving users and groups across. Because the free edition covers OIDC, SAML, LDAP, SCIM and MFA, most of this can run on the open-source core, with community support as the main channel.

Scope: Confirm every Okta app integration type, including SAML apps with custom attribute statements that must be copied into authentik property mappings.
Sequence: Pilot two or three low-risk apps first, then move the rest in batches by user group.
Users: Plan password and MFA re-enrollment, since password hashes are usually not available from Okta exports.
Hosting: A single Docker Compose host is documented for test and small-scale production, so confirm whether your availability target fits that model.
Confirm first: Export your Okta app list and group assignments, and check which apps need features your team has never configured in Okta.

Before cutover, test login, logout and a token or assertion check for each application against a staging authentik instance.

What usually goes wrong and how to prevent it

Most failed Okta to authentik migrations break on the same few points: data that does not move, policies that were never inventoried, cutovers with no way back, and platform versions that fall out of support. Each card below names one failure and the check that prevents it, so the team can plan the cutover around them.

Assuming credentials and factors export

Teams often expect password hashes and enrolled MFA factors to come across with the user list. Okta's user list exports cover profiles and status, not reliable credential material, so users may face a password reset and new MFA enrollment on day one. Ask Okta what your export contains, confirm whether authentik can import any credentials at all, and plan re-enrollment with help desk capacity before cutover.

Underestimating policy and flow rebuilds

Okta sign-on policies, network zones, group rules and app assignments do not become authentik flows automatically. Build an inventory of every Okta app, policy and group rule, then map each one to an authentik provider, application, policy binding or flow stage. Test each mapped app with a pilot group, because a missed MFA prompt or group condition can silently widen access.

Cutting over without a rollback path

A big-bang switch removes the old sign-on path before the new one is proven. Keep Okta active for each application until its authentik configuration passes login, logout, MFA and group checks. Record the DNS records, OIDC client settings and SAML metadata you changed, so each app can be pointed back to Okta quickly. Decide the rollback trigger in advance.

PostgreSQL connection growth after upgrades

Since release 2025.10, authentik runs on PostgreSQL alone, with no Redis for caching, tasks, sessions or WebSocket traffic. The release notes warn of roughly 50% more PostgreSQL connections after upgrading. Size connection limits and any pooler before go-live, and watch connection counts during the first days of production load.

Running unsupported authentik versions

authentik publishes a security policy listing which versions receive security fixes, and the project announces security releases at least 24 hours in advance. Teams that deploy once and stop tracking releases fall out of support without noticing. Assign an owner for upgrade windows, subscribe to the release feed, and schedule a test instance to take each security release before production.

Questions teams ask before moving from Okta to authentik

How much effort does a move from Okta to authentik take?

The effort depends on how many applications, policies and directory sources you have, not on a fixed duration. The main drivers are the number of SAML and OIDC apps that must be re-registered, how many Okta policies and group rules have to be rebuilt as authentik flows, stages and policies, whether LDAP or RADIUS clients point at the new server, and how many users must re-enroll MFA. Teams with a short app inventory and clean group structure usually have less to rebuild than teams with many custom policies. Ask any implementation partner for a written scope that lists each app and policy before agreeing a timeline.

Can our own team migrate from Okta to authentik without outside help?

A capable platform team can run a pilot alone, especially with a small application count and a test environment. authentik documents Docker Compose for test setups and small-scale production, with at least 2 CPU cores and 2 GB of RAM as the stated minimum for that guide. Production work usually adds PostgreSQL operations, high availability, backups, certificate handling, outpost placement for proxy apps and a cutover plan that touches every relying application. If the team has no one who has run an identity provider before, a fixed-scope engagement with DeployOpen can cover planning, implementation, hardening and documentation, with ongoing support available as a retainer.

What skills and staff time does an authentik migration need?

The work needs three kinds of people: someone who owns the identity platform, application owners who can change redirect URIs and claim mappings, and a security or compliance lead who signs off on policies and evidence. The platform owner needs working knowledge of OIDC, SAML, LDAP and container or Kubernetes operations. Application owners need to test sign-in, logout and group-based access for their own systems. Plan for the staff time of each group to be in the written scope, because application testing is often the largest share of effort and is easy to underestimate.

Do we need the paid authentik Enterprise edition to replace Okta?

Not for every case. The free edition supports OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos and proxy authentication, with community support only. Enterprise is needed if you depend on Google Workspace or Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history, enhanced audit logging or ticket-based support. The authentik pricing page lists Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, with Enterprise Plus starting at $20k annually for SLAs, multi-instance support and FIPS compliance. Map each Okta feature you use against that list before deciding, and confirm current pricing on the pricing page.

How are passwords and MFA handled when users move to authentik?

Okta does not hand over password hashes in a standard user list, so you should not expect existing passwords to carry over automatically. The usual approach is to create accounts in authentik from an exported user list, then have users set a new password on first sign-in or through a reset flow, and re-enroll MFA factors such as TOTP or WebAuthn. Confirm with Okta support whether any hash export is available for your tenant before planning around it. Schedule re-enrollment in waves, with a help desk script and a fallback path for users who lose a device.

Can we run Okta and authentik side by side during cutover?

Yes, a staged cutover is the safer pattern. Run authentik alongside Okta, move one low-risk application at a time, and keep the Okta app assignment in place until the new flow is proven. Users can be split by group so pilot users sign in through authentik while others stay on Okta. Keep the Okta tenant active until you have confirmed every application, logout path and account lifecycle step, and record which apps have moved in a tracking sheet that application owners sign off.

What should we check in authentik's support and release model before we commit?

Check the supported versions and the security release process before you set a patch cadence. The authentik security policy lists 2026.5.x and 2026.8.x as supported versions receiving security fixes, and the project announces security releases at least 24 hours in advance. Releases are named by year and month, and the latest release shown on GitHub at the time of the research was 2026.8.4, published October 14, 2026. Free edition support is community Discord only, so decide whether you need a paid support route, and confirm with authentik which versions will be current when your production go-live happens.

Which Okta features do not have a direct authentik equivalent?

Map each feature before you commit. authentik documents provider types for OAuth2/OIDC, SAML, LDAP, proxy, RADIUS, SCIM, remote access control, Google Workspace, Entra ID, Shared Signals Framework and WS-Federation. Okta features tied to its cloud directory, its adaptive risk signals, its workflow automation and its Access Gateway may need redesign rather than a one-to-one swap. Ask for a written gap list from any implementation partner, and confirm each capability in the current authentik documentation rather than assuming a match.

How DeployOpen scopes and runs an authentik migration

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted authentik inside your own cloud accounts, data center or isolated network. The work covers the authentik server and worker containers, the PostgreSQL database that holds all configuration and data, and the proxy outposts that take over from Okta Access Gateway. Engagements are typically fixed-scope: the written scope names which Okta applications, policies, LDAP or RADIUS clients and proxy-protected hosts are in, which are out, and what each deliverable looks like. A quote follows from that written scope, so the scope document is the first thing a CISO or platform lead should review and sign off.

A useful scope starts with an inventory that you and DeployOpen build together. For each Okta application, record the protocol (OIDC, SAML, or a header-based proxy app), the assignment groups, the MFA rule that applies, and who owns the relationship with the vendor. Decide which authentik Enterprise features, if any, you need before the build starts. Google Workspace and Microsoft Entra ID integrations, privileged access management and ticket-based support sit in the paid edition, so the scope should state whether they are required or deferred. Confirm current edition terms directly with authentik, because the authentik pricing page can change. Also confirm which authentik release line you will standardize on and how upgrades will be scheduled, since the project publishes security policy details you should review before committing.

Ongoing support is available as a retainer, separate from the fixed-scope build. A retainer can cover patching the authentik release line, reviewing security advisories, testing PostgreSQL and backup restores, and adjusting flows and policies as applications change. Ask any provider, including DeployOpen, to state in writing what the retainer includes, how incidents are escalated, who holds administrative credentials, and how changes are logged. DeployOpen prepares documentation and evidence for your internal reviews and compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments, so the scope should name the controls you need evidence for and who will collect that evidence.

Migrate from Okta to authentik