How to export your data from JumpCloud

How to export data from JumpCloud without losing access

The Admin Portal exports directory records as files, but credentials, MFA enrollments and device-bound secrets generally do not leave with them, so the rebuild needs its own plan before the contract ends. Treat the export as the inventory of users, groups and attributes, not as a migration. Nothing in the supplied research confirms which export formats, filters or fields JumpCloud offers today, so confirm the exact options against JumpCloud's current documentation and test them in your own tenant. Ask the vendor in writing which objects are included, which are excluded, and whether group memberships, device associations and application bindings appear in the output.

Start by listing what the export will not carry. Passwords are the first gap, so plan for users to set new credentials in the new platform or to authenticate through a process you control. MFA enrollments are the second gap, since authenticator seeds and registered devices usually have to be re-enrolled at the destination. Device-bound secrets, such as certificates or keys tied to managed laptops and Linux hosts, need a separate inventory. Compare the export against each LDAP bind account, RADIUS shared secret, SSO application and managed device, because any of these can stop working on the day JumpCloud is switched off. Record the owner and the cutover step for each one.

Plan the rebuild before you request the final export, because a directory that is still live is easier to reconcile than a snapshot taken during shutdown. Export a test set first, load it into a staging instance of the target platform, and check that attribute names, user identifiers and group structures map correctly. Keep dated copies of every export under your own retention rules, and confirm with the vendor how long the tenant and its data remain accessible after cancellation. Pair this plan with the sequencing steps in the sibling migration pages so that re-enrollment and cutover happen in a controlled order rather than under contract deadline pressure.

What JumpCloud's Admin Portal exports, by data type

This table lists the five data types you are most likely to move when leaving JumpCloud, with the export method, file format and documented limits for each. Cells marked unverified could not be confirmed in vendor documentation or a test export, so check them in your own tenant before you set a contract end date. The main takeaway is that user records are usually the simplest to move, while applications, devices and logs need a separate check.

Data type	Export method	File format	Limits and status
Users and user attributes	Selected users, a view or all users (unverified)	CSV or JSON (unverified)	Passwords and MFA enrollments are not expected; confirm in a test export
User groups and memberships	Selected groups or all groups (unverified)	CSV or JSON (unverified)	Confirm whether memberships export with each group or as separate records
Systems and devices	Unverified; check whether the Admin Portal offers a systems export	Unverified	Device enrollment state and agent keys are likely excluded; confirm in a test export
Applications and SSO connections	Unverified; check each application's export options	Unverified	SAML signing certificates and client secrets are likely excluded; confirm per application
Admin and audit logs	Unverified; may be available through the event log or API	Unverified	Retention window and export limits are not confirmed; ask JumpCloud before the contract ends

What does not leave JumpCloud and how to replace it

A directory export gives you identity records, not the secrets and enrollments that make logins work. Each item below needs its own replacement plan, and the export file alone will not restore any of them.

Password hashes and passwords

Standard user exports carry profile attributes and group memberships, but not the credentials users type at sign-in. Plan a staged onboarding or a forced password reset in the new platform, and confirm with JumpCloud whether password hashes are available on your plan and whether they can be exported in a form your new directory can import. If hashes are obtainable, check the hashing algorithm and whether the target accepts it before you rely on that path. Users who sign in through SSO may need no action, while LDAP-only users usually do.

MFA enrollments and seeds

TOTP seeds and registered hardware keys are bound to the source system. Treat every enrolled factor as lost after cutover and schedule re-enrollment for each user before the old tenant is switched off. Confirm with JumpCloud whether TOTP seeds can be exported at all, since most vendors keep them out of reach. Build the re-enrollment flow with identity verification by your help desk, so an attacker who learns a username cannot register their own factor.

Device certificates and private keys

Certificates issued through JumpCloud's device management, along with their private keys, are generally not part of a directory export. Wi-Fi, VPN and managed laptop access may fail once the device trusts a different issuer. Inventory which certificates your endpoints and services depend on, then decide whether to reissue them from a new internal certificate authority or keep the old chain running during a transition. Confirm with JumpCloud what it exports for device certificates on your plan.

SSO signing keys and client secrets

Each SAML or OIDC application connected to JumpCloud holds signing keys and client secrets that the export does not carry. Every relying party must trust the new identity provider's metadata, and every OIDC client needs a new secret that you rotate and store in a secrets manager. Map each application's redirect URIs and certificate expiry dates before cutover. Confirm with JumpCloud which application configuration it can export, because SAML metadata and client secrets are often handled differently.

LDAP bind credentials

Applications, NAS devices and Linux hosts that bind to JumpCloud's LDAP service use bind accounts and passwords stored in their own configuration. Those passwords do not move with the user list, and the bind accounts themselves must be recreated in the new directory with the same search base and group filters. Inventory every LDAP client, record its bind DN and search scope, and plan a window where clients are repointed one at a time. Confirm with JumpCloud how it exposes bind account details for export.

RADIUS shared secrets

The shared secret between each access point, VPN concentrator or firewall and the RADIUS service is set on both sides and is never included in a user export. Once the endpoint points at a new RADIUS server, the secret must match on both ends or authentication fails with no clear error message. Generate new secrets, record which device uses which one, and change them during a maintenance window. Confirm with JumpCloud whether any RADIUS configuration is exportable before you rebuild it.

Why the export is only half of the exit

A file of users and groups does not move how JumpCloud authenticates your estate. The export from the Admin Portal gives you identity records, but the things that depend on those records, such as LDAP bind accounts, RADIUS shared secrets, SSO application trusts and enrolled MFA factors, are configuration and device state that a user file does not carry. Before the contract ends, inventory each place a directory binding lives: Linux hosts and SSH access, NAS devices, Wi-Fi and VPN concentrators, and every SSO application with its client registration. Each of these needs a deliberate rebuild on the destination, and the export only supplies the identity side of that work.

The destination documentation shows where the gaps sit. FreeIPA's migration how-to states that ipa migrate-ds excludes Kerberos attributes because FreeIPA regenerates them, and that sudo and HBAC rules need manual migration through LDIF. A user list therefore tells you nothing about who may run which command on which host. Keycloak's export and import guide warns that realm export has limitations as a backup and restore mechanism and that all nodes must be stopped while it runs, so it should not be treated as your rollback plan for the new directory. Confirm with each vendor which attributes, secrets and credentials their importer does not carry, and plan to re-enter or re-issue them.

Cutover is where a directory migration most often breaks authentication. Devices that bind to JumpCloud over LDAP or RADIUS will fail the moment their target changes, so run the old and new directories in parallel, repoint one client group at a time, and keep the JumpCloud tenant active until every group has authenticated successfully on the new side. Ask your vendor and integrator to define the parallel period, the rollback steps and the owner of each cutover window in writing. Do not schedule the final shutdown of JumpCloud until those checks pass.

Sequence to export data from JumpCloud and verify it

This sequence turns a JumpCloud export into a verified, dated and access-controlled record of users, groups and configuration. Each step ends with a check you can confirm before moving on, so the files can serve as the source for a directory rebuild before the contract ends.

Inventory the data types the business needs
The identity owner, with input from each application owner, lists every data type the business must keep: users, groups, group membership, user attributes, app assignments, LDAP and RADIUS settings, admin roles and MFA policies. For each item, note whether the Admin Portal export covers it or whether it must be recorded by hand, because passwords and MFA enrollments are not part of a standard export. This is done when every item has a named owner and a source, and the list is approved in writing.
Run a test export on a small set
Select a few users that cover different cases: an administrator, a user in several groups, a suspended user and a user with unusual characters in the name or attributes. Export them in each format the Admin Portal offers, CSV and JSON, and check headers, date formats, multi-value fields, character encoding and empty fields. Confirm with JumpCloud which fields and formats the current Admin Portal produces. This step is complete when the test files match the inventory columns and a sample record matches its Admin Portal screen field by field.
Run the full export and log each file
Run the full export for every data type in the inventory, one file per type where the portal allows it. Record the file name, format, export time, the administrator account used and any view or filter applied, so the export can be explained later. Keep the test files out of the final set. This step is complete when every inventory item maps to exactly one file in the log and no file is unaccounted for.
Compute checksums and record counts
Generate a SHA-256 checksum for each file with a standard tool such as sha256sum, and count the rows in each CSV file and the records in each JSON file. Write the file names, checksums and counts into a manifest that is stored separately from the files. A second person re-runs the checksums on a copy and must get identical values. This step is complete when the manifest is signed off and the independent recalculation matches it.
Reconcile counts against the Admin Portal
Compare the user totals, group member counts and app assignment counts in the manifest with the counts shown in the Admin Portal at the same point in time. Changes made during the export, such as new users or edited groups, can cause differences, so freeze directory changes during this window or repeat the export. Any remaining difference must be written down with its cause. This step is complete when every count matches or every difference has a documented explanation.
Store files encrypted with access logged
Move the exported files and manifest to encrypted storage that you control, and confirm that encryption at rest is enabled on that storage. Restrict access to a named group, turn on access logging, and delete working copies from laptops and shared drives. Confirm the retention period with your legal or compliance team before setting it. This step is complete when the access list has been reviewed, the access log shows only expected reads, and no unmanaged copies remain.
Keep a dated copy of configuration and memberships
Capture dated copies of the configuration screens that the export does not carry, such as application connections, LDAP and RADIUS settings, MFA policies, admin roles and group membership. Store them in the same encrypted location, add them to the manifest with checksums, and record who captured each one. This set is what your team will rely on during the directory rebuild, so it should be complete before the export is treated as final. This step is complete when the team can answer which application used which group on the export date using only these records.

Which exported fields feed FreeIPA, authentik or Keycloak

FreeIPA can take users and groups through its own migration tooling, but the access model needs hand work. Use ipa migrate-ds to pull users and groups from an LDAP source, and expect Kerberos attributes to be left out because FreeIPA regenerates them. Sudo rules and host-based access control (HBAC) rules do not come across this way and must be written as LDIF.

Identity fields: map exported username, email, first name, last name and group membership to the attributes FreeIPA expects, and check login names against the naming rules in your environment.
Group structure: create the groups in IPA before loading users so that membership maps cleanly.
Sudo rules: translate each JumpCloud sudo policy into a sudo rule in LDIF and load it manually.
HBAC rules: rewrite SSH and login permissions as HBAC rules scoped to host groups you create in FreeIPA.
Credentials: the export does not carry passwords or MFA enrollments, so users must set passwords and re-enroll OTP tokens after the cutover.

Confirm the exact column names in your export file and test the mapping on a non-production IdM server first. The FreeIPA migration how-to lists the attributes that are excluded during migration.

Keycloak works with users in two ways: as local accounts in a realm, or as accounts that stay in an external LDAP or Active Directory server through user federation. The choice determines which exported fields matter. Realm export and import use the kc.sh export and kc.sh import commands, which write and read realm JSON files. The Keycloak documentation warns that this is limited as a backup and restore method and that all nodes must be stopped while it runs.

Realm export and import: plan a maintenance window, because every node must be stopped while the realm export or import runs.
User federation: if users remain in a directory, configure a user federation provider and map username and email attributes there instead of loading them as local accounts.
Local user import: map exported username, email, names and status to Keycloak user fields, and set required actions so users reset passwords and enroll OTP.
Clients and roles: recreate clients, redirect URIs and realm roles manually, since the user export does not contain them.
Group mapping: map JumpCloud groups to Keycloak groups and add the protocol mappers that place group or role claims into tokens.

Test the realm import on a copy of the realm and review the Keycloak import and export guide before you choose a backup approach for production.

Can we export data from JumpCloud ourselves?

Can our own team export all our JumpCloud data without a partner?

Usually yes for the export step, because the Admin Portal can produce user lists and related data without outside help. The export is a starting inventory, though, not a migration. It does not carry passwords or MFA enrollments, so users must re-enroll, and groups, application assignments and device bindings still have to be rebuilt in the target platform. Confirm the export formats, the fields included and any row or scope limits in JumpCloud's current documentation or with JumpCloud support, since those details are not covered here. Staff who have handled directory changes before can often manage the export alone. Work gets harder when many SSO apps, LDAP binds and RADIUS clients must cut over without outages.

How much effort does a JumpCloud directory rebuild take?

Effort depends mostly on counts you can pull from your own environment: user accounts, enrolled devices, groups and policies, SSO applications, and LDAP or RADIUS clients. User count matters less than the number of integrations. Each SSO app needs its redirect URIs, client secrets, attribute mappings and claims rebuilt in the new identity provider. Each LDAP client needs its bind account, base DN and group filter checked against the new directory. Each RADIUS device needs its shared secret and policy confirmed. Build this inventory before agreeing on scope, because a written scope that lists each application and client is the only reliable basis for a quote.

How long does a JumpCloud migration take from start to finish?

No duration applies to every environment, so treat any single number as unverified until it matches your inventory. The timeline is set by the number of applications and clients to cut over, the change windows application owners will accept, the number of MFA re-enrollment waves, and whether the old and new directories run in parallel during cutover. A common sequence is a test group first, then pilot applications, then production groups. Keep JumpCloud active until the last dependent system has authenticated against the new source. Confirm your change calendar and freeze periods with your change board before any date is set.

What does our team need to provide for a directory migration?

The work needs decisions and access from your side as much as technical skill. Plan for the following:

Administrator access to the JumpCloud Admin Portal for the export, inventory and later decommissioning
A named owner for each SSO application, LDAP client and RADIUS device who can test and approve the cutover
Agreed change windows and a freeze calendar for each system
A test group of users and devices that can validate sign-in before wider rollout

Confirm the owner list early. Most delays come from applications nobody can speak for, not from the export itself.

What does a fixed-scope migration engagement from DeployOpen cover?

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. A fixed-scope engagement agrees scope, deliverables and timelines in writing before work starts. For a directory move, that scope typically lists the inventory of users, groups, applications and clients, the target platform build, re-federation of the named applications, the cutover runbook and documentation. Ongoing support and upgrades are available as a retainer. DeployOpen does not publish a price list, and a quote follows from the written scope. DeployOpen prepares controls and evidence for compliance reviews but does not issue audit reports or certifications.

What does a JumpCloud export leave out that we must rebuild?

The export does not carry passwords or MFA enrollments, so those cannot be moved as a simple file copy. Users will need a secure way to set or reset credentials, and every user must re-enroll MFA factors on the new platform. Group memberships, policies, application assignments and device-linked settings also need explicit rebuilding and checking. Some access rules have no direct import path. For example, FreeIPA's migration guide notes that sudo and HBAC rules require manual migration through LDIF. Confirm the exact attributes in your export with JumpCloud and map each one to a target field before cutover.

Why should the cutover include a parallel run and a tested rollback?

A parallel run lets you prove the new directory authenticates each system before JumpCloud is switched off, and a rollback path limits the damage if something fails. Backup and restore practices in the target platforms matter here. Keycloak's documentation warns that its realm export and import is limited as a backup and restore mechanism, and that all nodes must be stopped while it runs. FreeIPA's documentation warns that restoring an outdated backup into an active replica topology can break replication. Test restores in a non-production environment and write the rollback steps for each application before the change window opens.

What to plan before the JumpCloud contract ends

The export is only one step in leaving JumpCloud. The six items below set the dates, the parallel running period, the handling of personal data and the way back if a cutover fails, and each one needs a named owner on your side before the export starts.

Read the contract exit terms

Before any export, read the agreement for the notice period, the termination date, the data return terms and any commitment about deleting your data afterward. Confirm in writing with JumpCloud which export formats and scopes your plan includes and whether an administrator can still sign in after the end date. Ask whether you can keep read-only access during the overlap. Owner: procurement or legal, with the IT lead confirming the operational dates.

Schedule a test and a full export

Run a small test export first, using a filtered set of users or groups, and check that the columns, counts and group memberships match what you see in the Admin Portal. Then schedule the full export with enough time to repeat it if a file is incomplete. Store each export with a date stamp so the team can compare runs. Owner: the directory administrator, who signs off each file before it is used for import.

Keep JumpCloud available in parallel

Keep the existing directory running while the new one is tested, so LDAP binds, RADIUS checks and SSO logins can fall back if something breaks. Confirm with JumpCloud that the contract allows this overlap and that changes made in the old system will not be pushed into the new one by accident. Plan which apps move first and which keep pointing at JumpCloud. Owner: the IT operations lead, with application owners approving each switch.

Re-enroll MFA and devices in waves

The export does not carry MFA enrollments, so every user will register a new factor. Group users into waves by department or device type, and give each wave a support window and a fallback channel for lockouts. Check which second factors your target supports. FreeIPA, for example, handles HOTP and TOTP tokens, including hardware keys. Owner: the service desk manager, with the endpoint team for device profiles.

Set retention and deletion rules

Exported files contain personal data and directory attributes, so decide where they are stored, who can open them and how long they are kept. Encrypt the files at rest, limit access to the migration team, and record the deletion date for each copy in your retention schedule. Once the cutover is accepted, remove working copies and keep only what your records policy requires. Owner: the data protection officer or privacy lead, with the IT lead carrying out deletion.

Define a rollback path

Decide in advance what triggers a return to JumpCloud, who makes that call and how long the team waits before it does so. Take a backup of the target directory before each cutover step. For FreeIPA, the backup guidance warns that restoring an outdated backup into an active replica topology can break replication, so restore only in a planned way. Document each step so the rollback can be run under pressure. Owner: the platform engineering lead, who approves the rollback.

How DeployOpen works on this

DeployOpen approaches a JumpCloud export as the first step of a directory exit, not as a file download. We start by inventorying what the Admin Portal can export, what it cannot, and which LDAP clients, RADIUS devices and SSO applications depend on the directory, so the target platform and the re-enrollment plan are set before any data moves.

How we scope

Inventory the user, group and device data you need, and confirm which export views you can reach in your Admin Portal role.
List the LDAP binds, RADIUS clients, SSO applications and MFA enrollments that must keep working through the cutover.
Agree the scope, deliverables and timelines in writing before work starts, since most engagements are fixed-scope.

How we build

Run the export, store the CSV or JSON files in your environment, and map each field to the target identity platform's schema.
Rebuild groups and attribute mappings in a test instance, then check that sample logins and group filters return the expected results.
Plan credential and MFA re-enrollment as a separate workstream, since exports do not carry passwords or enrolled factors.

How we hand over

Document the export procedure, field mappings, known gaps and the order in which applications and devices are repointed.
Provide a cutover runbook with rollback steps for each LDAP client, RADIUS device and SSO integration in scope.
Deliver a record of test results and the open items that your own administrators or auditors need to confirm.

How we support

Support is available as a retainer for upgrades, hardening, backups and documentation updates after the directory is retired.
Confirm with us which exported files and configuration backups must be kept, and for how long, under your retention policy.
Ask for a written quote based on your scope, since DeployOpen does not publish a price list and quotes follow from the agreed scope.