Moving FreeIPA from CentOS to RHEL IdM

Can a team move FreeIPA from CentOS to RHEL IdM without rebuilding every client?

The move is done by adding RHEL IdM replicas to the existing FreeIPA topology and then retiring the CentOS, AlmaLinux or Fedora servers one at a time. In-place conversion is not supported, so there is no single step that turns an existing server into a RHEL IdM server. Because the realm, DNS domain and certificate authority stay the same, most enrolled clients keep working without re-enrollment, but this depends on your environment and must be tested. The effort is driven by how many servers you run, how many sites they span and how well the current topology is documented. Confirm with Red Hat how mixed-version topologies are supported during the transition, since that sets how long old and new servers can coexist.

The main work is topology, DNS, certificates and client checks. Start by comparing your current layout with the FreeIPA deployment recommendations, which advise two to three replicas per datacenter, no more than four replication agreements per replica, and at least one replica per datacenter running PKI or DNS where those services are used. Add RHEL replicas so every site keeps that coverage before any old server is removed. Then check that each client's resolv.conf lists at least two DNS servers and that the new servers answer for them.

Certificates and backups need explicit attention. The first server handles certificate renewal and CRL publication by default, so move that role on purpose and confirm which server holds it before retiring the old one. Do not restore an older backup into the live topology to recover from a failed step, because that can break replication. Test each removal on a copy of the deployment, and record client checks such as Kerberos login, identity lookup and SSSD behavior for each site. Ask any partner quoting this work to name those checks and the rollback point in writing.

What maps cleanly from FreeIPA on CentOS to RHEL IdM and what does not

This table compares the FreeIPA components you run today on CentOS, AlmaLinux or Fedora with their RHEL IdM counterparts and flags where migration needs extra work. Read each row as a question to confirm with Red Hat documentation and your own test replica before planning cutover. The main takeaway is that data and policy usually carry over through replicas, while the package versions, CA hierarchy and support status need explicit checks first.

Capability	Source FreeIPA on CentOS or similar	RHEL IdM target and migration notes
Users and groups	Stored in 389 Directory Server and replicated between multi-master servers	Carried over by adding RHEL IdM replicas to the existing topology; confirm object counts and attributes on a test copy
Kerberos realm	One realm with an MIT Kerberos KDC on each server	Realm name must stay the same so existing keytabs and client tickets keep working; confirm realm and principal handling in the RHEL IdM release you deploy
Dogtag certificate authority	Integrated CA; the first server handles renewal and CRL publication by default	Confirm the CA hierarchy, sub-CAs and which server holds the renewal role before promoting RHEL replicas, since this is the riskiest area
DNS zones	Integrated or external DNS zones replicated with the directory	Zone data replicates with the topology; confirm forwarders, reverse zones and DNSSEC settings match on the RHEL side
HBAC and sudo rules	Stored as directory objects in the IPA tree	Expected to replicate with the tree; verify each rule with hbactest and a sample login before moving host groups
AD trusts	Cross-forest trust configured through Samba components on the source servers	Trust objects and ID mapping need re-validation on RHEL IdM; confirm the supported Windows versions and trust type for your forest
OTP tokens	HOTP and TOTP tokens stored in the directory, with optional RADIUS proxying	Tokens should replicate with user data; confirm token synchronization and RADIUS settings on a test login
Backups	ipa-backup and ipa-restore on each server; restoring an old backup into a live topology can break replication	Take a fresh backup on the source before adding RHEL replicas and treat any restore as a separate, planned procedure
Package and version alignment	Community builds on CentOS, AlmaLinux or Fedora with their own release cadence	Confirm the RHEL IdM version, minimum source version and supported upgrade path with Red Hat before scheduling work
Support status	Community support through the FreeIPA project and your own team	Red Hat support applies only to RHEL IdM servers; confirm what your subscription covers during a mixed-topology period

Which documented paths move data between FreeIPA deployments

Three documented routes can carry FreeIPA data between servers or deployments: adding new servers as replicas, restoring from backups, and migrating between realms. Each one answers a different question, so the choice depends on whether you are extending an existing topology, recovering from failure, or consolidating into a new realm.

Adding RHEL IdM replicas

Adding RHEL IdM servers as replicas of your existing CentOS, AlmaLinux or Fedora servers is the route that keeps one realm and its data in place while the server platform changes. Replicas copy the directory, Kerberos and certificate data from peers, so the existing topology keeps serving clients during the move. Check that the RHEL IdM version can join your current FreeIPA version, and confirm with Red Hat which replication and version combinations it supports before you add the first server.

Backups for recovery testing

The ipa-backup and ipa-restore tools produce full backups or online data-only backups, which is useful for proving that you can recover a server. Restores are not a migration method, because restoring an outdated backup into an active replica topology can break replication. Test restores on an isolated host, and confirm which server holds certificate renewal and CRL publication before you restore anything.

ipa-migrate between realms

The ipa-migrate tool copies users, groups, certificates, sudo and HBAC rules, hosts, services, DNS, OTP tokens and policies between two FreeIPA deployments over LDAP. It fits consolidating or rebuilding into a new realm, where the target is a separate deployment. It is the wrong tool when you only need the same realm on newer servers, because the target would then be a different realm with its own keys, clients and enrollments.

Client re-enrollment after realm moves

A move into a new realm means every enrolled Linux host, service keytab and Kerberos principal must be handled again. Migrated accounts typically need password resets or key regeneration, and hosts may need re-enrollment. Plan the client inventory and cutover order before the first copy so the work is not discovered during the change window.

Limits of the documented paths

None of the three paths converts an existing server in place, and none is described as a way to change operating system family under a running server. Confirm each step, version pairing and support statement against Red Hat's IdM documentation and your own lab test before you rely on it. Treat any path that is not in the supplied documentation as unsupported until your vendor confirms it.

How the replica-based move runs from inventory to decommission

The sequence replaces CentOS, AlmaLinux or Fedora FreeIPA servers with RHEL IdM replicas in a controlled order, so identity, certificates and DNS stay available to clients throughout. Each step ends with a check that the next step depends on.

Inventory servers, roles and clients
Record every FreeIPA server with its operating system and FreeIPA version, the roles it carries (CA, DNS, NTP, trust controller), the datacenter it sits in, and the replication agreements between servers. Add the enrolled client count, the client distributions and any hosts that use the servers as their only DNS resolvers. Your team owns this inventory, and DeployOpen can review it with you. It is done when every server and role is listed and each role has a named owner in the new topology.
Confirm the CA and DNS placement
Identify which server currently performs certificate renewal and CRL publication. FreeIPA's backup documentation notes that the first server handles these duties by default, so this role does not move automatically when you add new servers. Write down where the integrated CA and DNS zones live and which servers clients query. It is done when you have a written map of CA and DNS duties that the cutover plan will reassign deliberately.
Rehearse the move on a lab copy
Build a lab topology on RHEL that mirrors the production layout, then restore or copy the current data into it and join a RHEL IdM replica to that copy. Test client enrollment, Kerberos login, certificate issuance and DNS resolution, and record every failure with its fix. Run ipa-backup beforehand so you have a known-good restore point. It is done when the rehearsal completes without manual repair and the runbook reflects what you actually typed.
Add RHEL IdM replicas in each datacenter
Install RHEL IdM replicas in each datacenter and join them to the existing topology through replication agreements. FreeIPA's deployment recommendations advise at least two to three replicas per datacenter and no more than four replication agreements per replica, so check the agreement count before you add links. Place PKI and DNS on the new replicas where those services will run. It is done when each new replica replicates cleanly, appears in the topology view, and holds the expected services.
Run a parallel period with client and DNS checks
Keep the old and new servers running side by side while you point test clients at the RHEL replicas first. Check Kerberos ticket issuance, SSSD lookups, host-based access and DNS answers from each site, and confirm that changes made on one server reach the others. Track replication status and error logs during this period. It is done when test and pilot groups authenticate and resolve names through the new servers without errors.
Move CA renewal and CRL duties
Transfer the certificate renewal and CRL publication duties from the old first server to a RHEL replica, as planned in step two. Verify that the new server renews certificates, publishes the CRL and serves revocation checks, and confirm that the old server no longer performs these duties before you stop it. Keep the old server's CA data until this check passes. It is done when the new server performs the CA duties and the old server is no longer the default renewal point.
Cut over clients and retire the CentOS servers
Point the remaining clients and DNS resolver lists at the RHEL replicas, one group at a time, and watch authentication and DNS metrics after each group. When no client or service depends on an old server, remove it from the topology, delete its replication agreements and decommission the host. Your change record should list each removed server and the date of removal. It is done when the old servers no longer appear in the topology and no client is configured to use them.

How effort changes with topology, DNS placement and CA role

A single datacenter with integrated DNS and CA is usually the most contained case. The existing CentOS, AlmaLinux or Fedora servers form one replication topology, and the replacement RHEL IdM replicas can be added to it, promoted into the roles the old servers held, and then the old servers removed. Work concentrates on one site, one set of network paths and one change window, although the topology still needs to stay healthy throughout.

Replica count: Plan replacement replicas so the topology keeps at least two or three servers in the datacenter during the transition, in line with the deployment recommendations.
CA role: Confirm which server currently handles certificate renewal and CRL publication, because the first server holds that role by default and it must move deliberately.
Integrated DNS: DNS zones, forwarders and the resolv.conf entries on clients must point to surviving servers before any old server is removed.
Backups: Take a backup before each topology change, since restoring an outdated backup into an active topology can break replication.
Client impact: Clients usually keep working through the change if at least one server remains reachable, so confirm which server each client is configured to use.

Before starting, ask your team to confirm the exact server roles, the DNS delegation and the CA chain in writing.

What drives cost and duration in a CentOS to RHEL IdM move

This table lists the factors that change the effort and cost of replacing FreeIPA servers on CentOS, AlmaLinux or Fedora with RHEL IdM replicas. Read each row as a question to answer in your environment before requesting a quote, noting who pays and whether the cost is one-time or recurring. The main takeaway is that topology size, certificate and DNS roles, and backup confidence usually matter more than the number of clients.

Driver	Why it changes cost or effort	What to ask for in a quote
Replicas and sites	Each datacenter needs replicas built, verified and retired, so cost grows with server count and site count. The FreeIPA recommendations suggest two to three replicas per datacenter.	Itemized count of new RHEL IdM replicas, sites covered, and retirement steps for each old server.
Replication agreement limits	The recommendations advise no more than four replication agreements per replica, so a dense mesh needs redesign before the move, which adds design time.	Confirmation of the target topology and agreement map, and whether topology redesign is in or out of scope.
DNS and client count	Clients with resolv.conf entries pointing at old servers must be updated, and DNS servers need at least two per client. Client count drives test and rollout effort.	Client inventory method, DNS cutover steps, and who performs per-client changes (vendor, your team, or automation).
CA and certificate role	The first server handles certificate renewal and CRL publication by default. Moving that role and checking issued certificates adds recurring verification work until it is confirmed.	Plan for CA role transfer, certificate inventory, and who owns renewal monitoring after cutover.
Trust and OTP dependencies	Active Directory trusts, RADIUS-proxied OTP checks and HOTP or TOTP tokens each need separate testing on the new servers, and some may need vendor or network changes.	List of trusts, OTP methods and RADIUS endpoints in scope, with test cases for each.
Backup confidence	Restoring an outdated backup into an active replica topology can break replication. Weak backup evidence means more pre-move rehearsal and a longer rollback plan.	Backup verification steps, restore rehearsal scope, and the rollback procedure with its time limit.
Change windows	Limited maintenance windows force phased replica promotion and extend parallel running, which increases coordination and staff time.	Number of change windows assumed, parallel running period, and any after-hours labor included.

What usually goes wrong in replica-based FreeIPA moves

Replica-based moves fail less often from the new RHEL IdM servers themselves than from the old estate around them: stale backups, unnoticed CA duties, and clients that still point at the old names. Each card below names one failure, why it matters during a move from CentOS, AlmaLinux or Fedora, and what to check before cutover.

Restoring an outdated backup

A backup taken weeks earlier and restored into a live replica topology can roll back data that other servers have already changed, and this can break replication. Never restore an old ipa-backup into a running topology as a shortcut. Before the move, confirm which backup is current, take a fresh full backup from the source servers, and rehearse restores only on an isolated copy.

Breaking replication agreements

Replicas that are added, removed or renamed out of order can leave replication agreements pointing at servers that no longer exist, or push the topology over the recommended limit of four agreements per replica. Map every agreement before the move, add the new RHEL replicas one at a time, and check replication health after each step rather than at the end.

Losing CA renewal and CRL duties

By default the first server in a topology handles certificate renewal and CRL publication. If that role stays on a server being retired, renewals can silently stop and certificates can expire. Identify which server holds these duties, move them to a RHEL replica with the CA role deliberately, and confirm renewal and CRL publication on the new server before decommissioning the old one.

Clients with hardcoded server names

Enrolled Linux hosts, scripts and configuration files that name a specific IdM server will fail once that server is retired, even when other replicas are healthy. Inventory where server names are referenced, including ipa-client configuration, sssd.conf files and automation, and switch them to the domain-level names before cutover so clients can reach any remaining replica.

DNS resolver lists with one server

Clients whose resolver configuration lists fewer than two DNS servers lose name resolution when the single listed server is retired, which also breaks Kerberos and LDAP lookups. The deployment recommendations call for at least two DNS servers in each client's resolv.conf. Check every client's resolver list against the new RHEL DNS servers and fix any list that is short before retiring old servers.

Assuming RHEL support covers a mixed estate

Red Hat support for Identity Management applies to RHEL IdM servers, not to a topology that still runs FreeIPA on CentOS, AlmaLinux or Fedora alongside them. A mixed estate may fall outside the support statement during the transition. Ask Red Hat and your subscription contact in writing which combinations are covered, and document the period when both platforms run side by side.

Questions buyers ask before moving FreeIPA from CentOS to RHEL IdM

Can we convert our CentOS or AlmaLinux FreeIPA servers to RHEL IdM in place?

No. In-place conversion is not supported, so the route is to build RHEL IdM servers, join them to your existing topology as replicas, move the server roles and clients over, and then retire the old servers. Replication carries the directory, Kerberos and certificate data across during the transition. Before you plan, confirm the exact procedure, prerequisites and supported version pairing for your source and target releases in Red Hat's current IdM documentation, because the answer depends on those versions. Your team should also confirm that the old and new servers can replicate with each other before any production change.

How long does a FreeIPA move from CentOS to RHEL IdM take?

The duration depends on the size and layout of your topology, and no fixed figure applies to every estate. The main drivers are the number of servers, the number of datacenters, the roles each server holds (certificate authority, DNS, NTP), and how many clients must be repointed or re-enrolled. Current FreeIPA deployment guidance recommends at least two to three replicas in each datacenter and no more than four replication agreements per replica, so a larger multi-site layout adds planning and validation work. Ask for a written plan with phase gates for building, replicating, validating, moving roles, repointing clients and decommissioning, and make each gate a go or no-go decision.

What cost drivers apply to a FreeIPA move to RHEL IdM, and who pays for what?

The cost has several parts. Red Hat subscriptions for RHEL and IdM are paid to Red Hat, and their terms should be confirmed directly with Red Hat. New replica hardware or cloud instances are paid to your infrastructure provider. Implementation services, when you use them, are paid to DeployOpen under a fixed scope agreed in writing, and internal staff time is an cost you carry regardless. The migration itself is one-time, while subscriptions and any support retainer recur. Costs rise with the number of replicas, sites, CA and DNS roles, integrations such as Active Directory trusts or RADIUS proxying, and clients to re-enroll. When you request a quote, ask for an itemized scope, the exclusions, and which subscription terms are assumed.

What does the migration need from our own team?

The work needs named owners for the directory, DNS, networking, certificates and each application that binds to LDAP or uses Kerberos. Your team must approve change windows, provide access to the servers and clients, and decide which services move first. Backups are a critical prerequisite. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so take a current backup and test the restore on a copy before cutover. Your team should also know that the first server in the topology handles certificate renewal and CRL publication by default, so those duties must be moved and verified deliberately rather than assumed to follow the replicas.

Can our own team run the move without an outside partner?

Yes, if your team already runs FreeIPA and has the time, a test environment and a rollback plan. The work is mostly sequencing and verification, and it is well documented in the upstream and Red Hat material. The points that most often need experienced hands are certificate and CRL handling, replication topology changes, and moving the trust and ID ranges without breaking logins. DeployOpen plans, implements, hardens, backs up, documents and supports FreeIPA inside your own cloud accounts, data centers or air-gapped networks, typically under a fixed scope agreed in writing before work starts. Ask any partner to show how the scope covers rollback, client repointing and the cutover runbook.

Does moving from CentOS to RHEL IdM change our support arrangements?

It can, and the change depends on your subscription and vendor policy, which this page does not set. FreeIPA itself is a community project licensed under GPL-3.0-or-later with no paid edition, so support for the upstream code is community support. RHEL IdM support comes through a Red Hat subscription, and Red Hat's terms define which releases, components and configurations are covered. Confirm with Red Hat which support window applies to the version you will run, whether your current CentOS, AlmaLinux or Fedora servers are covered during the overlap, and how a mixed topology is treated during transition. DeployOpen is not a Red Hat partner, so any DeployOpen support is a separate written agreement that covers the scope you sign.

How does an Active Directory trust change when we move to RHEL IdM?

The trust must be rebuilt or verified on the new servers before any production login depends on it. FreeIPA establishes a cross-forest trust with Active Directory through Samba components, and the IPA DNS domain must not overlap with any domain in the AD forest. During the move, check that the trust objects, ID ranges and ID views replicate correctly to the RHEL IdM replicas and that AD users resolve to the expected Linux identities on test clients. Keep the trust out of the cutover until those checks pass. Ask your vendor and your Windows team whether the trust must be re-established or can be carried over, and test a sample of AD logins on a copy of the topology first.

What changes for your team and your clients after cutover

The first change to plan for is the server name. Once the RHEL IdM replicas take over, every client and automation that points at the old CentOS, AlmaLinux or Fedora servers needs a new target. Check the resolv.conf entries, the enrollment configuration used by ipa-client-install in your bulk enrollment scripts, and any hard-coded server names in SSSD or configuration management. Confirm each item against the client inventory, because a machine that was missed will still try to reach a decommissioned server and fail quietly until someone logs in. Also confirm which clients use the DNS servers you are retiring, since FreeIPA recommends at least two DNS servers in each client's resolver configuration.

On the operator side, monitoring, backup and certificate jobs are the changes most often forgotten. Health checks that probe the old hostnames, backup schedules that run ipa-backup against the retired servers, and alerts on the Dogtag certificate authority must all move to the new topology. The FreeIPA backup documentation notes that the first server handles certificate renewal and CRL publication by default, so confirm which RHEL IdM server holds that role after cutover and that its jobs are monitored. Record the new owner for each runbook step in the inventory, not only the server names.

The support boundary also moves. Your vendor, distribution and FreeIPA support terms now apply to RHEL IdM servers, so the platform team should confirm in writing which operating system, package and subscription support covers the servers, and which items remain your responsibility, such as client distributions that stay on CentOS, AlmaLinux or Fedora. Update the escalation contacts, change records and the incident playbook to match. Treat this as a decision to close before cutover, because an unclear boundary during an outage is harder to resolve than a documentation gap found in advance.

How DeployOpen scopes, delivers and supports a FreeIPA distribution move

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so a move from FreeIPA on CentOS, AlmaLinux or Fedora to RHEL IdM is handled as a fixed-scope engagement with written deliverables. The work follows the replica-based path described on this page, with each stage agreed, tested and handed over before the next one starts.

How we scope

Inventory every existing FreeIPA server, replica, CA role, DNS role and trust in the current topology before proposing a target.
Confirm which RHEL IdM subscription and versions your organization will run, and which of your clients depend on the current realm.
Agree in writing which replicas, roles and client groups are in scope, and what is excluded, before work starts.

How we build

Stand up RHEL IdM replicas in the target environment and verify replication agreements against the topology you approved.
Test promotion of CA and DNS roles, certificate renewal paths and CRL publication on a copy of the realm first.
Run client re-enrollment and SSSD checks on a representative set of hosts, then sequence the cutover one host group at a time.

How we hand over

Deliver the as-built topology, server role map, replication diagram and the cutover runbook you approved.
Document backup and restore steps, including the ipa-backup procedure and the rule for never restoring an outdated backup into an active topology.
Provide a decommissioning checklist for the old CentOS, AlmaLinux or Fedora servers, with your team trained on the new operating procedures.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the migration.
Confirm with your RHEL account team which support terms apply to the RHEL IdM servers and which do not apply to the earlier platform.
Review health checks, backups and release notes with your team on a schedule you agree, so changes to FreeIPA are planned rather than reactive.

Moving FreeIPA from CentOS or other distributions to RHEL IdM