Why moving FreeIPA servers from RHEL 8 to RHEL 9 is a replica migration, not an upgrade
In-place upgrades of Identity Management (IdM) servers from RHEL 8 to RHEL 9 are not supported. The move is done by adding RHEL 9 replicas to the existing topology, moving the server roles that RHEL 8 currently holds onto them, and then retiring the RHEL 8 servers. Teams that treat the work as a package update on the existing machines will find that the supported path is different from what they planned. FreeIPA is the upstream project, and Red Hat ships it as *Identity Management* in Red Hat Enterprise Linux, so the RHEL 9 IdM guides describe the same software you run today. Red Hat's migration guide, Migrating to Identity Management on RHEL 9, sets out the sequence. Read it against your own topology before you schedule anything, and confirm the exact steps for your minor release, because the procedure is tied to the RHEL versions involved.
Red Hat advises migrating all IdM servers quickly. Mixing IdM versions for long periods can cause incompatibilities between replicas, so a slow, drawn-out migration carries more risk than a compact one. Before starting, inventory every server, its role (CA, DNS, CRL, replica) and the clients that depend on it, and agree on a window in which the RHEL 8 and RHEL 9 servers will coexist. Confirm with your Red Hat support contacts or documentation whether any version constraints apply to your environment.
What changes for existing deployments when moving to RHEL 9
This table compares the changes that affect an IdM move from RHEL 8 to RHEL 9, with the impact of each on existing servers and the action to take. Read it before scheduling replica work, since the version-mixing window and the CA role move set the order of every other step.
| Change | Impact on existing deployment | Action needed |
|---|---|---|
| In-place upgrade of RHEL 8 IdM servers | Not supported. Upgrading an existing RHEL 8 server to RHEL 9 in place is outside the supported path. | Add RHEL 9 replicas and retire RHEL 8 servers instead of upgrading them in place. |
| CA renewal server role | The RHEL 8 server currently renews the CA certificates by default, so renewal duties depend on it until moved. | Make a RHEL 9 replica the CA renewal server before decommissioning the RHEL 8 server. |
| CRL generation | CRL publication follows the CA role and must move with it, or revocation data can go stale. | Move CRL generation to the RHEL 9 replica and confirm publication from it. |
| Mixed IdM versions for long periods | Red Hat advises migrating quickly because mixing versions for long periods can cause incompatibilities. | Set a short migration window and plan the replica, role move and retirement steps as one sequence. |
| Restoring an old backup into the topology | Restoring an outdated backup into an active replica topology can break replication. | Take a fresh backup before role changes and avoid restoring older backups during the move. |
| New web UI beta in 4.13 | Arrives with newer 4.13 releases as a beta, so existing administrators may see a different interface. | Confirm the RHEL 9 build includes the feature and brief administrators on the beta status. |
| DNS over TLS and LDAP system accounts | Introduced in 4.13 and change how clients reach DNS and how service accounts are created. | Test client DNS settings and service account handling on a RHEL 9 replica before cutover. |
| Random serial numbers by default | New certificates use random serial numbers by default, which changes how serial numbers look to tools that expect sequential values. | Check any scripts or audit tools that read certificate serials before the CA role moves. |
| 4.13.4 security fixes | Fixes two CVEs, including LDAP access control flaws, and hardens authentication checks in the API. | Confirm that the RHEL 9 build in use includes these fixes and record the package version for the audit trail. |
Backups, inventory and a test topology before the first replica joins
Before a RHEL 9 replica joins, the current topology needs a verified backup and a written map of every role the RHEL 8 servers play. A test topology on RHEL 9 lets the team rehearse each stage against the same layout production uses.
Full backup from the first server
Take a full ipa-backup from the current first server, the one that handles certificate renewal and CRL publication by default. Copy the archive off the server and confirm it is readable before any change. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so this backup is a rollback point for the current state only, not a substitute for the live servers.
Replica and role inventory
List every IdM server with its OS version, its replication agreements, and whether it runs the CA, DNS or NTP services. Record which server holds the CA renewal role and which generates CRLs, because those roles move to the new RHEL 9 replica. The FreeIPA guidance allows no more than four replication agreements per replica, so check the topology map against that limit before adding servers.
DNS and client resolver entries
Map which servers answer DNS and which clients point at them. Each client's resolv.conf should list at least two DNS servers, so retiring a RHEL 8 server without updating those entries can leave clients with a single resolver. Plan replacement addresses in advance and confirm that the RHEL 9 replicas answer the same zones before any RHEL 8 server is removed.
Trusts and integrations
Document any cross-forest trust with Active Directory, along with the sync agreements, certificate consumers, Ansible roles and external services that depend on IdM hostnames or CA certificates. Confirm which of these reference a specific server name, since retiring a RHEL 8 host changes that name. Trust configuration should be reviewed against the Trusts page requirements before the move starts.
Test topology on RHEL 9
Build a RHEL 9 test topology that mirrors production: the same domain, the same number of replicas, the same DNS and CA roles, and a copy of the backup restored into an isolated network. Use it to rehearse adding a replica, moving the CA renewal and CRL roles, and retiring a server. Confirm with your Red Hat support path which RHEL 9 IdM version your subscription provides before you build it.
Change window and rollback decision
Agree on a window, a named owner for each stage, and the point at which the team stops and rolls back. Red Hat advises migrating all IdM servers quickly because mixing versions for long periods can cause incompatibilities, so the window must cover the full sequence, not one step. Record the rollback criteria in writing, including who decides and which checks must pass before the next server is touched.
Step-by-step: adding RHEL 9 replicas and retiring RHEL 8 servers
This sequence moves every IdM server role from RHEL 8 to RHEL 9 without an in-place upgrade, so the topology keeps serving logins, certificates and revocation lists at each stage.
Confirm the current topology and back up
Before any change, the team records every IdM server, its role (CA, DNS, NTP), its datacenter and its replication agreements, and confirms that each datacenter has two to three replicas and no more than four replication agreements per replica, as the deployment recommendations advise. The team then takes a full backup with ipa-backup on the server that currently renews certificates and publishes the CRL, and stores it off the server. Done when the backup is verified and the topology inventory is signed off by the owner of the identity service.
Install RHEL 9 replicas alongside RHEL 8 servers
The platform team installs one RHEL 9 server per datacenter as a replica of an existing RHEL 8 server, with the same FreeIPA version family, and enrolls it into the topology. Each new replica is installed with the CA and DNS roles that match the RHEL 8 servers it will replace. Done when ipa-replica-manage list shows the new server as a replica with working agreements and the admin can log in to it.
Verify replication and DNS on new replicas
The team checks that directory data replicates in both directions between the RHEL 9 replicas and the RHEL 8 servers, confirms that Kerberos logins succeed against each new server, and tests that DNS answers for the IdM zones from each new replica. Clients should list at least two DNS servers in resolv.conf, so the team confirms those resolvers are reachable. Done when a test user, a test host and a test DNS record created on one server are visible on all others within the normal replication interval.
Move the CA renewal server role
Before changing anything, the team records the current CA renewal server, takes a fresh ipa-backup, and confirms the rollback procedure with the owner of the change. The renewal role is then moved to a RHEL 9 replica, and the team checks that the CA renewal master setting reports the new server. Rollback point: the previous renewal server stays in the topology and can be set back as renewal master until the next step is complete. Done when the new renewal master is reported and a test certificate request succeeds against it.
Move CRL generation to a RHEL 9 replica
The team moves CRL generation to the same RHEL 9 replica that now renews certificates, since the backup documentation notes that the first server handles renewal and CRL publication by default. A rollback point is taken again before the change. After the move, the team confirms the CRL is regenerated and published from the new server and that the revocation list served to clients is current. Done when a revoked test certificate is listed in the newly published CRL and the old server no longer publishes it.
Confirm certificate and CRL publication
The team waits through a full publication cycle on the new roles and checks the CA service health, certificate issuance for a service host, and CRL availability from each datacenter. Any RHEL 8 server still holding a role is reviewed against the Red Hat migration guide before it is removed. Done when every role has a working owner on RHEL 9 and the monitoring reports no failed CA or CRL tasks.
Remove RHEL 8 servers one at a time
Each RHEL 8 server is removed in a separate change window, starting with the one holding the fewest roles. The team runs the removal procedure from a RHEL 9 server, confirms the replica topology after each removal, and checks replication, DNS and Kerberos logins before continuing to the next server. Red Hat advises moving all servers quickly because mixing versions for long periods can cause incompatibilities, so the team should plan the sequence to finish without long gaps. Done when only RHEL 9 servers remain in ipa-replica-manage list and the final checks pass.
Record the final topology and close the change
The team updates the topology inventory, client resolver lists, monitoring targets and backup jobs to reference only the RHEL 9 servers, and takes a new full backup from the final renewal server. The retired servers are kept in a documented state until the owner accepts the change. Done when the inventory matches the running topology and the new backup is stored and verified.
How to test each stage and roll back a failed role move
Test each stage before you move to the next one. After the RHEL 9 replica joins, confirm that replication is healthy in both directions with the topology and replication status tools described in Red Hat's guide, and that the new server holds the same user, host and service data as the RHEL 8 servers. Then check certificate issuance by requesting a test certificate from the new CA renewal server, and check CRL publication by confirming that the CRL is generated and retrieved from the RHEL 9 host after the role moves. Confirm exact commands and expected output against Red Hat's RHEL 9 migration guide for your release, not against memory or older FreeIPA documentation.
Run client and service checks as well. Authenticate a test user with Kerberos from an enrolled client, resolve hosts and SRV records against the DNS servers that the RHEL 9 replica serves, and, if you run a cross-forest trust, confirm that trust health and AD user lookups still work after each step. Record the results of every check so that you can compare them with the baseline you took before the first replica was added. Note that DNS and trust checks only prove something if the test clients point at the servers you are retiring and at the new replica, so cover both paths.
Rollback is limited. Downgrading a RHEL 9 server to RHEL 8, or restoring an old RHEL 8 image onto a live topology, is not a route back, and the FreeIPA backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Your real safety net is the full backup you take before the first change, tested on an isolated staging topology that mirrors your replica count, DNS placement and CA role. Practice the role move, the failure you expect, and the restore procedure there first. In production, a failed step usually means stopping the move, fixing the new server or its roles, and keeping the RHEL 8 servers in service until checks pass.
What makes a RHEL 8 to RHEL 9 IdM move take longer
This table lists the factors that expand or shrink the work of moving IdM servers from RHEL 8 to RHEL 9. Read each row as a question to answer about your own topology before you agree on a schedule. The main takeaway is that replica count, CA and DNS roles, and external dependencies on server names usually matter more than the operating system step itself.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of replicas and sites | Each RHEL 8 server needs a RHEL 9 replacement added, verified and retired, and multi-site topologies add checks per datacenter. | Count servers per site before planning, and sequence replacements one site at a time. |
| Replication agreements | Every new RHEL 9 replica joins the existing agreement mesh, so dense topologies need more verification after each join. | Confirm the agreement layout is within the recommended limit of four per replica before adding servers. |
| CA renewal and CRL roles on RHEL 8 | Red Hat's guide has you make a RHEL 9 replica the CA renewal server and move CRL generation to it, so these roles must be moved and checked before retirement. | Document which server currently holds each role and confirm the handover in a test environment first. |
| DNS roles on RHEL 8 servers | If RHEL 8 servers run integrated DNS, clients and forwarders that point at them need updates and resolution tests after each change. | List every resolv.conf and forwarder entry that names a RHEL 8 server and plan their replacement together. |
| Custom scripts and integrations referencing server names | Hard-coded hostnames in cron jobs, monitoring, Ansible inventories and application configs break when a server is retired. | Search configuration management and monitoring for old hostnames, then change them ahead of the cutover. |
| Active Directory trusts | Trust configuration and any DNS or ID mapping tied to a retiring server may need review and testing before that server is removed. | Confirm trust health on the target servers and record which server each trust component depends on. |
| Client counts that depend on DNS entries | Large client fleets that resolve servers by a fixed name or depend on specific DNS records need more testing and staged rollout. | Use DNS aliases or service records where possible so clients follow a name rather than a host. |
| Available change window | Mixing IdM versions for long periods creates incompatibility risk, so a narrow window can force faster, tighter sequencing or a longer pause on the work. | Ask your team to confirm the approved window and agree the rollback point before setting the sequence. |
Questions teams ask before moving FreeIPA from RHEL 8 to RHEL 9
Can I upgrade FreeIPA servers from RHEL 8 to RHEL 9 in place?
No. Red Hat's migration guide says an in-place upgrade of RHEL 8 Identity Management servers to RHEL 9 is not supported. The route Red Hat describes is to add a RHEL 9 replica to the existing topology, make that replica the CA renewal server, move CRL generation to it, and then decommission the RHEL 8 servers one at a time. Confirm the current wording in the Red Hat migration guide against your exact RHEL minor versions before you schedule any change, because the steps depend on which roles each server holds.
How long does a RHEL 8 to RHEL 9 FreeIPA move take?
No duration has been published for this move, so treat any figure you hear as something to verify. The elapsed time is driven by the number of IdM servers, how many replicas each datacenter holds, how many clients and services depend on the CA and DNS roles, how much change control your organization requires, and how much testing you do between stages. Red Hat advises migrating all IdM servers quickly because mixing IdM versions for long periods can cause incompatibilities, so the plan should keep the mixed-version window short. Ask any partner for a written schedule tied to your topology inventory.
What does the move need from our internal team?
Your team needs people who can run and read the current topology before anything changes. In practice that means access to every IdM server, the list of roles each server holds (CA, DNS, NTP, trust controller), the replication agreement map, current backups, and the authority to change DNS records and client resolver settings. Someone must own the CA renewal handover, since that role decides which server issues and publishes certificate revocation lists. Security and compliance staff should also agree on how evidence of each stage will be recorded, so the change log matches what auditors will later ask about.
Can our own team do this without a partner?
Yes, if your team already runs FreeIPA replication, backups and certificate operations and has a tested rollback plan. Red Hat's guide gives the sequence, so an experienced team can follow it in a lab first. A partner is most useful where the topology is large, where CA renewal or DNS roles are intertwined with many clients, or where the team has not performed a replica-based server move before. Whichever way you go, rehearse the sequence on a copy of the topology and confirm the steps with Red Hat support for your subscription.
What does a DeployOpen quote for this move depend on?
A DeployOpen quote follows from a written scope, and DeployOpen does not publish a price list. The scope depends on the number of IdM servers and sites, the roles each server holds, whether DNS and the CA are integrated, the number of clients and integrated services to check, the backup and rollback approach, the test environments available, and whether you want documentation and evidence for an internal or external assessment. Ask for the cost components to be split into planning, the migration itself, verification, and any ongoing support, and ask which items are one-time and which recur.
Does FreeIPA 4.13 change the RHEL 8 to RHEL 9 migration?
Yes, it can change what you check. FreeIPA 4.13.0 introduced random certificate serial numbers by default, LDAP system accounts, DNS over TLS between clients and IdM DNS servers, and a beta of a new web UI, according to the FreeIPA 4.13.0 release notes. Newly added replicas may behave differently when they handle certificates, so review the 4.13 upgrade guidance for your topology and test certificate issuance and renewal on the new RHEL 9 CA server before you retire the old one. Confirm which FreeIPA version your RHEL 9 packages ship before you finalize the plan.
What should we check after each server is added or retired?
Check replication health across all servers, confirm the CA renewal role and CRL publication are on the intended server, confirm DNS resolution from a sample of clients, and verify that Kerberos authentication and certificate-based services still work. Also confirm that a current backup exists before each retirement. The FreeIPA backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so recovery plans must be tested, not assumed. Record each check so the sequence can be repeated and audited.
What your team provides and what you receive from DeployOpen
The move goes faster when your team hands over a few things before the first RHEL 9 host is built. The most important is a current topology inventory: every IdM server with its OS version, its replication agreements, the DNS and PKI roles it holds, and which clients and services point at it through DNS records and resolv.conf entries. You also need SSH or console access to every RHEL 8 and RHEL 9 host involved, with sudo rights sufficient to run the IdM installer and read the Dogtag and 389 Directory Server logs. Name a change window for each server that will be moved, and agree how long the topology may run with mixed versions, since Red Hat advises finishing the migration quickly for that reason.
Ownership decisions matter as much as access. Confirm who controls the DNS zones and any forwarders, who owns the certificates issued to services outside IdM, and who will approve the moment the CA renewal and CRL generation roles move to the new RHEL 9 replica. List the integration owners for each system that authenticates against IdM, such as Active Directory trusts, SSH key distribution, file servers and application single sign-on, because each one must be checked after the move. In return, DeployOpen delivers a migration runbook for your topology, written step by step with the commands for each server, a verification record that captures the checks run after each replica joins and after each role moves, and a decommission checklist covering DNS record removal, client and service repointing, and final backup of each retired RHEL 8 server. The exact scope, deliverables and timeline are agreed in writing before work starts.
How DeployOpen works on this
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, so the RHEL 9 replicas, CA renewal move and RHEL 8 retirement run in your cloud accounts, data centers or air-gapped network. Engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory every IdM server, its role, its site and the RHEL 8 version it runs before any change is planned.
- Confirm which servers hold the CA renewal and CRL roles, and document the target RHEL 9 server that will take them over.
- Agree in writing the replica order, maintenance windows, rollback points and the sign-off checks for each stage.
How we build
- Add RHEL 9 replicas to the existing topology, then verify replication and DNS health before any role moves.
- Move the CA renewal and CRL generation roles to a RHEL 9 server and confirm certificate renewal succeeds there.
- Test client authentication, Kerberos ticket issuance and host access rules after each server change, then retire RHEL 8 servers cleanly.
How we hand over
- Deliver a written runbook covering the final server order, role placement, backup state and retirement steps taken.
- Provide a record of verification results for each stage, including replication status and certificate checks.
- Walk your platform and security teams through the new topology so they can operate it without DeployOpen present.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer if your team wants help after the move.
- Review backup coverage on the new servers so an outdated backup is never restored into the active topology.
- Confirm with your team which post-migration checks and monitoring you need, and agree on them in the written scope.
