Why a FreeIPA RHEL 7 upgrade must pass through RHEL 8
If your identity management estate runs on RHEL 7 or CentOS 7 and must reach RHEL 9, a direct jump to RHEL 9 is not supported, so the move runs through RHEL 8 replicas. Red Hat's migration guide states that you must first move IdM to RHEL 8 and then to RHEL 9. Plan the work as two stages with a stable checkpoint between them, not as one operating system change.
The reason is the shape of the service. An IdM deployment is not a single server. Its replicas share a live multi-master directory, a Kerberos KDC, a Dogtag certificate authority with one server handling renewal and CRL publication by default, and DNS and NTP roles that clients depend on. Replica-based moves suit that topology because you install a current replica on the new operating system, let it synchronize, test authentication, certificate issuance and DNS resolution against it, and only then retire the old servers one at a time. The FreeIPA migration how-to describes this same pattern. Confirm with Red Hat which RHEL 8 minor release your target RHEL 9 path expects before you install anything.
Start planning before you need the upgrade. Inventory every IdM server, its roles (CA, DNS, NTP) and its replication agreements, and confirm which of them still run RHEL 7 or CentOS 7 under your vendor support terms. Then check how much room your topology has to lose a server during each stage. Ask your platform team and your Red Hat account contact to confirm the support status of your current operating system version and the supported RHEL 8 and RHEL 9 releases, since those dates are set outside this page and change over time.
What changes for IdM servers at each platform hop
This table compares the RHEL 7 to RHEL 8 hop with the RHEL 8 to RHEL 9 hop, showing what changes for IdM servers and what to do at each stage. Read each row as a checkpoint for the replica you add at that stage, and confirm the IdM version each RHEL release ships with Red Hat before you plan the sequence.
| Change | RHEL 7 to RHEL 8 hop | RHEL 8 to RHEL 9 hop |
|---|---|---|
| Direct jump allowed | false | false |
| Supported path | Add RHEL 8 replicas to the existing RHEL 7 topology first | Add RHEL 9 replicas to the RHEL 8 topology, then retire RHEL 8 servers |
| Server role during transition | RHEL 8 replicas join as new servers, not as in-place upgrades of RHEL 7 hosts | RHEL 9 replicas join as new servers, not as in-place upgrades of RHEL 8 hosts |
| CA renewal and CRL role | Confirm which server holds the CA renewal and CRL role before any server is stopped | Move the role to a RHEL 9 replica and verify it before retiring the RHEL 8 holder |
| IdM version on target platform | Confirm with Red Hat which IdM version RHEL 8 ships | Confirm with Red Hat which IdM version RHEL 9 ships, including any 4.13 changes such as random serial numbers |
| Certificate serial numbers | Check existing certificate issuance and serial handling on the RHEL 8 replica | Expect random serial numbers on new issuance if the target IdM version includes the 4.13 default, and confirm with Red Hat |
| Web UI | Document current admin workflows that depend on the legacy UI | Test the modern Web UI beta only if your target version includes it, and confirm its status with Red Hat |
| Replication and DNS checks | Run replication and DNS health checks on each new replica before adding the next | Repeat replication, DNS and client authentication checks on each RHEL 9 replica before stopping any RHEL 8 server |
| Retiring old servers | Stop RHEL 7 servers one at a time, only after the replacement has passed testing | Stop RHEL 8 servers one at a time, keeping at least one working CA holder and DNS server in each site |
What to inventory and back up before the first replica
Before a RHEL 8 replica joins the topology, the existing RHEL 7 servers need to be fully described, backed up and tested. These four to six items cover what to record, what to protect and what to verify, so the first replica is added to a known state.
Full topology inventory
List every IdM server with its OS release, the roles it holds (CA renewal, CRL publication, DNS, NTP), its replication agreements and its site. Record which server is the CA renewal master, since the backup documentation notes the first server handles certificate renewal and CRL publication by default. Map where DNS and the CA run, so you know which replicas must exist in each datacenter before you retire any RHEL 7 server.
Fresh backup, verified off-host
Take a new ipa-backup on a healthy server and copy it to storage outside that host before any change. Confirm the archive is readable and note which backup type you used, full or data-only. Warning: restoring an outdated backup into an active replica topology can break replication, so never roll back to an older archive once the new replica is in service.
Custom sudo and HBAC rules
Export every custom sudo rule and HBAC rule, along with the integrations that depend on them, such as Samba file servers, Ansible automation and external LDAP consumers. Sudo and HBAC rules are not carried over by every migration path, so the export is your record of what must be recreated or verified on the new servers. Check each rule against the host groups it targets.
Test environment mirroring the topology
Build a non-production topology with the same server count, OS mix, replication agreements and DNS placement as production. Run the RHEL 8 replica addition and the planned retirement steps there first. Use it to time each step and to confirm that clients still authenticate and resolve hosts after each change.
Client and resolver review
Check /etc/resolv.conf on enrolled clients and confirm at least two DNS servers are listed, so no client loses name resolution when one server is retired. Identify clients that point only at a RHEL 7 server by hostname or IP. Update those entries before the old server is stopped, not afterward.
Dedicated server check
Confirm each IdM server runs no other applications, as the deployment recommendations advise. Shared hosts complicate the upgrade because a change to a neighboring service can interrupt directory or Kerberos traffic. Note any server that also runs web, mail or application workloads, and plan to move those workloads or add dedicated hardware before the replica step.
Decisions to settle before the RHEL 8 replicas go live
Settle the server roles before you install anything on RHEL 8. The most consequential choice is which RHEL 8 replica takes over certificate renewal and CRL publication, because the FreeIPA backup documentation notes that the first server handles these by default and that an outdated backup restored into an active topology can break replication. Decide that role move explicitly, record it, and confirm with your team that the old first server will not keep it by accident when you stop it. Next, map where DNS and NTP roles land. Identify which current servers run the integrated DNS service and time services, which clients resolve through them, and confirm that every client's resolv.conf still lists at least two DNS servers after the move.
Work out the topology arithmetic early. The deployment recommendations advise at least two to three replicas in each datacenter and no more than four replication agreements per replica, so count the agreements each new RHEL 8 replica would create before you add it. Also decide whether each datacenter keeps at least one replica running PKI or DNS, if you use those services. Confirm the current agreement counts with ipa-replica-manage list on each server rather than relying on the diagram you have. Assign one named owner for the cutover window, with authority to pause between stages, and agree in writing who approves stopping each old server.
The migration how-to sequence gives these decisions their order. You install an up-to-date replica on the target system with ipa-replica-install, test it, and only then stop old servers one by one. Each decision above must be closed before the install step, and each stop must follow a passing test of the replacement. Treat the test as a gate that checks CA renewal ownership, DNS and NTP resolution from a sample of clients, and replication health, because a stop that removes the last server holding a role is hard to reverse. Ask your team to confirm the exact checks against the Red Hat guide before the window is scheduled.
The FreeIPA RHEL 7 to RHEL 9 sequence, with checks and rollback points
This sequence moves an IdM topology from RHEL 7 to RHEL 9 through a RHEL 8 stage, so that every server is added, tested and only then retired while the original servers stay available for rollback. Each stage closes with a check the team can record before it proceeds.
Inventory the topology and confirm the target versions
Before any new server is added, record every IdM server, its role (CA, DNS, CA renewal and CRL master), its replication agreements and its site. Confirm the current FreeIPA package versions on each RHEL 7 server and check the target RHEL 8 and RHEL 9 releases against the current Red Hat migration guide, since the exact commands and supported paths should be verified there rather than taken from this page. The output is a written map of roles and agreements that the rest of the sequence refers to. Rollback point: nothing has changed yet, so the existing topology remains the only production path.
Install an up-to-date RHEL 8 replica
On a new RHEL 8 host, run ipa-replica-install against an existing RHEL 7 server, using the options your topology needs for CA and DNS. Confirm each option against the current Red Hat guide before you run it. Check that replication completes without errors and that the new replica appears in the topology on every server. Rollback point: remove the new RHEL 8 replica from the topology while the RHEL 7 servers continue serving all clients.
Test authentication, DNS, certificates and client logins
Point a test set of clients at the RHEL 8 replica and check Kerberos ticket issuance, LDAP lookups, DNS resolution for the IdM zones, certificate issuance and renewal, and logins over SSH and any other services you rely on. Repeat the same tests against a RHEL 7 server for comparison. Record the results and resolve any differences before going further. Rollback point: the RHEL 7 servers still hold every role, so a failed test only means the RHEL 8 replica is removed or repaired.
Move the CA and DNS roles to the RHEL 8 replica
Once the RHEL 8 replica passes testing, move the certificate authority renewal and CRL publication role and any DNS role to it, one role at a time, following the Red Hat guide's procedure. Confirm after each move that certificate renewal and CRL publication are working on the new server and that DNS answers still resolve for clients. Rollback point: each role can be moved back to its RHEL 7 server until the old server is stopped, so keep the original server running and reachable during this stage.
Stop the RHEL 7 servers one at a time
Retire RHEL 7 servers individually, starting with those holding no remaining roles. Before each stop, confirm that replication is healthy across the remaining topology and that clients still authenticate. Leave the stopped server's data and configuration intact until the rest of the migration is verified. Rollback point: a stopped server can be restarted to rejoin replication while the remaining servers are healthy, which is why the sequence keeps one server out of service at a time.
Repeat the cycle with RHEL 9 replicas
Add RHEL 9 replicas from the RHEL 8 servers using the same pattern: install, test authentication, DNS, certificates and client logins, move roles, then confirm. Do not add RHEL 9 replicas until the RHEL 8 stage is stable. Check that the topology, including the agreement count recommended in the FreeIPA deployment guidance, still matches your design. Rollback point: each RHEL 9 replica can be removed while RHEL 8 servers hold the roles.
Retire the RHEL 8 servers last
After the RHEL 9 servers carry all roles and pass the same tests, stop and decommission RHEL 8 servers one at a time, verifying replication and client logins after each. Keep the retired servers' backups and configuration archived according to your retention policy. Confirm with the Red Hat guide and your backup procedure that a current ipa-backup exists before the final removal. Rollback point: until the last RHEL 8 server is removed, it remains a recovery option, so the decommission is the only step that cannot be reversed in place.
What makes a FreeIPA platform migration take longer
This table lists the factors that raise the effort of moving FreeIPA off RHEL 7 or CentOS 7, with the effect each has and what to check before planning. Read each row as a driver that adds work to the two-stage path through RHEL 8 to RHEL 9, not as a fixed amount of time. The main takeaway is that the inventory of your current topology and backups matters more to the plan than the number of users.
| Driver | Effect on effort | What to check |
|---|---|---|
| Number of servers and replicas per datacenter | Each IdM server needs a new RHEL 8 or RHEL 9 replica installed, tested and retired, so more servers means more install, verification and cutover cycles. | Count every IdM server, its role and its replication agreements, and compare against the deployment recommendations for replicas per datacenter. |
| CA and DNS roles held by specific servers | The server running the CA renewal and CRL role, and servers hosting integrated DNS, must be moved deliberately, which adds coordination and checks. | Confirm which servers renew certificates, publish CRLs and serve DNS, and whether a RHEL 9 replica holds each role before retiring the old server. |
| Custom integrations (Samba, Keycloak federation, Ansible, AD trusts) | Each integration may depend on a specific host, keytab, service principal or configuration file that has to be re-pointed or retested after the move. | List every integration, the host it depends on, and the service accounts or keytabs it uses. Confirm each one works against a RHEL 9 replica. |
| Custom sudo and HBAC rules | Rules created by hand or migrated from another directory need review, because they are not carried over automatically in every migration path. | Export sudo and HBAC rules and compare them with the new replica. Note which rules were migrated manually through LDIF. |
| Volume of clients that must re-verify | Enrolled clients depend on the server they were configured against, and many clients mean more testing of login, SSSD and host access after the cutover. | Count enrolled clients by OS and document which ones need a test login after server changes. Confirm the client upgrade approach for each OS. |
| Number of datacenters and maintenance windows | Each site has its own replica order and change window, and each window adds planning, communication and rollback preparation. | Map sites, replication topology and approved change windows. Confirm whether sites can be changed in sequence or must stay in step. |
| State of existing backups | A current, tested backup lowers the risk of the cutover. Outdated backups, or backups never restored, add preparation and may force a full backup before work begins. | Confirm the date and type of the latest backup, whether it has been test-restored, and that the team knows the backup warning about restoring old data into an active topology. |
Which checks matter for a single site and for multi-datacenter topologies
A single-site topology with two or three servers has fewer moving parts, but each stage still changes the servers that issue tickets, certificates and DNS answers, so the checks should run after every server, not only at the end. Because the replicas share one network segment, a failed check usually points to one host, which makes it easier to isolate before you retire the next RHEL 7 server.
- Authentication and tickets: Test a password login and a Kerberos login from an enrolled client against each server in turn, then confirm
kinitsucceeds for a service principal and a user principal. - Certificate issuance and renewal: Confirm the Dogtag CA answers on the server that holds the CA renewal and CRL roles, and check that the certificate status lists show no stuck requests.
- DNS resolution from clients: Query the IdM DNS records from a client and confirm each server in
resolv.confreturns the same answers. - Replication status: Run the replication checks between all pairs of servers and confirm no agreement reports errors before you stop the next server.
Before you stop a RHEL 7 server, confirm the RHEL 8 or RHEL 9 replica has passed every check above and that you have a current backup taken with ipa-backup.
A multi-datacenter estate has the same checks as a single site, run per site, plus checks for the links between sites. Replication must cross the wide-area path, DNS locations must stay close to the clients they serve, and any Active Directory trust adds a separate authentication path that the move can break. Schedule the stages so each site's replicas are complete before a neighboring site changes.
- Replication across sites: Verify that each site keeps the replica count and agreement limits from the deployment recommendations, and that cross-site agreements are healthy after each server change.
- Trust health: If Active Directory is in use, test a cross-forest login and a Kerberos ticket for an AD user after every stage, since trust material lives on the servers you are replacing.
- External or split DNS: Where DNS is served outside IdM, confirm delegation and forwarding still point to live servers, and check that clients in each site resolve local names first.
- Certificate roles: Check which server currently renews certificates and publishes the CRL, and move that role deliberately so it is never unassigned during a site change.
- Coordination: Agree on a change calendar with the networking, DNS and AD teams, and record which site is in progress.
A trust that works from one site but fails from another usually points to DNS or a server that was not updated, so test every site before you declare a stage complete.
Whatever the topology, the checks only protect you if they are recorded. A written record of each run gives the security and compliance team evidence of the move and gives the operator a baseline if a later stage behaves differently. The record should name the server, the stage, the test command and the result, and it should be kept with the change ticket.
- Baseline before the first stage: Capture authentication, ticket, certificate, DNS and replication results on the RHEL 7 topology so you have something to compare against.
- Per-server entries: Log each check against the server it ran on, not only against the site.
- Failure handling: Write down what was rolled back or paused and who approved the decision.
- Retention: Store the record alongside backup references so a restore can be matched to the state it came from.
- Review: Have a second engineer read the record before the next server is retired.
Ask your implementation partner to show the exact checks and record format they will use before the first stage starts.
How much effort does a FreeIPA RHEL 7 upgrade take, and what does the team need to provide
What drives the cost and effort of a FreeIPA upgrade from RHEL 7?
The main drivers are the number of IdM servers and replicas, how many sites they span, and how many services depend on them. Each server needs an intermediate RHEL 8 replica, then a RHEL 9 replica, then retirement of the old server, so the count of servers multiplies the work. Other drivers include the number of CA and DNS roles, custom integrations such as Samba file servers or Active Directory trusts, the number of enrolled clients that need checking, and how much backup and rollback preparation the environment already has. Ask any partner to show how each driver maps to a line in the written scope.
Can our own team upgrade FreeIPA from RHEL 7 without a partner?
Yes, if the team has staff who can run the replica installs, test authentication and Kerberos, and handle the certificate authority and DNS roles safely. The Red Hat guide and the FreeIPA migration how-to describe the sequence, so an experienced IdM team can follow it. A partner adds value when the topology is large, when no one on staff has run FreeIPA replica moves before, or when the change windows are tight. Either way, the team should read the Red Hat guide in full before the first server is touched.
What does our staff need to provide during the upgrade?
Plan for named owners and a usable environment before work starts:
- Change windows agreed for each server, with a rollback path and a freeze on other IdM changes.
- Administrative access to the IdM servers, the DNS zones, the certificate authority and the clients used for testing.
- A test environment that mirrors the production topology closely enough to rehearse each stage.
- A named owner for the CA and its renewal and CRL roles, and a named owner for DNS, since both move with the server roles.
- A named owner for each integration, such as Samba, trusts or application clients.
- Current backups, taken with ipa-backup, stored where a restore can be tested.
Why can't we jump directly from RHEL 7 to RHEL 9?
Red Hat's migration guide states that migrating IdM directly from RHEL 7 or earlier to RHEL 9 is not supported. You must first move the topology to RHEL 8 and then to RHEL 9. In practice this means adding RHEL 8 replicas to the existing RHEL 7 topology, moving the CA renewal and CRL roles and DNS duties as needed, retiring the RHEL 7 servers, and then repeating the same pattern from RHEL 8 to RHEL 9. Treat the guide as the authority for the supported path and confirm the details against your own versions.
How do we verify each stage before retiring an old server?
Verify each stage before the next one begins. After a new replica is installed, check replication status between all servers, confirm that Kerberos ticket requests succeed for test users, and confirm that clients can resolve hosts and services through the new DNS servers. Confirm that certificate issuance and renewal work on the new CA, and that a CRL is published. Test a restore from a recent backup in the test environment. Only after these checks pass should the old server be stopped, one at a time, following the FreeIPA migration how-to.
What does a written fixed-scope quote for this work cover?
DeployOpen does not publish a price list. A quote follows from the written scope, which is agreed before work starts. Ask the quote to list the servers in scope, each RHEL 8 and RHEL 9 stage, the test environment and rehearsals, the handling of CA and DNS roles, integration checks, backup and restore testing, the handover documentation, and what the client must provide. Confirm which items are one-time work and which would recur under a support retainer. DeployOpen's fixed-scope engagements set deliverables and timelines in writing before work begins.
How DeployOpen scopes, delivers and supports a FreeIPA platform migration
DeployOpen plans and runs FreeIPA on RHEL 7 migrations inside your own infrastructure, from the current topology to a RHEL 9 deployment. Each stage is scoped in writing, built against your environment, and handed over with documentation your team can operate.
How we scope
- Inventory every FreeIPA server, replica, CA role, DNS role and enrolled client before setting the sequence
- Agree in writing which RHEL 8 intermediate replicas are added, which servers retire and what each stage delivers
- Confirm maintenance windows, rollback points and who approves each server cutover with your team
- Engagements are fixed-scope, so scope, deliverables and timelines are agreed before work starts
How we build
- Install the RHEL 8 replica with ipa-replica-install and test it before any old server is stopped
- Run replication, DNS and certificate checks after each server joins, moves or retires
- Move the certificate renewal and CRL publication roles deliberately, and record where they sit at every stage
- Take ipa-backup copies before each change and confirm they restore cleanly in a test environment
How we hand over
- Deliver a stage-by-stage runbook covering commands, expected output and rollback steps for each server
- Document the final topology, replication agreements, DNS locations and CA role assignments in your own records
- Provide the test evidence collected at each checkpoint so your auditors and security team can review it
- Walk your platform and security engineers through the operating procedures before the work closes
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the migration closes
- Review each new FreeIPA package release against your topology before it reaches production replicas
- Keep backup, restore and health-check procedures current as the RHEL 9 estate changes
- Ask any provider to confirm response scope, access arrangements and who holds the runbooks after handover
