How a FreeIPA to FreeIPA migration with ipa-migrate works
If you are consolidating or rebuilding FreeIPA realms, ipa-migrate moves most identity data between two FreeIPA deployments over LDAP, but the work is a planned cutover that still needs manual follow-ups, client re-enrollment and password handling. The tool covers users, groups, certificates, sudo and HBAC rules, hosts, services, DNS, OTP tokens and policies, according to the FreeIPA to FreeIPA migration design. Treat it as a migration project with a rollback plan, not as a copy command.
The effort depends mainly on how many realms, hosts, policies and clients you are moving, and on how many of those policies depend on objects the tool does not carry across. Before you run anything, confirm with the FreeIPA documentation which objects fall outside the tool's scope for your version, and list them. Each of those becomes a manual task with its own owner. Also decide whether the source and target will run the same FreeIPA release, since version differences add test work. Build a test environment from a recent backup of the source so you can rehearse the run and time each step.
Your team can run ipa-migrate itself if it has people who understand Kerberos, replication and DNS on both sides, and if it can test on a copy before the production window. DeployOpen plans and runs these migrations as fixed-scope engagements: the realms, hosts, policies, clients and cutover steps are agreed in writing before work starts, and the quote follows from that written scope. Ask any partner to show the inventory, the manual follow-up list, the client re-enrollment plan and the password reset approach before you sign.
What ipa-migrate moves and what needs manual work
This table compares the FreeIPA objects that ipa-migrate carries between two deployments with the items you must rebuild or verify on the target. Use the first column to find an object, then check the middle column for what the tool covers and the last column for the follow-up you own.
| Object or item | Moves through ipa-migrate | Manual follow-up on the target |
|---|---|---|
| Users and groups | Yes, as documented in the migration design page | Confirm group membership, user private groups and login names after the run |
| Certificates | Yes, as documented in the migration design page | Confirm the CA state and renewal ownership on the target before cutover |
| Sudo and HBAC rules | Yes, as documented in the migration design page | Test access with hbactest and confirm host group scope on each client |
| Hosts and services | Yes, as documented in the migration design page | Confirm host entries match the machines you will actually enroll |
| DNS records | Yes, as documented in the migration design page | Check zones, forwarders and reverse zones against the new realm and domain |
| OTP tokens and policies | Yes, as documented in the migration design page | Re-test MFA paths and password policy settings with a test account |
| Realm name and DNS domain | No, the target keeps its own realm and domain | Plan the target naming in advance, since client configuration depends on it |
| Replica topology and CA state | No, the target builds its own topology | Design replicas, decide which server holds CA renewal and CRL publication |
| Client enrollment | No, clients stay bound to the source until re-enrolled | Re-enroll each client to the target and verify SSSD and Kerberos tickets |
Production versus staging mode: choosing the right ipa-migrate run
The core decision in an ipa-migrate project is which mode each run uses. A staging run rehearses the move so the team can see what arrives on the target and what breaks, while a production run is the one that carries the real cutover. The two runs should not be treated as interchangeable, because each leaves a different footprint on the target realm. Before the first run, read the mode options in the FreeIPA to FreeIPA migration design page and confirm the exact option names against your installed ipa-migrate version, since this section does not assume any particular flag syntax.
Rehearse on a copy of the source data, not on the live source. Take a recent backup of the source realm, restore it into an isolated environment that matches the target's FreeIPA version and DNS layout, and run the staging migration there first. Then compare the target against the source: user and group counts, host entries, service principals, sudo and HBAC rules, OTP tokens and DNS records. Note every object that did not arrive and every object that arrived with a changed attribute. Keep the rehearsal log, because it becomes the checklist for the production run.
Before switching to production mode, confirm three things. First, the target realm is the one you intend to keep, since a production run changes it for real. Second, the manual follow-ups from the rehearsal have an owner and a date, including sudo and HBAC rules, which the migration does not carry over in full. Third, a rollback path exists: a verified backup of the target taken immediately before the run, and a documented decision point for reverting. Restoring an outdated backup into an active replica topology can break replication, so the rollback plan must restore a current, tested state, not the oldest one available.
Documented tools for FreeIPA to FreeIPA moves
Moving users, policies and hosts between two FreeIPA realms uses a small set of documented tools, each covering a different slice of the data. Knowing what each one carries, what it leaves behind and how a backup fits around them determines how much manual work remains at cutover.
ipa-migrate for FreeIPA to FreeIPA
ipa-migrate is the primary documented path between two FreeIPA deployments. It moves users, groups, certificates, sudo and HBAC rules, hosts, services, DNS, OTP tokens and policies over LDAP. Confirm in your own lab which objects arrive intact, because the design page describes the intended scope, not every edge case in your data. Check the production and staging modes before running it against a live target.
ipa migrate-ds for LDAP users and groups
Use ipa migrate-ds only when the source is an LDAP directory rather than another FreeIPA realm, for example users and groups still held in OpenLDAP or Red Hat Directory Server. It excludes Kerberos attributes, which FreeIPA regenerates, so password behavior after the move needs its own plan. Treat it as a separate track in the same project, not as a substitute for ipa-migrate between two IPA deployments.
LDIF export and import for access rules
Sudo and HBAC rules need manual migration through LDIF. Export the rules from the source, map their hosts, host groups and user groups to the target realm, then import and test each rule with hbactest before cutover. The limit is that LDIF carries the objects you export, not the dependencies behind them, so check every referenced group and host exists on the target first.
Backup and restore as a safety net
Take a full ipa-backup of the source and target before any migration step, and keep it off the servers being changed. Restore is not a rollback for a live topology. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so restores belong on isolated rebuilt servers, not on replicas that other servers still depend on.
Replica and certificate authority checks
Before any cutover, confirm which server holds the CA renewal and CRL role. The backup documentation says the first server handles certificate renewal and CRL publication by default. Moving that role, or migrating certificates to a realm whose CA is still active elsewhere, is a design decision to make on paper before any command runs.
Sequence for inventory, rehearsal, parallel run, cutover and decommission
This sequence moves users, hosts and policies from one FreeIPA realm to another in controlled stages, with a check at each step so the old realm is retired only after the new one has proven itself. Each phase produces a written record that the team can roll back to if a check fails.
Inventory realms, hosts, policies and clients
Your team lists every source realm, replica, enrolled client, user and group population, host group, sudo and HBAC rule, certificate, OTP token, DNS zone and service principal that the migration touches. Note which items ipa-migrate carries and which need manual work, such as items the design page does not list as moving. The step is done when the inventory is reviewed against the source servers and signed off by the owners of each area, and the list of manual follow-ups is agreed in the written plan.
Rehearse on a copy in staging mode
Restore a recent backup of the source realm into an isolated environment, then run ipa-migrate in staging mode against that copy. Staging mode is meant for rehearsal, so the team confirms the exact options against the current tool documentation before running it. Compare user counts, group memberships, policies and certificates on both sides. The step closes when the rehearsal produces a reconciled report with no unexplained gaps, and the rehearsal runbook is updated with every issue found.
Run a parallel test with a client group
Choose a small test group of hosts and test accounts, enroll them against the target realm, and run login, Kerberos ticket, sudo and HBAC checks on each. Keep the source realm live for everyone else during this phase. The test group should include the client types you run in production, such as SSSD on different distributions. The step is complete when each test account authenticates successfully on every test host, and failures have been traced to a cause and fixed or documented.
Execute the production ipa-migrate run
Schedule a change window, take fresh backups of both realms, and run ipa-migrate in production mode against the agreed scope. Record the command, options, start and end times, and the output log. Check object counts for users, groups, hosts, services, certificates, OTP tokens and policies against the inventory. The step is done when the counts match the inventory or each difference is explained in the change record, and the target realm passes its health checks.
Complete password and client follow-up
Work through the manual items from the inventory, including sudo and HBAC rules that the tool does not carry and any password resets the migration requires. Confirm which users can sign in with their existing credentials and which need a reset. Re-enroll clients that still point at the old realm, then verify each client resolves the new realm's servers and DNS. The step closes when a checklist of users and hosts shows every item either working or assigned to a named owner with a follow-up date.
Cut over one host group at a time
Move host groups to the new realm in batches, starting with the least critical group, and keep the source realm available for rollback until the batch has run cleanly. Each batch runs the same login, service and access checks used in the parallel test. Record which host groups have moved and which remain. The step is complete when every host group in scope has run in production on the new realm for the agreed observation period, with no open access incidents.
Decommission the old realm
Once every host group has moved, confirm that no client, service or script still authenticates against the source realm. Then stop the old servers in an order that does not break replication for anything still in use, and retain final backups under your retention policy. Remove the old DNS records, service principals and enrollment entries that point to retired servers. The step is done when the old realm has no active clients, the final backup is verified, and the decommission record is filed with the change board.
Password resets and client re-enrollment after the move
Users and hosts need attention after a realm move because the new realm has its own Kerberos keys, and nothing in the move guarantees that a user's existing password works in the same way. Before cutover, the team should test with a migrated account from the source version and settings it actually runs, and confirm whether password hashes and Kerberos keys carry over, or whether users must set a new password on first use. Treat that answer as a fact to verify in your own environment, not an assumption from this page. Record the result for each password policy and authentication method in use, including any OTP tokens that the migration carries across.
Clients enrolled in the old realm still trust the old Kerberos realm and its KDC, so each host needs to be re-enrolled into the new realm and its host keytab and SSSD configuration replaced. Plan this by host group rather than in one pass: group hosts by owner, role and dependency (for example, build agents, shared file servers and interactive workstations), and schedule re-enrollment so that services depending on a host's keytab are switched in a controlled window. Confirm the enrollment steps, SSSD cache handling and any host-based access rules against the target FreeIPA version with a canary host before you start, and keep a rollback path for each group.
User communication should go out before the first password or login change, and it should say what will change, what the user must do, and who to contact if sign-in fails. Give users a dated checklist covering the new login realm, any forced password change, how to re-register OTP tokens if they are not carried over, and which applications need a fresh Kerberos ticket. Keep a support queue for lockouts and failed logins during the window, since failed sign-ins after cutover are often caused by stale client configuration rather than by the account itself.
What drives the cost and duration of a FreeIPA consolidation
This table lists the main factors that change the effort of consolidating FreeIPA realms with ipa-migrate, and who carries each one. Read each row as a question to answer in your own environment before asking for a written scope, since most of these drivers multiply each other. The main takeaway is that rehearsal depth and manual LDIF work usually matter more to the timeline than the raw user count.
| Driver | Why it changes effort | One-time or recurring | How to keep it down |
|---|---|---|---|
| Source and target realm count | Each source realm needs its own mapping, rehearsal and cutover plan, and merged realms add conflict analysis | One-time | Consolidate in waves, and confirm the realm pairs before scoping |
| User and group counts | Larger directories lengthen export, validation and post-migration checks of memberships | One-time | Remove stale accounts and empty groups in the source before the run |
| Sudo and HBAC rules needing LDIF work | ipa-migrate does not carry all policy objects in the same way, so manual review and rebuild can dominate the schedule | One-time | Inventory rules early and retire unused ones before mapping |
| Enrolled clients and host groups | Every enrolled host may need re-enrollment or a changed server target, and host groups drive cutover batches | One-time, with some recurring checks | Group hosts by role and cut over one batch at a time |
| DNS zones and records | Zones, forwarders and reverse zones must be confirmed on the target, and mismatches break client lookups | One-time | Document zones per realm and compare before cutover |
| Certificate scope | Certificates, CA configuration and service certificates may need reissue or trust updates on clients and applications | One-time, with recurring renewal on the target | List service certificates and their consumers before the change window |
| OTP token handling | Tokens and their users must be carried over and tested, and users may need enrollment support if tokens do not behave as expected | One-time, with recurring help desk load | Test token logins on a copy and plan a support path for affected users |
| Password resets and user communication | Users may need new passwords or first-login steps, which increases help desk volume during cutover | One-time | Confirm the password approach with the migration team and prepare user notices |
| Change windows and rollback | Narrow windows, or no tested rollback, raise the number of rehearsals and the risk premium in quotes | One-time | Agree window length, rollback steps and go or no-go criteria in writing |
| Testing depth on a copy | Rehearsals on a copy of production show what breaks, but each extra run adds time and environment cost | One-time | Fix the test matrix in the scope, including staging mode results |
| Target operations and monitoring | The new target needs backups, health checks, patching and replica sizing that the source may not have had | Recurring | Set operational owners and backup tests before the cutover date |
What usually goes wrong in FreeIPA realm consolidation
Consolidating realms with ipa-migrate fails less often on the migration itself than on the operational details around it. The cards below cover the failure points we see most often, and each one names the check to run before cutover.
Outdated backup restored into a live topology
Restoring an old backup into an active replica topology can break replication, so a rollback or test restore can damage the systems that are still serving users. Keep restores on isolated hosts that are not joined to the production replication agreements. Before any restore, confirm which backup type you hold and when it was taken, and document the restore order with the team that owns the replicas.
Overlapping DNS domain with trusted Active Directory
If the target realm uses a DNS domain that overlaps with a domain in a trusted Active Directory forest, the trust and name resolution can fail in ways that look like migration errors. Before choosing the target realm and domain names, list every AD domain in the forest and confirm that the new IPA domain does not overlap with any of them. Treat this as a naming decision made before the migration starts.
Clients still pointing at the old realm
Enrolled Linux hosts keep their existing Kerberos and SSSD configuration, so they continue to authenticate against the source realm after cutover. Build an inventory of enrolled clients, their realm names and their DNS settings, then plan re-enrollment host group by host group. Confirm that a test host can log in to the new realm before you retire the old one.
Forgotten sudo and HBAC rules
Users and groups move through the migration tool, but sudo and HBAC rules need manual work, so they are the most common gap after cutover. Export the rules from the source deployment, map each one to the target, and test access with hbactest before you cut over each host group. Assign an owner to the rule inventory so that no policy is left behind.
Certificate renewal on the wrong first server
The first server in a topology handles certificate renewal and CRL publication by default. If that role lands on a server being retired, or on a server that is not part of the new topology, renewals and CRL updates can stop without an obvious alert. Identify which server holds the role in each realm, move it deliberately as part of the topology plan, and check certificate and CRL status on the new topology before decommissioning the old one.
Unplanned password resets
If migrated users cannot authenticate because password hashes do not carry over in the form the target expects, help desks face a wave of reset requests on cutover day. Confirm with the migration plan which credentials move and which do not, decide in advance whether users reset passwords or use another path, and communicate that decision to users before the window opens.
Questions teams ask before consolidating FreeIPA realms
How much does a FreeIPA to FreeIPA migration cost?
No supplied fact gives a price for this work, so the honest answer is that cost follows the written scope. FreeIPA itself is GPL-3.0-or-later with no paid edition, so the spend is labor and infrastructure: the people who plan the realm mapping, run the migration, test client behavior and document the cutover, plus any new servers, storage and backup capacity for the target realm. Costs rise with the number of users, hosts, host groups, sudo and HBAC rules, certificates and OTP tokens in scope, and with how many environments must be rehearsed before production. Ask any provider for a quote that separates one-time work (planning, rehearsal, cutover, cleanup) from recurring work (support, upgrades, testing), and that lists which items are included and which are excluded.
How long does consolidating two FreeIPA realms take?
Duration depends on scope more than on the tool. The ipa-migrate tool copies users, groups, certificates, sudo and HBAC rules, hosts, services, DNS, OTP tokens and policies over LDAP, but the surrounding work sets the calendar: agreeing the target naming, rehearsing on a copy, handling items that do not move, re-enrolling clients and reviewing results. Realms with many hosts or custom policies need more rehearsal time. Ask for a schedule that breaks out each phase, the number of rehearsal runs assumed, and the change windows required for cutover. No timeline is stated here because none was supplied for this topic.
What does our team need to provide for the migration?
Expect to provide access and decisions, not just credentials. The team needs administrative access to both realms, network paths between the source and target servers for the LDAP-based copy, and a named owner who can approve the realm name, domain layout and DNS plan for the target. You also need an inventory of host groups, sudo rules, HBAC rules, OTP tokens, certificates and DNS zones, along with the list of applications that authenticate against the source realm. Confirm with your provider which environments they will use for rehearsal, how backups of both realms will be taken before any change, and who signs off on cutover.
Can our internal team run ipa-migrate without outside help?
Yes, if you have people who already operate FreeIPA, understand Kerberos and SSSD, and can test on a copy before touching production. The FreeIPA documentation describes ipa-migrate as a tool with a production mode and a staging mode, and the design page lists what it moves. The harder parts are judgment calls: which objects should be carried over, how identifiers and realm names map, which items need manual follow-up, and how clients recover. Be honest about capacity. If the team has no recent FreeIPA operations experience or cannot dedicate rehearsal time, a fixed-scope engagement may reduce the risk of an incomplete cutover.
What happens to user passwords during a FreeIPA to FreeIPA migration?
Plan for password resets unless your rehearsal proves otherwise. The reliable way to decide is to test on a copy, because password material and Kerberos keys depend on the source and target configuration. Users should expect to set or confirm credentials on the new realm, and service accounts and keytabs need their own review. Ask the provider to state, in writing, how Kerberos keys and password hashes are handled, which users will be asked to reset, how users are notified, and what the fallback is for users who cannot authenticate on the first day after cutover.
How are clients re-enrolled after the realms are consolidated?
Clients that trust the source realm must be pointed at the target realm, which usually means uninstalling and re-enrolling them, then confirming SSSD works for logins, sudo and SSH keys. Enrollment and SSSD work is a separate topic with its own install options, but the migration plan must include the sequence: which host groups move first, how DNS records and resolv.conf entries change, how stale host entries are removed from the old realm, and how a failed client is rolled back. Ask for a per-host-group cutover checklist and a test login that proves access before the old realm is turned off.
What should we ask for in a quote for this work?
Ask for a written scope that lists each object type in or out of the migration, the source and target versions, the environments used for rehearsal, and the number of rehearsal runs included. Require a list of manual follow-ups by category, a rollback plan with backup and restore steps (FreeIPA documents ipa-backup and ipa-restore and warns that restoring an outdated backup into an active replica topology can break replication), and a clear acceptance test. Also ask which items are one-time and which recur, what post-cutover support is included, and what changes are needed to any work if the source realm has undocumented customizations.
How DeployOpen scopes and delivers a FreeIPA migration
DeployOpen plans, builds, tests and documents FreeIPA-to-FreeIPA consolidations and rebuilds inside your own infrastructure, including cloud accounts, data centers and air-gapped networks. Engagements are fixed-scope, with the migration boundary, deliverables and timelines agreed in writing before any work starts.
How we scope
- Inventory source and target realms, versions, replicas, DNS zones and certificate authorities before choosing production or staging mode
- Record which users, groups, hosts, sudo rules, HBAC rules, OTP tokens and policies move, and which need manual rebuilding
- Agree in writing who resets passwords, who re-enrolls clients and which cutover window each side owns
How we build
- Run a full rehearsal against a copy of the source realm and record every object that differs afterward
- Work through manual follow-ups such as sudo and HBAC rules, DNS records and service principals in a tracked change list
- Test client re-enrollment and login on representative hosts before the production cutover is approved
How we hand over
- Deliver the migration runbook, rollback steps and the verified object-by-object comparison report
- Document the final realm layout, replica roles and the decommissioning order for the retired deployment
- Walk your operations and security staff through re-enrollment, password reset communications and open items
How we support
- Offer post-cutover support for authentication failures, client issues and replication checks as a retainer
- Keep the rehearsal and cutover scripts under version control so your team can rerun them for later changes
- Agree upgrade and security-release follow-up for the new realm as a separate, written scope if you want ongoing help
