How to export your data from Okta

What you can export from Okta, and what you will rebuild

A renewal, a licensing change or a residency requirement is forcing the move, and the first deliverable is an inventory. The user list is the one export path Okta documents clearly: the Password Health report CSV in the Admin Console, the List Users API with a filter, or a community browser extension. Policies, app integrations and MFA settings are not exported as a portable set, so they must be recorded and recreated in the target. Confirm with Okta exactly which fields your tenant's export returns, because the Okta support article on exporting active users describes the export methods without guaranteeing a complete attribute set.

Before any import, the target needs its own design. In Keycloak that means deciding how realms are split, which user store holds identities (Keycloak's own store or LDAP and Active Directory federation), and how clients and client scopes are structured. In authentik it means choosing the instance layout and the flows and providers that replace Okta's policies. Import the users into that design, not into a copy of the Okta tenant. Keycloak's realm export and import is JSON-based and documented with limitations as a backup mechanism, so treat it as a migration aid, not a substitute for the inventory.

Build a written inventory with four columns: user attributes and group memberships exported from Okta, application assignments and their protocol (SAML, OIDC or proxy), authentication policies and sign-on rules, and MFA enrollments. Each row needs an owner and a rebuild decision. Ask your integrator to confirm which of these can be read through the Okta API for your license tier, because access to some configuration objects depends on the suite. Password hashes are generally not exportable from Okta, so plan for user re-enrollment of passwords and MFA factors as a separate workstream.

Which Okta data exports, by method, format and limit

This table compares the export methods Okta documents or community tools offer for user lists, app and group assignments, and policies or app integrations. Read each row for the method, output format and known limits, then confirm anything marked for verification in your own tenant before planning the migration.

Data type	Export method	Format	Limits and what to confirm
Active user list	Password Health report, downloaded from the Admin Console	CSV	Documented by Okta Support for listing active users. Confirm the columns it includes in your tenant, since you will need attributes beyond login and status.
Active user list	List Users API with a filter	JSON from the API	Suited to scripted, repeatable pulls. Check the current Okta API documentation for rate limits, paging behavior and the filter syntax before you write the script.
Active user list	Rockstar browser extension	Community-defined output	Community-maintained and not supported by Okta. Treat it as a convenience tool, validate its output against the API, and review its code and permissions before use.
App and group assignments	Admin Console reports or Okta API endpoints	Confirm with Okta	Confirm in the admin console or the API docs for your tenant which export path returns assignments per app and per group, and in what format.
Policies and app integrations	No documented bulk export supplied	Not confirmed	Plan to rebuild these by hand or from configuration you document yourself. Ask Okta whether any bulk export of policies or app integration settings is available for your tenant.
Credentials and password hashes	Not covered by the methods above	Not confirmed	Assume passwords cannot be carried over as-is. Plan password re-enrollment or a supported import path, and confirm the options with Okta.

What does not export cleanly, and the workaround for each

A user list is the easy part of leaving Okta. The items below depend on secrets, enrollments and configuration that a standard export does not carry across, so each one needs an owner and a rebuild step. Treat them as the core of the migration plan, not as afterthoughts.

Password hashes and credentials

The supplied documentation does not describe a way to export password hashes from Okta, so the reader should not assume one exists. Ask Okta in writing whether any credential material can leave the tenant, and in what format, before scoping the move. Unless Okta confirms a usable export, plan for users to set a new password in the target identity provider, and decide how that reset is communicated and verified.

MFA enrollments and authenticator secrets

Enrolled factors such as authenticator apps, security keys and phone numbers are bound to the tenant that issued them, and their secrets do not move with a user list. Each user will need to enroll again in the target, so the cutover plan should include a window, a self-service enrollment path and a help desk procedure for users who cannot complete it. Confirm which factor types the target supports before users lose access to the current ones.

Policies and sign-on rules

Global session policies, authentication policies and sign-on rules control who gets which factor, from where and for how long. None of them come out as a file you can import, so build an inventory from the Admin Console that records each rule, its conditions and its exceptions. Rebuild each one in the target as a flow or policy, then test it against the same user groups before cutover.

App integrations and client secrets

Each SAML or OIDC application in Okta holds its own signing certificate, redirect URIs, client ID and client secret. The target generates new values, so every application owner must update their side and test single sign-on in a staging environment. Keep a register of the applications, their owners and their protocol settings, because the owner list is often the hardest part of the migration to reconstruct.

Group rules and lifecycle workflows

Group rules that assign users automatically and lifecycle workflows for joiners, movers and leavers are logic, not data, so they do not carry over as records. Document each rule and workflow as a specification first, including its trigger, its conditions and the downstream actions it calls. Then recreate it in the target, for example through directory group membership or automation triggered by identity events, and verify the results against a sample of real accounts.

Custom attributes and profile mappings

Custom user attributes are defined in the Okta profile schema, and the mappings between Okta attributes and each app's expected claims live in separate configuration. Export the schema first so the attribute list, data types and required fields are known, then map each attribute to a claim or directory field in the target. Check that application claims match what each app reads, since a missing or renamed attribute often fails only after cutover.

Why a CSV is not a migration file

A user list export from Okta gives you identifiers and attributes such as login, email, first name, last name and status. That is enough to seed a directory, but it does not describe how those users relate to the rest of the tenant. The file says nothing about which groups each person belongs to, which applications they are assigned to, which sign-on policies apply to those applications, or which MFA enrollments they hold. Treat the CSV as one input to the inventory, not as the migration itself. The Okta Password Health report, the Rockstar extension and the List Users API with a filter all return user records, so whichever method you use, confirm with your Okta administrator that the output includes the attributes your target realm or directory needs, and that deactivated or staged users are handled deliberately.

Keycloak has its own export format, and it is easy to assume that a realm export could serve as a backup of Okta or as a starting point for the migration. It cannot. Keycloak exports and imports realms as JSON files with the kc.sh export and kc.sh import commands. That file describes Keycloak's own realm: its clients, roles, groups, authentication flows and identity providers. It does not contain Okta data, and it is not the source of truth for anything in Okta. The Keycloak server guide also warns that this process has limitations as a backup and restore mechanism, and that all nodes must be stopped while the export runs. If you plan to use it on your own Keycloak instance during the project, schedule that downtime and do not treat the file as a substitute for a proper database backup.

The practical consequence is that the Okta-side inventory is still required before any import starts. Record every application integration with its protocol, redirect URIs, attribute mappings and assigned groups, along with each group's membership rules, each sign-on policy and the MFA settings that apply to it. Confirm these details in the Okta Admin Console and through the Okta APIs, and write them down in a document the migration team owns. Those records become the checklist for rebuilding clients, flows and role mappings in Keycloak, and they show which items cannot be carried over automatically and need a decision from the business owner of each application.

The export sequence, with a check at each step

This sequence turns Okta's live state into a dated, owned inventory of users, assignments, policies and app integrations, so the migration starts from a verified record rather than memory. Each step closes with a check that you can repeat before any data is loaded into the target identity provider.

Freeze the scope and name app owners
Before exporting anything, list every application, group and policy in scope, and record which org unit, instance or tenant each one belongs to. Assign one named owner to each app who will answer questions about its users, roles and sign-on behavior during the migration. The step is complete when the scope list is saved in a shared location and every app has an owner who has confirmed the entry in writing. Agree with those owners that changes to Okta during the export window will be logged, so the inventory does not drift.
Export the active user list with a date stamp
Export the active user list using the Password Health report CSV in the Admin Console, or the List Users API with a filter, and save the file with the export date in its name. Okta's support guidance describes these as the documented routes for an active-user list, while community tools are not a substitute for a reviewed export. Confirm the row count against the API result for the same filter, and note any users in suspended, deprovisioned or staged states that you need to handle separately. The step is complete when both counts match or each difference is explained in the log.
Pull app and group assignments
For each application, export its user assignments and group memberships through the Admin Console or the Okta API, then record them in a spreadsheet or a version-controlled config repository. Keep one row per user, app and group so you can later see who has access to what in the target system. Check that the total assignments per app in your file match the count the console shows for that app. The step is complete when every in-scope app has an assignment file and each file has passed its count check.
Inventory policies, sign-on rules and MFA settings
Document authentication policies, global sign-on rules, password policies and MFA enrollment settings for each app and group. Use screenshots for settings that have no reliable export, and an export where the admin interface offers one. Mark which settings you expect to rebuild by hand in the target, since configuration is generally not portable as data. The step is complete when each policy has a record that states its scope, its conditions and the factors it requires, and an owner has reviewed the list.
Record each app integration's protocol and mappings
For every app integration, record the protocol (OIDC, SAML 2.0 or other), client identifiers, redirect URIs, logout URLs, signing certificates and attribute mappings. These values define how each application trusts the identity provider, so they need to be exact before you rebuild them in Keycloak or authentik. Ask each app owner to confirm the redirect URIs and any custom claims the application reads. The step is complete when each integration has a record that the app owner has reviewed, and no field is marked as unknown.
Confirm what the target can import
Before loading anything, confirm which data your chosen target accepts and in what format. Keycloak imports and exports realms as JSON through its server commands, but the documentation notes limitations for backup and restore and requires all nodes to be stopped during the operation, so plan around that rather than assuming a complete copy. Where users remain in an existing directory, LDAP or Active Directory federation may be the better path. Test the import on a non-production realm with a sample of records and compare results to the source. The step is complete when a test import has produced the expected user and role counts.
Spot-check and obtain sign-off on each mapping
Select ten users with varied roles and group memberships, and compare each one's assignments, attributes and app access in the export files against the Admin Console. Then ask each app owner to sign off on their mapping in writing, covering users, assignments, protocol settings and redirect URIs. Any mismatch goes back into the inventory and is re-checked before sign-off. The step is complete when all ten sample users match and every app owner has signed the record, which becomes the baseline for the cutover plan.

How the export maps to Keycloak, authentik or ZITADEL

Keycloak has the most direct path for the configuration side of an Okta move. A realm can be exported to JSON with the kc.sh export command and imported with kc.sh import, which is useful for copying realm structure between environments. The Keycloak documentation warns that this process has limitations as a backup and restore mechanism and that all nodes must be stopped while it runs, so plan a maintenance window for any export taken from a live cluster. Existing user stores are usually better handled through LDAP or Active Directory federation, which keeps identities in your directory rather than copying them into Keycloak.

Realm JSON export and import: Use it for realm settings and client definitions, then review each imported client against the Okta app list.
LDAP or Active Directory federation: Point Keycloak at the directory that already holds your identities, so passwords and group memberships stay where they are.
Operator resources on Kubernetes: With the Keycloak Operator, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient custom resources let you declare realms and clients as code.
Policies and MFA: Authentication flows and MFA enrollment do not map one to one from Okta policies and must be rebuilt and tested.

Before committing, confirm with the Keycloak project or your support provider which export format and import behavior apply to your release, and how your cluster will be stopped during export.

What to plan before the Okta renewal or termination date

Export is the easy part when the rest of the plan is weak. The cards below cover the contract, the sequence of access changes, the parallel run, and the data you create along the way, so the export feeds a cutover you have already rehearsed.

Confirm data return terms in writing

Read your own order form and master agreement before anything else. Check what Okta commits to return on termination, in what format, within what period, and when it deletes your tenant data afterward. Ask Okta to confirm these points in writing, including whether exports from the Admin Console or API are included or whether you must request a separate data extract. Do not rely on a verbal answer from your account team.

Schedule the export before access reduction

Plan the user, group and assignment exports while every admin and app still works. Reducing licenses, disabling apps or lowering seat counts can change what the List Users API returns and what reports show. Run a first export early, then a final export close to cutover so you can compare the two and catch changes made in the meantime.

Keep admin access and audit logs

Keep at least one named admin account and the system log accessible until the target identity provider has been verified and the decommissioning record is signed off. Export or archive the audit logs you need for your own retention obligations, because access to the Okta console may end at contract termination. Confirm with Okta how long system logs remain available in the tenant.

Run a parallel sign-in period

Let Okta and the target provider both authenticate users for a defined period. Where an app supports two identity providers, route a pilot group to the new provider first and watch sign-in failures, claim mismatches and MFA enrollment problems. The parallel period is also the window in which you find apps that were missing from the export or were configured with settings no export captured.

Set a cutover window for each app

Move applications one at a time rather than switching the whole tenant at once. For each app, record the owner, the protocol (SAML or OIDC), the redirect URIs, the signing certificates, the attribute mappings and the rollback step. Agree the window with the app owner, because some applications cache signing keys or session tokens and need a restart or a user re-login after the change.

Set retention for exported data

Treat every CSV and JSON export as personal data. The user lists carry names, email addresses, departments and manager fields, and the group and assignment files show who can reach which systems. Decide who may access these files, where they are stored, how long they are kept and how they are deleted after migration. Record that decision in your data inventory before the first export runs.

Questions buyers ask before exporting from Okta

How much effort does an Okta export take?

The effort depends on the size and shape of your Okta tenant, not on the export tool. A CSV of active users is a short task for an admin. The larger work is inventorying applications, group assignments, sign-on policies, MFA enrollments and custom authorization settings, then recreating them in the target identity provider. The main drivers are the number of applications and how many use custom SAML or OIDC settings, the number of policies and rules, the number of groups that feed app assignments, how many users have enrolled MFA factors, and how many users sit in directories or agents that feed Okta. Ask for a written inventory of each of these before estimating the work.

Can our team export everything from Okta on its own?

Your team can export the user list on its own. Okta documents three routes for active users: the Password Health report CSV in the Admin Console, the community Rockstar browser extension, or the List Users API with a filter. The user list alone rarely covers a migration, though. App and group assignments, policies, app integration settings and MFA configuration must be read from the Admin Console or the Management API and written down, and some of that work is manual. Teams without someone who has administered Okta's app integrations and policies often find that the inventory takes longer than the export itself. A fixed-scope review can cover the inventory if your team lacks the time or the context.

What do we need from our team before the export starts?

Three things make the export go smoothly. First, an Okta super administrator or a role with read access to users, groups, applications and policies, so the reports and API calls succeed. Second, named app owners for every SAML and OIDC application, because only they can confirm redirect URIs, attribute mappings, signing certificates and which users truly need access. Third, a test environment, such as a non-production realm or a staging instance of the target identity provider, where you can rebuild a few applications and test sign-in before any production cutover. Also plan for a change window and a rollback path that keeps Okta running until the applications are proven.

Can Okta export our users' password hashes?

No documented path for exporting password hashes from Okta was available for this page, so do not plan a migration on the assumption that hashes will move. Confirm the position with Okta in writing before scoping the work. If hashes cannot be exported, the usual approach is to plan credential re-enrollment, where users set new passwords at first sign-in in the new system, and to decide how existing MFA factors will be re-registered. Ask Okta specifically about user credentials, MFA factor secrets and any support-led export process, and record the answer in the migration plan.

How long does an Okta export and rebuild take?

The duration cannot be given responsibly without an inventory. It depends on how many applications and policies you have, how many of them require custom configuration, how many owners must sign off, how many users need to re-enroll MFA, and whether a test environment is ready. Pulling the user CSV can be done in a single session. Rebuilding and testing each application, then coordinating the cutover, is where the time goes. Ask for a written scope that lists applications, policies, directories and owners, and build the timeline from that list rather than from a general figure.

Does DeployOpen handle the Okta export for us?

DeployOpen plans, implements, integrates and documents self-hosted open-source identity platforms inside your own infrastructure, and most engagements are fixed-scope. The work can include the inventory of applications, groups, policies and integrations, the rebuild in Keycloak or authentik, and the test and cutover plan. DeployOpen does not publish a price list. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. Ask for the inventory deliverable first, since it determines the rest of the quote.

What does a complete Okta export miss?

Exports typically miss configuration that lives in the admin console rather than in user records. Expect gaps in several areas:

Sign-on and password policies, network zones and MFA enrollment rules, which must be read and rewritten in the target platform.
Application-specific settings such as signing certificates, attribute statements, group claims, and the redirect URIs your applications rely on.
Lifecycle automations, provisioning rules and directory agent configuration, which need their own mapping.
Audit history and logs, which you should retain under your records policy rather than assume will move.

Write each gap into the inventory with an owner and a decision, so nothing is left for cutover day.

How DeployOpen scopes and delivers an Okta exit

DeployOpen plans and implements the move off Okta inside your own infrastructure, starting with a written scope that defines which user data, app assignments and policies leave Okta and where they land. We then build, test, document and hand over the target identity platform, with exports verified against your own environment before any cutover.

How we scope

Inventory which Okta exports you can take: user reports, List Users API results, app and group assignments.
Map each Okta policy, app integration and sign-on rule to the target platform, and flag what must be rebuilt by hand.
Agree the scope, deliverables and timelines in writing before work starts, since engagements are fixed-scope.

How we build

Script repeatable exports from the Okta API and validate record counts against the Admin Console before each run.
Rebuild clients, groups and authentication flows on the self-hosted identity provider, with test users for each application.
Test every exported dataset and rebuilt integration in a staging environment before any production change.

How we hand over

Document the export procedure, field mappings, known gaps and the reasons each item was rebuilt rather than exported.
Provide a checklist of what users must re-enroll, including MFA factors and password resets that exports cannot carry.
Deliver the runbooks, configuration records and evidence your internal team or external auditors will ask to see.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the handover.
Agree in the quote who holds administrator access, backup responsibility and patching for the new platform.
Ask your DeployOpen contact to confirm how exports will be repeated if a cutover is delayed or partially rolled back.