Open-source alternatives to One Identity Manager: which option fits your situation
If your driver is a renewal date, a licensing change or a lock-in concern, and you want to keep identity governance on infrastructure you control, midPoint is the more complete starting point for full lifecycle governance, while Apache Syncope fits teams that mainly need self-service user management and provisioning with a lighter administrative model. Both are self-hosted, both carry no license fee for the software itself, and both can run inside your own cloud accounts, data centers or air-gapped networks. Which one fits depends on how much of your One Identity Manager estate (attestation, role models, approval workflows, connectors) you need to reproduce on day one. Teams usually review One Identity Manager when the contract renews, when the licensing basis or module bundle changes, when a data residency rule requires identities and audit evidence to stay in a specific jurisdiction, or when rebuilding a custom process would take more effort than the platform's cost justifies. On the open-source side, the supplied licensing facts are straightforward: midPoint is developed by Evolveum, dual-licensed under EUPL and Apache 2.0 with no license fees, and Evolveum sells support, consulting and training separately. Apache Syncope is distributed under the Apache License 2.0. Those facts describe the software license only, not the total cost of running either platform.
No pricing or feature facts for One Identity Manager are part of this assessment, so do not treat any statement about its modules, licensing metric or renewal terms as settled until you have checked them. Pull your current order form, the module list and the support terms, then record which modules you actually use, such as attestation, access request workflows, password management or connectors to specific target systems. Those records become the baseline for the comparison. Ask your vendor representative in writing to confirm what is included in your renewal and what changes if you reduce scope. Then compare that baseline against what midPoint or Syncope covers through the ConnId connector framework and the platform documentation, and flag every gap for a decision rather than assuming it will close.
Which open-source platform to shortlist for One Identity Manager replacement
Two self-hosted platforms are realistic candidates for replacing One Identity Manager's lifecycle, attestation and provisioning workflows. Both are Apache-licensed or dual-licensed open source, so the decision rests on your connector coverage, workflow model and internal skills rather than on license fees.
midPoint by Evolveum
midPoint is the closer functional match for governance-heavy estates, because it covers provisioning and deprovisioning, identity lifecycle, role-based access control, auditing, self-service access requests and role mining in one product. Evolveum has developed it since 2011 and licenses it under EUPL and Apache 2.0 with no license fees, so your recurring costs shift to infrastructure, support subscriptions if you buy them, and internal or partner effort. Check that the role model you plan to build can be expressed in midPoint's object model before you commit.
Apache Syncope for custom workflows
Apache Syncope fits teams that want to build their own identity logic on an Apache Software Foundation project under the Apache License 2.0. It manages digital identities in enterprise environments and is a good candidate when your team prefers to design workflows and provisioning rules directly. Version 4.1.3 was released on September 11, 2026. Expect more engineering work on attestation-style reviews and approval flows than you would configure out of the box in a governance-first product, so confirm which of those features you need and how much of them you will build.
Mapping One Identity Manager capabilities to midPoint and Syncope
This table maps the identity governance capabilities most often used from One Identity Manager to the open-source option that covers them, based on the features each project documents. Read the coverage notes as the checklist for your own review, since the depth of attestation and certification features needs confirmation against the One Identity Manager modules you actually license and use. The main takeaway is that midPoint documents the broadest coverage of the lifecycle and role functions, while attestation depth is the area to verify first.
| Capability | Open-source option | Coverage note |
|---|---|---|
| Provisioning and deprovisioning | midPoint, Apache Syncope | Both cover account provisioning to target systems. Confirm the connectors you need exist in ConnId or Syncope's connector set. |
| Joiner-mover-leaver lifecycle | midPoint | midPoint documents identity lifecycle management. Map your existing HR-driven joiner, mover and leaver rules to it and test each transition. |
| Attestation and certification campaigns | midPoint (confirm depth), Apache Syncope (confirm depth) | Confirm campaign scope, reviewer assignment and evidence export against your One Identity Manager attestation policies before committing. |
| Entitlement and role management | midPoint | midPoint documents role-based access control. Compare your current role model and entitlement hierarchy to its role design before migration. |
| Role mining | midPoint | midPoint documents role mining. Use it to analyze existing access data, then validate the proposed roles with business owners. |
| Self-service requests and password reset | midPoint | midPoint documents self-service access requests and password reset. Confirm the approval flows and reset policies match your current configuration. |
| Auditing | midPoint, Apache Syncope | Confirm which audit events are retained, where they are stored and how long, since your compliance evidence depends on them. |
| Simulation before changes | midPoint | midPoint documents simulations against production data. Use them during cutover to preview changes before they reach target systems. |
How ConnId connectors replace your One Identity target system integrations
Every One Identity target system integration needs an explicit connector decision in midPoint before any data moves. midPoint reaches source and target systems through the ConnId connector framework, where each connector is Java code behind a uniform interface that speaks the target system's protocol. Your existing One Identity Manager connectors do not carry over, so the team should inventory each connected system and record how it is used today: which accounts are created, which groups and entitlements are assigned, how reconciliation runs, and how failed writes are retried or escalated. That inventory becomes the acceptance checklist for each connector.
For each target, decide whether an existing ConnId connector covers the protocol and object types you need, or whether a custom connector must be written and maintained. Check the connector's supported object classes, how it handles account enable and disable, group membership changes, and entitlement attributes, and whether it supports live synchronization or only periodic reconciliation. Confirm these points against the connector documentation in the ConnId documentation and test them with non-production accounts. A custom connector adds recurring work for code review, upgrades and security patching, so the cost of ownership should be weighed against the number of systems that need it.
Apache Syncope uses its own connector model, so if it is the chosen platform, the same checklist applies: confirm accounts, groups, entitlements, reconciliation behavior and error handling against each target before cutover. Do not assume that a connector working in one platform behaves identically in the other. Run both integrations in parallel against test or shadow accounts and compare what each one writes. Differences in reconciliation results or error recovery are the most common source of access drift during cutover, so record them as defects with an owner and a retest date.
What you give up when you leave One Identity Manager and the usual workarounds
Leaving One Identity Manager means losing vendor-packaged modules, connectors, evidence formats and support channels, not just a license. Each card below names one gap, the workaround teams usually adopt, and what to confirm before committing to a cutover date.
Vendor-specific modules and features
Some One Identity Manager capabilities that your team relies on may not map one to one onto midPoint or Apache Syncope. Inventory every module, custom workflow and approval rule in use today, then mark each as covered natively, covered through configuration, or needing custom development. The usual workaround is a custom build in midPoint's object model or Syncope's workflow engine, which adds build and test effort to the project. Confirm feature parity against the current release notes before you plan the scope.
Connector coverage for niche targets
midPoint reaches target systems through ConnId, where each connector is Java code that speaks the target's protocol. Mainstream directories, databases and cloud platforms are usually covered, but legacy mainframe applications and specialized line-of-business systems may have no maintained connector. The workaround is writing a custom ConnId connector, which means someone owns that code for its whole life. Ask for a list of your targets and check each one against the connector catalog before you agree on scope.
Attestation evidence auditors accept
Auditors often expect certification campaigns and access reviews in a format and cadence they already know from your current tool. midPoint and Syncope provide certification and audit capabilities, but the exported evidence may differ in structure, fields and retention. The usual workaround is an evidence mapping document that links each control to the new report, reviewed with your internal audit team and external assessor before cutover. Confirm early which artifacts your assessor will sample.
Vendor support and escalation paths
One Identity contracts give you a single escalation path with defined response obligations. Open-source platforms shift that responsibility to you or to a third party. Evolveum sells support subscriptions, consulting and training for midPoint, and Apache Syncope is supported through its community. The usual workaround is a commercial support subscription or a retained partner with written response terms. Ask any provider what severity levels, hours and response targets are included, and whether they cover the long-term support release you choose.
Internal skills in Java and identity modeling
midPoint customization and ConnId connector work involve Java and a specific identity object model, and Syncope has its own configuration model. Your administrators may know One Identity Manager's Manager console and policy concepts but not these internals. The usual workaround is training plus a partner-led handover, with runbooks written during the build. Assess your team's current skills honestly and decide whether you will hire, train or contract for ongoing change work.
Staffing a parallel run
Running One Identity Manager and the replacement side by side means two systems receive and review changes, which doubles operational load during cutover. Staff from identity operations, application owners and auditors all have to work in both tools for the overlap period. The usual workaround is a defined reconciliation process, a named owner for discrepancies and a fixed end date for the parallel phase. Agree the overlap length, reconciliation frequency and staffing levels in writing with your partner before the project starts.
How a One Identity Manager to midPoint migration runs, step by step
This sequence moves identity lifecycle, attestation and entitlement workflows from One Identity Manager to midPoint without a single unverified cutover, keeping both systems in agreement until the old one can be retired with its evidence preserved.
Inventory workflows, attestations, entitlements and target systems
Your team lists every One Identity Manager job, approval workflow, attestation policy, entitlement and target system connection, plus the audit reports auditors rely on. DeployOpen maps each item to its midPoint equivalent or flags it as a gap, such as a custom process that needs redesign. You provide the configuration exports, the list of connected systems and the report definitions. The step is complete when every item has a named owner and a mapping status that your compliance lead has reviewed.
Export and cleanse identity and assignment data
Identity records and role assignments are exported from One Identity Manager and checked for duplicates, orphaned accounts, stale leavers and inconsistent attribute values. Cleansing rules are agreed with your HR and application owners before any data is loaded. You supply the authoritative HR source, the owners who approve cleansing decisions and access to the source database under your change control. The step closes when the cleansed extract reconciles with the source counts and the exceptions list is signed off.
Map roles and policies to midPoint
Existing roles, business rules and separation-of-duties policies are translated into midPoint roles, assignment rules and policies. Each mapped role is checked against the entitlements it grants today, so no access is added or removed by accident. Your role owners confirm the intended meaning of each role. The output is a role mapping document with a reviewed difference report showing every entitlement that changed, and the reasons for each change.
Pilot on one application or target
One application or target system is connected through a ConnId connector in midPoint and run end to end: joiners, movers, leavers, access requests and attestation. Results are compared against One Identity Manager for the same population. Confirm early whether a connector for your target already exists or needs to be built, since that work usually sets the pace of the rest of the project. The pilot is complete when provisioning results match the baseline and the pilot owner accepts the attestation output.
Run both systems in parallel with reconciliation
Both platforms run side by side while midPoint is reconciled against One Identity Manager and the live target systems. Discrepancies are logged, classified as defects, mapping decisions or source data issues, and resolved before any production account is switched. Your security and operations teams review the reconciliation reports on an agreed cadence. The step ends when the discrepancy backlog is empty for the agreed scope and the reconciliation evidence is stored for the auditors.
Cut over in waves with rollback criteria
Applications move to midPoint in groups, each with written rollback criteria covering failed provisioning, missed attestations and audit gaps. Before each wave, the rollback path back to One Identity Manager is tested. You approve each wave and its criteria in writing. A wave is closed only when its owners confirm access is correct and no rollback criterion has been met during the agreed observation window.
Decommission One Identity Manager and retain evidence
Once all waves are closed, One Identity Manager is switched to read-only, its jobs are stopped and its data is archived under your retention policy. The archive includes historical attestations, approvals and provisioning logs that auditors may request. Confirm with your compliance team which retention periods apply, and confirm with One Identity the terms that govern your license exit. The step is complete when the archive is verified, access to it is restricted, and the decommissioning record is approved by your CISO or delegate.
Choosing midPoint or Syncope by situation
When data residency or sovereignty is the trigger, the first question is where the identity store, audit logs and connector hosts must run. Both midPoint and Apache Syncope are self-hosted, so either can run in your own cloud account, data center or air-gapped network. The choice then depends on the operating model your team can support and on how many identities and target systems sit inside the boundary.
- Hosting boundary: Confirm which systems must stay inside the boundary, including connectors, logs and backups.
- Air-gapped operation: Confirm how software packages, connector updates and patches will reach an isolated network.
- Operating skills: midPoint is Java-based with its own object model, while Syncope uses a Java and Spring stack with its own console and REST API. Match the choice to the team that will run it.
- Connector source: midPoint connectors are built on the ConnId framework, so confirm that each target system you must reach already has a connector or can be built.
- Vendor access: Ask whether support or upgrades require remote access, and whether that access is acceptable under your residency rules.
Confirm the hosting boundary and the air-gap update path before comparing platforms.
When the main pressure is a license renewal or a pricing change, the open-source option removes the license line but not the total cost. Both midPoint and Apache Syncope are available under open-source licenses with no license fee. The recurring cost moves to people, infrastructure, support and upgrades. midPoint is also offered with paid support subscriptions from its developer, which is one option for organizations that want a contracted support line.
- License removed: midPoint is dual-licensed under EUPL and Apache 2.0 with no license fees. Apache Syncope is distributed under the Apache License 2.0.
- Support as an option: Evolveum sells support subscriptions, consulting and training for midPoint. Apache Syncope has no single vendor, so support comes from consultants or a retained partner.
- Internal effort: Staff time for operations, connector maintenance and release upgrades is usually the largest recurring item. Ask what each option would require in your environment.
- Infrastructure: Confirm the hosting, database and backup costs that the current platform bundles.
- Quote scope: Ask any implementation partner for a written scope covering the connectors, workflows and handover, not a flat figure.
Build a side-by-side total cost of ownership with the current license, then add the internal and support lines for each option before deciding.
When the environment depends on custom connectors, approval paths or attribute logic, the platform's extension model matters more than its feature list. midPoint exposes its behavior through XML object definitions, mappings and workflows backed by Java extension points, and connectors are Java code behind the ConnId interface. Apache Syncope also extends through Java, with custom workflows, mappings and resources. Customization is where most of the migration effort lands.
- Connector development: A ConnId connector is Java code that speaks the target system's protocol. Confirm which target systems have existing connectors and which need new work.
- Workflow extension: Map each One Identity approval and lifecycle workflow to a platform object, then decide which can be configured and which need Java.
- Object model fit: midPoint's role and policy model and Syncope's user, group and role model differ, so test a sample of your access structure in each before committing.
- Upgrade cost of custom code: Every custom connector or extension must be retested at each platform release. Ask how the option handles versioned upgrades.
- Ownership: Name who will maintain the Java code after handover.
Inventory your custom connectors and workflows first, because that list will decide which platform needs less rework.
In regulated environments, the questions shift from features to evidence: can you show, across the cutover, who had access, who approved it, and when it changed. Both platforms can produce audit records, but the evidence must be complete, retained and reviewable by an independent auditor. DeployOpen prepares systems, controls and evidence for assessments, while auditors and certification bodies issue any opinion or certification.
- Audit trail continuity: Confirm that audit records from One Identity can be kept or archived in a form the auditor accepts while the new platform starts generating its own records.
- Access review evidence: Map each certification or attestation control to the platform function that produces its evidence, and test that output with the auditor early.
- Segregation of duties: Confirm how role and policy rules will be enforced and documented on the new platform.
- Retention and backup: Set retention periods from your policy and confirm the backup and restore procedure covers both platforms during parallel running.
- Standards mapping: Refer to the control IDs and titles in your framework, such as ISO/IEC 27001 Annex A access control entries, and confirm the mapping with your assessor.
Agree the evidence plan with your auditor before the first parallel run, because continuity gaps are hardest to close after cutover.
How much effort, time and skill a One Identity Manager replacement needs
What drives the effort and cost of replacing One Identity Manager?
The biggest drivers are the number of target systems that need connectors, how many business processes (joiner, mover, leaver, attestation, access requests) must be rebuilt, how much custom logic lives in the current One Identity Manager configuration, and the quality of the data in source systems. Effort rises quickly when attestation rules, approval chains and role definitions were grown over many years without documentation. Costs fall into one-time items such as analysis, design, connector work, testing and cutover, and recurring items such as internal staff time, support subscriptions and upgrades. midPoint itself carries no license fees, and Evolveum sells support subscriptions, consulting and training separately, so ask any provider to split the quote by component.
Can our internal team replace One Identity Manager without outside help?
A capable internal team can do it, but only if it has people who know identity governance design, the target systems, and the open-source platform's configuration model. Most teams underestimate the connector work and the business process mapping. Outside help is often used for the design phase, for building the first connectors, or for a parallel run review, while the internal team keeps ownership of day-to-day operations. Be honest about skills in advance: a team that has operated only the old product will need time to learn midPoint or Apache Syncope before it can make design decisions alone.
What does the replacement need from identity owners and application owners?
The project needs identity owners to confirm which roles, entitlements and approval rules are still correct, and application owners to confirm how each target system grants access, who can request it, and what must be revoked when someone leaves. Their time is usually the bottleneck, not the software. Plan for workshops where existing One Identity Manager rules are reviewed line by line, and make sure each owner signs off on the new model before cutover. Without named owners who can decide, the project tends to copy old rules that nobody understands.
What technical lead role does a midPoint or Syncope project require?
A named technical lead should own architecture, integration with HR and directory sources, connector strategy, environment promotion and the acceptance criteria for cutover. This person needs working knowledge of identity data models, directory services, and the target systems being connected, and should be able to review Java-based connector code or configuration when a connector does not behave as expected. The lead also coordinates security reviews, change control and evidence for auditors. Without one accountable person, decisions about roles, connectors and data quality tend to be split across teams and delayed.
How do midPoint and Apache Syncope release support windows affect planning?
Release support windows set how long you can run a version without a forced upgrade, so they belong in the project plan from day one. midPoint 4.8 (Curie) is a long-term support release supported until October 17, 2028, and midPoint 4.10 (Braille) is the latest feature release, supported until November 26, 2027, according to the midPoint release documentation. Apache Syncope 4.1.3 was released on September 11, 2026, according to the Apache Syncope downloads page. Choose a version whose support window covers the expected go-live and the first upgrade cycle, and ask your provider how upgrades, testing and connector revalidation will be scheduled and priced.
Is a parallel run with One Identity Manager required during cutover?
A parallel run is not strictly required, but it is the safest way to prove the new platform produces the same access decisions as the old one. During parallel operation, both systems compute entitlements from the same HR and directory data, and differences are reviewed before the old system is switched off. This adds cost, because two platforms run at once, licenses for the existing product continue until its contract ends, and staff must review reports. Confirm with your auditors and business owners what evidence they expect, and agree the length and exit criteria of the parallel run in writing.
What should we ask for in a written scope before starting?
Ask for a written scope that names the target systems and connectors in scope, the business processes to be rebuilt (lifecycle, attestation, access requests, password reset, role model), the data sources and their owners, and the acceptance criteria for each phase. Request separate line items for analysis, design, connector development, testing, parallel run support, cutover, documentation, training and post-go-live support, so you can compare providers and see which costs recur. Ask who owns the outputs, how changes after sign-off are handled, and what evidence will be delivered to compliance teams. DeployOpen works from a written scope agreed before work starts and does not publish a price list, so a quote follows from that scope.
How DeployOpen scopes, migrates, hands over and supports the replacement
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source identity platforms inside your own infrastructure. For a One Identity Manager replacement, the work is agreed in a written, fixed scope before any build starts, then delivered and handed over in your environment.
How we scope
- Inventory of One Identity Manager lifecycle, attestation and entitlement workflows, mapped to midPoint or Apache Syncope objects.
- Written list of target system connectors to rebuild, with ConnId coverage confirmed for each system before work starts.
- Agreed decision on parallel running duration, cutover criteria and rollback conditions, recorded in the fixed-scope document.
How we build
- Configure role models, provisioning policies and approval flows in midPoint or Apache Syncope against your own data.
- Build and test connectors for each target system, then run simulations against production-like identity data before cutover.
- Run One Identity Manager and the replacement in parallel, reconciling entitlements and audit trails between the two systems.
How we hand over
- Deliver configuration, connector code, runbooks and test results as documentation your team keeps and can audit.
- Walk your operations and security staff through daily administration, access request handling and attestation campaigns.
- Prepare control evidence and records for your compliance assessment, without issuing audit reports or certifications ourselves.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover, scoped in writing.
- Plan upgrades between midPoint release lines, such as the LTS line and feature releases, against your change windows.
- Confirm with Evolveum or Apache Syncope which versions and support terms apply to your chosen release before committing.
