Migrate from JumpCloud to authentik: what the move involves
Most organizations leaving JumpCloud do so because of a renewal, a licensing or packaging change, a data residency requirement or a wish to reduce lock-in. Whatever the trigger, the migration is a rebuild of directory, client and federation configuration, not a file copy. JumpCloud's user records can be exported, but passwords, MFA enrollments, group bindings to devices and the settings each LDAP client, RADIUS device and SSO application holds must be recreated in authentik. Plan the work as a set of configuration projects with their own test and cutover steps.
In most cases an internal platform or IT team does the work, often with an implementation partner for the design, the LDAP and RADIUS outpost setup and the cutover rehearsal. Effort depends on how many SSO applications are federated, how many devices and services bind to LDAP or RADIUS, how many groups drive access, and whether users must re-enroll MFA. Ask any partner for a written scope that lists each application and client, who owns each one and what evidence confirms it works. Your own inventory of JumpCloud bindings is the first deliverable, because it sets the size of everything else.
The main risk is breaking device authentication during cutover. Wi-Fi, VPN, NAS and Linux logins often depend on a bind account, a shared secret or a group filter that stops working the moment its source changes, and users may not be able to recover without help desk involvement. Run authentik's LDAP and RADIUS outposts in parallel with JumpCloud where possible, repoint one client group at a time, and keep a rollback path for each. Confirm the outpost sizing and PostgreSQL requirements for your scale with the authentik documentation before you commit to a date.
Which JumpCloud capabilities map to authentik and which need rework
This table maps each JumpCloud identity capability to the authentik provider or outpost that covers it, marked as clean, needs rework or gap. Read the rows with your own app inventory open, because the rework column is where cutover schedules usually slip.
| Capability | authentik component | Status and what to confirm |
|---|---|---|
| SSO for OIDC and SAML apps | OAuth2/OIDC and SAML providers | Clean for most apps. Re-register each app with new client IDs, secrets and redirect URIs, and confirm SAML signing certificates and attribute mappings in each app. |
| LDAP binds for NAS, Linux and apps | LDAP provider with an LDAP outpost | Needs rework. Bind DNs, base DN, group filters and the search attributes that clients expect often differ from JumpCloud, so repoint and test each client individually. |
| RADIUS for Wi-Fi and VPN | RADIUS provider with a RADIUS outpost | Needs rework. Create new shared secrets, point each access point or VPN gateway at the outpost address, and confirm the authentication flow and MFA behavior on each device type. |
| MFA enrollment | authentik authenticators and stages | Gap in carry-over. Enrolled JumpCloud factors generally do not move, so plan re-enrollment and confirm with your own environment how each factor type will be handled before cutover. |
| Users and groups | authentik users and groups, imported by script or API | Needs rework. Export from the Admin Portal, then map group membership to authentik groups. Confirm how group filters on LDAP and RADIUS evaluate after import. |
| SCIM provisioning to SaaS apps | SCIM provider | Needs rework. Each SaaS app needs its own SCIM endpoint and token configured, and deprovisioning behavior must be tested against each application. |
| Google Workspace and Microsoft Entra ID integrations | Enterprise-only integrations | Enterprise-only. authentik's pricing page lists these as Enterprise features, so confirm the edition you need before you plan these connections. |
| Device management and Windows or macOS policy | Not replaced by authentik | Gap. authentik does not manage devices or apply Windows or macOS policy, so you need a separate endpoint management tool for these controls. |
What can be exported from JumpCloud and what must be re-created
The JumpCloud Admin Portal exports user and group records, but the credentials and enrollments that let people sign in do not move cleanly. Each item below is either carried over as data, rebuilt by hand in authentik, or re-enrolled by the user, and the cutover plan depends on knowing which is which. Confirm the current export formats and fields with JumpCloud before you set the schedule.
User records and attributes
Export the user list from the Admin Portal to capture usernames, email addresses, names, status and any custom attributes your apps read. Map these fields to authentik users and their attributes before import, and decide how suspended JumpCloud accounts are handled so they do not reappear as active users. Check whether every attribute you need appears in the export, because the file only carries what the portal shows. Use a test import into a staging authentik instance to confirm the mapping before you touch production.
Passwords and MFA enrollments
Plan on users re-enrolling their MFA devices and passwords in authentik, because password hashes and MFA enrollments are not reliably carried over from the Admin Portal export. Ask JumpCloud in writing whether any credential material can be exported for your tenant and under what conditions. Where it cannot, schedule enrollment windows, tell users which authenticator apps or hardware keys to prepare, and keep a help desk path for people who cannot complete enrollment on the cutover day.
Groups and group membership
Group names and memberships can be exported and then recreated as authentik groups, which drive application access and policy bindings. Rebuilding groups is a design task, not only a copy: membership that JumpCloud granted through device or application bindings may need to become explicit authentik group assignments or policies. List every group that controls access to a real application, then confirm which application each group feeds before cutover.
LDAP bind accounts and search base
Each application, NAS or Linux host that binds to JumpCloud Cloud LDAP uses a bind account and a search base that must be recreated in authentik's LDAP outpost. Create new bind accounts with read-only scope, record the base DN and group filters each client uses today, and update the client configuration to point at the outpost host. Expect to change these settings on every LDAP client, since no credential or filter moves automatically.
RADIUS shared secrets and device configuration
Wi-Fi controllers and VPN concentrators authenticate against JumpCloud Cloud RADIUS with shared secrets that are configured on each device. Treat these secrets as new values: generate them in authentik's RADIUS provider, install them on every access point, firewall and VPN gateway, and test each device against the outpost before retiring the JumpCloud entry. Record which devices have which secret so a rotation later does not break Wi-Fi for a site.
SSO app federation and SCIM connections
Each SAML or OIDC application trusts JumpCloud as its identity provider, so it needs a new provider in authentik with its own client IDs, certificates, redirect URIs and attribute mappings. SCIM provisioning links are also tied to JumpCloud and must be pointed at authentik with new tokens. Run each app in a test tenant first, and confirm that the attribute names and group claims the app expects match what authentik sends.
How to sequence the cutover so devices keep authenticating
This sequence moves JumpCloud-dependent logins to authentik in stages, so every LDAP client, RADIUS device and SSO app keeps authenticating until its replacement has been proven and its JumpCloud binding can be safely removed.
Build the dependency register
Before changing anything, list every user, group, LDAP client, RADIUS device, SSO application and device policy that depends on JumpCloud. For each item, record the owner, the protocol, the bind account or shared secret, the group or policy it relies on, and the network path it uses. Ask each application owner to confirm the register, since integrations often bind through accounts nobody remembers creating. The output is a signed-off register that becomes the cutover checklist and the source for every rollback decision.
Rebuild users and groups in a pilot tenant
Import the users exported from the JumpCloud Admin Portal into a separate authentik instance, then recreate the groups that drive application access and outpost filters. Passwords and MFA enrollments usually do not carry over in a plain export, so confirm with JumpCloud exactly what your export contains and plan how each user will set a new password and re-enroll MFA. The output is a test realm where group membership matches the register and a short list of users who can sign in.
Pilot with a small group of non-critical clients
Choose one low-risk LDAP client, one SSO application and one RADIUS device, such as a test Wi-Fi SSID or a lab VPN profile, and repoint them to authentik. Run them with a pilot group of administrators who know how to report problems. Watch authentication logs on both sides during normal working hours. The output is a documented pilot result for each client type, including the exact settings that worked, such as bind DN format, base DN, group filters and RADIUS shared secret handling.
Run both directories in parallel in batches
Repoint clients in batches grouped by dependency, starting with those that have the simplest fallback. Keep JumpCloud active during this stage so a client can be switched back by changing its server or bind settings. Record, for each batch, the time of the change, the users affected and the result. Do not move a batch until the previous one has authenticated successfully for a full working cycle. The output is a batch log showing which clients now authenticate against authentik and which still use JumpCloud.
Write a rollback procedure for each client
For every client type, write the exact steps to restore its JumpCloud binding: the configuration file or device profile to revert, the credential to restore, and who approves the change. Test the rollback on the pilot client before it is needed. For Linux hosts using SSSD, Wi-Fi profiles on managed endpoints and RADIUS devices, the steps differ, so keep one procedure per type. The output is a rollback runbook that the operations team can follow without the original project staff.
Cut over each client type in a planned window
Move the remaining clients of each type during a change window agreed with the owners in the dependency register. Start with the type that has the fewest dependencies, such as SSO applications that use OIDC, and finish with the clients that are hardest to change, such as embedded devices and firmware-bound RADIUS. Ask the owners to test sign-in on their own applications immediately after each change. The output is a signed confirmation from each owner that their client authenticates through authentik.
Confirm no traffic before decommissioning JumpCloud bindings
Keep JumpCloud bindings in place until authentik logs and the network records show no remaining authentication requests from the old LDAP, RADIUS and SSO endpoints for the period you have agreed in advance. Confirm this against the dependency register, not only the logs, because a quiet scheduled job can still rely on an old binding. Only then remove the bindings, revoke the bind accounts and retire the device policies. The output is a decommission record that shows the evidence used to close each binding.
What drives the cost and duration of the migration
This table lists the components that move the cost and timeline of a JumpCloud to authentik migration, who is paid for each, and whether the cost is one-time or recurring. Use it to decide what your written scope and quote must spell out before work starts.
| Driver or cost component | Why it changes cost or effort | One-time or recurring, and what to ask for |
|---|---|---|
| Number of LDAP bind clients | Each NAS, app or Linux host that binds to LDAP needs its bind account, base DN and group filter retested, so every extra client adds test and cutover work. | One-time. Ask the quote to list each client by name and state who tests it. |
| Number of RADIUS devices and SSIDs or VPN profiles | Each Wi-Fi controller, firewall or VPN concentrator needs its shared secret, outpost address and fallback path set and checked during the cutover window. | One-time. Ask for a device inventory and the cutover test plan per device type. |
| SSO applications to re-federate | Each OIDC, SAML or proxy app needs new client registrations, redirect URIs, attribute mappings and a test login, and apps that cannot be changed add custom work. | One-time. Ask for a per-app list stating which are configured by DeployOpen and which by your team. |
| User and group count, and nested group logic | Larger directories take longer to export, map and validate, and nested or dynamic JumpCloud groups must be rebuilt by hand as authentik groups and policies. | One-time. Ask how group mapping will be validated and how many users are in the test sample. |
| MFA re-enrollment volume | Passwords and MFA enrollments are not carried over in a standard JumpCloud export, so each user or device must re-enroll, which drives help desk load and schedule. | One-time. Ask for the enrollment approach, the help desk support window and the reset procedure. |
| Deployment model: Compose or Kubernetes | The authentik Docker Compose guide positions Compose for test setups and small-scale production, while Kubernetes adds cluster, ingress and storage design work. | One-time for design, then recurring for operations. Ask which model is in scope and who maintains it. |
| Server and PostgreSQL hosting | The authentik architecture stores configuration and data in PostgreSQL, and the server and worker containers need capacity for peak logins and LDAP queries. | Recurring. Ask for sizing based on user count, HA design and backup retention. |
| Upgrades and security patching | authentik publishes named releases and supports specific versions for security fixes, so upgrade windows and testing repeat through the life of the deployment. | Recurring. Ask whether upgrades, testing and rollback are in the retainer or priced per release. |
| authentik edition | The Open Source edition is free with community Discord support only. The pricing page lists Enterprise at per-user and external-user rates, and Enterprise Plus with SLAs and FIPS compliance, so the chosen edition sets the recurring license line. | Recurring for Enterprise editions. Ask the vendor for current pricing and confirm which features your scope needs, such as the RADIUS and LDAP providers. |
What usually goes wrong and how to prevent it
Most failed identity migrations break at the edges: devices and apps that still point at JumpCloud, users who arrive without a working second factor, and infrastructure sized for the old load. The cards below cover the failure points we see most often in this move, each with a check to run before the cutover window.
RADIUS shared secrets and client mismatches
Wi-Fi controllers and VPN concentrators authenticate against a RADIUS server using a shared secret and a configured server address. When the authentik RADIUS outpost replaces JumpCloud Cloud RADIUS, a secret typed differently, or a device still pointing at the old endpoint, causes silent authentication failures that look like password problems. Record every RADIUS client, its address and its secret in the change plan, then test each one against a non-production user before cutover. Confirm the outpost is reachable from the network segments where those clients sit.
LDAP bind DNs and search bases
LDAP clients such as NAS devices, Linux hosts and business applications store a bind account distinguished name, a password and a base DN. After the directory moves, a bind DN that does not match the new object path returns invalid credentials, and an incorrect base DN returns zero users with no error. Before cutover, bind each client with a test account, confirm the search base returns the expected user count, and keep the old JumpCloud values in the runbook so rollback is a configuration change, not a rebuild.
Group filters returning different members
Access decisions often depend on group membership pulled over LDAP, such as which users may log in to a VPN group or sudo on a server. Groups re-created by hand, nested groups flattened differently, or a filter written against JumpCloud's attribute names can return a different member list without any visible error. Export the membership of every group that gates access from JumpCloud, compare it with the authentik result for the same filter, and sign off the diff before the application team switches over.
Users locked out without MFA re-enrollment
Password hashes and MFA enrollments generally do not travel in a directory export, so users who rely on an authenticator app or security key must enroll again in authentik. If the cutover happens before users have enrolled, people are locked out of SSO-protected applications on their first day. Plan a re-enrollment window with a help desk script, keep a set of recovery or bypass codes under controlled issuance, and confirm with your team which MFA methods each user group will use before anyone is switched.
PostgreSQL connection limits after upgrading
authentik stores configuration, sessions, caching and background tasks in PostgreSQL, and the 2025.10 release notes warn of roughly 50% more PostgreSQL connections after upgrading. A deployment sized for a small test may hit its connection ceiling during a busy login period, causing intermittent failures across every application. Before go-live, review the connection limit and pooling settings on the database, load test the login path with expected peak concurrency, and check the release notes for every version in your upgrade path.
Decommissioning JumpCloud too early
Turning off JumpCloud as soon as the first application works removes the fallback for every system not yet tested, and it also removes the only complete copy of the directory state that the team may need for audit evidence or a rollback. Keep JumpCloud in read-only operation until each application, RADIUS client and LDAP consumer has run successfully for a full business cycle. Export and archive the final user, group and policy state before any subscription or tenant change, and confirm the retention requirements with your compliance owner.
How the migration differs by fleet size and starting point
A small office usually has a short list of consumers that still depend on JumpCloud: a handful of SSO applications, perhaps one LDAP bind for a NAS or printer, and a Wi-Fi network that authenticates through RADIUS. The main risk is not scale but the single point of failure, because one authentik host may be the only identity service in the building. Plan the cutover around a short maintenance window and keep a written inventory of every bind account and shared secret before anything is changed. Illustrative example: an office with one LDAP-bound NAS and one Wi-Fi SSID can often be moved in a single change window, provided both are tested first.
- Inventory first: List each SSO app, LDAP bind, RADIUS client and SSH path that uses JumpCloud, with its owner and fallback.
- Single host risk: Confirm whether the authentik deployment runs on one Docker Compose host, and document how it is restored if that host fails.
- Parallel test accounts: Create pilot users in authentik and test each consumer before moving any real staff.
- Local fallback: Keep a local administrator path for the network equipment so a RADIUS failure does not lock out everyone.
- Short overlap: Run both systems in parallel only as long as needed to confirm logins, then disable JumpCloud bindings in a defined order.
Before cutover, confirm with your own team which applications and devices depend on the current JumpCloud setup, since small offices often find undocumented dependencies late.
A multi-site organization is shaped by its network. Wi-Fi controllers, VPN concentrators and branch firewalls each hold a RADIUS client configuration, and each site may reach identity services over a different path. Cutover risk concentrates at the edges: a branch that cannot reach the new RADIUS endpoint can fail while headquarters appears healthy. Sequence the work by site rather than by application, and make each outpost placement a deliberate network decision with latency and failover in mind.
- Site-by-site cutover: Move one site or one SSID at a time, so a failure affects a bounded group of staff.
- Outpost placement: Decide where authentik outposts run relative to each site and whether a site needs a local instance during a WAN outage.
- Shared secret handling: Rotate RADIUS shared secrets per device through a controlled change, and record which secret each device holds.
- Certificate and MFA timing: Re-enroll MFA on a pilot group before widening the rollout, because enrollment problems at scale generate help desk load.
- Rollback plan per site: Keep the JumpCloud configuration for each site until its devices have authenticated successfully for a defined period.
Confirm with your network team the exact RADIUS and LDAP reachability between each site and the authentik deployment, and test it from the device side rather than from a server.
A Linux-heavy fleet that uses JumpCloud mainly for accounts, SSH and sudo has a different center of gravity. authentik covers SSO, LDAP and RADIUS well, but host-level policy such as host-based access control, Kerberos-based login and sudo rules is the domain of FreeIPA. Some organizations therefore run authentik for web SSO and network services while FreeIPA handles hosts. Decide early which system is the source of truth for Linux accounts, because two directories holding the same users create drift and password confusion.
- Source of truth: Choose one directory for Linux accounts and groups before any host is re-pointed, and document the reason.
- Host enrollment: Plan how each host moves from JumpCloud's agent to SSSD or the chosen client, and test login with an existing SSH key on a non-production host first.
- Access rule translation: Map JumpCloud access policies to the rules in the target system, and verify sudo behavior by running privileged commands in a test account.
- Dual running: Keep the JumpCloud agent in place on a host until its new login path has been proven, since removing it first can strand the host.
- Replica planning: Decide whether FreeIPA replicas are needed for resilience before hosts depend on it.
Confirm with your platform team whether the hosts are managed by configuration tooling, because that tooling will need changes before and after each host moves.
Organizations with many users, regulated data or formal change control face the same technical steps but with more evidence requirements and more stakeholders. Cutover approvals, access reviews and audit trails must survive the move, and the exported JumpCloud data must be handled as sensitive material. The risk here is less about a single outage and more about an incomplete or undocumented change. Set acceptance criteria and sign-off points before the first user is migrated.
- Written acceptance criteria: Define what a successful login, MFA enrollment and RADIUS authentication means for each consumer before the change window.
- Export handling: Treat user exports as sensitive, restrict who can read them, and delete working copies once the import is verified.
- Change records: Keep a record of each shared secret rotation, group mapping and disabled binding for later review.
- Support readiness: Choose whether support comes from internal staff or a retainer, and confirm escalation paths for the first weeks after cutover.
- Compliance evidence: Ask any auditor you work with which configuration exports and logs they expect, because DeployOpen prepares evidence but independent auditors and certification bodies assess it.
Confirm with your compliance and security leads which controls the identity change touches before the project timeline is agreed.
How much effort does a JumpCloud to authentik migration take?
What drives the cost of moving from JumpCloud to authentik?
The cost is driven by the number of applications, LDAP clients and RADIUS devices that must be repointed, the number of users and groups, and how much MFA re-enrollment is needed. The software side has two lines: authentik's open-source edition is MIT licensed for the core, while the Enterprise edition is priced per user per month on the authentik pricing page, plus a per external user charge, so the edition you choose changes the recurring cost. Infrastructure is a second recurring line: authentik runs as a server container, a worker container and PostgreSQL, so you pay for hosts, database operations and backups in your own environment. One-time costs are the migration work itself, including testing and cutover. Ask any quote to split one-time work from recurring support and to state which edition it assumes.
How long does a JumpCloud to authentik migration take?
No researched duration is available for this migration, so treat any timeline as something to agree in the written scope. The main timeline drivers are the size of the inventory of SSO apps and LDAP or RADIUS consumers, how many of those depend on group-based access that must be rebuilt, whether an existing test environment exists, and how many change windows your organization allows for cutover. Parallel running, where JumpCloud and authentik both authenticate users for a period, usually adds time but lowers risk. Ask for the proposed phases, the number of cutover windows and the rollback plan as part of the quote.
What does the internal team need to provide during the migration?
The internal team holds the knowledge that is not written down in the Admin Portal. Plan for these inputs before work starts:
- An inventory of every SSO application, its protocol and its owner, plus the LDAP bind accounts and RADIUS shared secrets in use.
- Named approvers for user, group and access decisions, since some JumpCloud groups may not map cleanly to authentik groups.
- Access to the test environment, DNS and certificate changes, and the device management or network teams who will repoint clients.
- Change windows, a communications plan for end users and a named person to sign off each cutover.
Identify who owns each application after cutover so support questions have a destination.
Can our own IT team migrate from JumpCloud to authentik without a partner?
Yes, a capable internal team can do this, provided it has experience with OIDC, SAML, LDAP and RADIUS, PostgreSQL operations and the specific SSO applications in use. The effort is concentrated in the testing and cutover stages rather than in the initial configuration. Teams that choose to do it themselves should budget for their own engineers' time, a staging environment and the risk of a failed cutover affecting logins. Teams without this experience, or with many critical applications, often prefer a fixed-scope engagement with written deliverables. Be aware that the authentik community edition offers community support only, which matters if you need a supported path during the move.
Can MFA enrollments be carried over from JumpCloud to authentik?
In general, MFA enrollments are not exported in a form that can be imported directly, so plan for users to re-enroll their authenticators in authentik. Confirm this with JumpCloud and with the authentik documentation for your specific factor types, because the export options and any credential migration paths are not covered in the researched facts supplied here. Practical steps include deciding which factors users must re-register, scheduling enrollment before cutover, offering a temporary bypass or help-desk verification path, and keeping a record of who completed enrollment. Shared secrets for RADIUS devices are a separate matter and need to be reconfigured on both sides.
What does a fixed-scope DeployOpen engagement cover for this migration?
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. For this migration, a written scope would normally name the authentik deployment, the user and group rebuild, the repointing of LDAP and RADIUS clients, the SSO application re-federation, the MFA re-enrollment approach, the cutover plan and the documentation handed over. DeployOpen does not publish a price list, so the quote follows from that written scope. Ongoing support, upgrades and testing are available as retainers. Ask for the exclusions in writing as well, such as device management, which authentik does not replace.
Where to confirm authentik and export details before you plan
Before you fix a migration plan, check the current authentik edition and feature list on the authentik pricing page. The free edition covers OIDC, SAML, LDAP and RADIUS, but Enterprise features such as the Microsoft Entra ID and Google Workspace integrations, mTLS client certificates and password history are paid. If your SSO apps or RADIUS devices depend on any of those, the edition decision comes before the cutover schedule, and the pricing page is the place to confirm which items sit in which tier for the version you will deploy.
Next, confirm protocol and component behavior in the authentik providers documentation and the architecture documentation. The providers guide tells you which provider types exist for OIDC, SAML, LDAP, RADIUS and proxy access, which determines how each JumpCloud SSO app and LDAP or RADIUS client maps to an authentik object. The architecture guide describes the server, worker and PostgreSQL components, which sets the rollback and backup scope. Read the 2025.10 release notes as well, since they describe the move away from Redis and the higher PostgreSQL connection count your database sizing must absorb.
Finally, confirm JumpCloud's current export behavior directly with JumpCloud before you rely on any export step. Ask which user, group, device and MFA data the Admin Portal exports in its current form, whether passwords or MFA enrollments are excluded, and how long the account remains readable after cancellation. Request this in writing and record the answer in your migration runbook, since the export limits determine which users must re-enroll and which RADIUS and LDAP settings you must recreate by hand.
How DeployOpen scopes, runs and supports the migration
DeployOpen plans and implements the move from JumpCloud to authentik inside your own infrastructure, sequencing the cutover so LDAP clients, RADIUS devices and SSO apps keep authenticating. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory every JumpCloud-bound app, LDAP client, RADIUS device and SSO integration before any work starts
- Agree in writing which groups, MFA policies and outposts move to authentik and which stay in JumpCloud
- Confirm the hosting target, PostgreSQL arrangements and whether the Open Source or Enterprise edition fits the requirement
How we build
- Stand up authentik in a test environment and rebuild groups and sources from the exported JumpCloud user list
- Repoint LDAP and RADIUS clients to authentik outposts in a staged order, tested against each device class
- Re-federate SSO applications and document MFA re-enrollment steps with the rollback path for each cutover wave
How we hand over
- Deliver the configuration, runbooks and cutover record in writing, matched to the agreed scope
- Document each application, outpost and client endpoint with its owner, its test result and its rollback step
- Walk your operations team through backup, upgrade and user lifecycle tasks before the JumpCloud contract ends
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Plan authentik version upgrades against the project's published security release notice and your change windows
- Prepare the controls and evidence your compliance assessor will ask for, while independent auditors issue any audit outcome
