Omada vs Apache Syncope: when each option fits
If your main need from Omada is provisioning and self-service, Apache Syncope fits that need well, and the trade-off is governance. Syncope covers identity management, a provisioning engine built on ConnId connectors, an Admin UI with delegated administration, an End-user UI for self-registration, self-service and password reset, and Web Access (WA) for single sign-on over SAML 2.0 and OpenID Connect. What it does not give you out of the box is the governance layer that Omada is typically bought for: periodic access reviews and certifications across many systems, risk scoring, and lifecycle governance that ties HR events to reviews and approvals. Those capabilities are where Omada remains the stronger fit.
Omada fits better when governance is the purpose of the program, not a side effect of provisioning. That includes recurring certification campaigns that business owners complete, risk-based access decisions, segregation of duties checks, and audit evidence produced directly from the platform. Syncope fits better when the core requirement is reliable provisioning and deprovisioning into a defined set of target systems, self-service for employees and partners, and a self-hosted stack under an Apache License 2.0 agreement with no subscription fee for the software itself. If you run Omada today mainly to push accounts into directories and applications, that gap is smaller than it looks.
The decision turns on two questions. First, how much governance does your organization use Omada for today? Pull the last twelve months of certification campaigns, approval workflows and risk reports, and count which ones would have to be rebuilt by hand or by a separate tool. Second, who will run the platform after go-live? Syncope is a Java application with its own Core, Admin UI, End-user UI and WA components, and you will need staff or a partner to operate it, patch it and extend its ConnId connectors. Confirm the supported internal database for your environment against the Apache Syncope getting started guide before you choose a stack.
Which option fits which scenario
This table maps common Omada customer scenarios to the platform most likely to fit, with the supplied capability behind each choice. Read it as a starting point: a scenario that depends on governance depth points toward midPoint, while one centered on connectors and self-service points toward Apache Syncope. Confirm each gap against your own requirements before deciding.
| Scenario | Better fit | Reason |
|---|---|---|
| Provisioning-led identity lifecycle | Apache Syncope | Syncope connects to target systems through ConnId, with Active Directory, SOAP, CSV and PowerShell connectors, and its Core manages identity data across systems. |
| Self-service password reset and access requests | Apache Syncope | The End-user UI supports self-registration, self-service and password reset. Confirm whether approval workflows for requests meet your needs. |
| Access certification campaigns | midPoint | midPoint covers auditing, role-based access control and self-service access requests. Syncope's supplied documentation does not describe certification campaigns, so confirm this gap before choosing it. |
| SoD and risk reporting | midPoint | midPoint provides role mining and simulations against production data, which support role design and impact analysis. Confirm the specific SoD rule and risk reporting features you need. |
| Strict data residency | Either, self-hosted | Both are Apache-2.0 or EUPL-licensed software you run in your own infrastructure. Residency depends on where you host them, not on the platform choice. |
| In-house operations skills | Apache Syncope, if the team is Java-light | Syncope exposes a Jakarta REST interface and admin UIs, while midPoint's connectors and configuration lean on Java and XML-style object design. Assess your team's skills before choosing. |
What Apache Syncope covers for provisioning and self-service
Apache Syncope's identity management engine is Syncope Core, which provides identity management services and a central configuration repository behind a Jakarta RESTful Web Services 3.1 REST interface. For an Omada customer whose main need is provisioning, this is the layer that matters most: it holds users, groups and provisioning logic, and the Admin UI and End-user UI are clients of that API. Before committing, confirm with the Apache Syncope project and your own integration team that the REST interface exposes every object type and operation your provisioning flows depend on, since the API surface is the contract your integrations will be built against. The Admin UI provides delegated administration, so help desk staff, application owners and business administrators can be given bounded rights over parts of the identity store. The End-user UI handles self-registration, self-service and password reset. Map each Omada self-service flow you use today to one of these functions and note any that require custom development. Connectors come from the ConnId framework, with documented examples including SOAP, CSV, PowerShell and Active Directory. Check each target system you need against the connector list for version 4.1.3, because a listed connector type does not guarantee support for your specific system version or authentication method.
Syncope separates identity management, which synchronizes identity data across systems, from access management, which handles authentication and authorization. Syncope Web Access (WA) is the hub for authentication, authorization and single sign-on, supporting SAML 2.0 and OpenID Connect. Secure Remote Access (SRA) is an API gateway with HTTP reverse proxying. Together these components cover access management ground that Omada's identity platform does not own in the same way, but they are separate products to install, secure, patch and operate. Decide early whether WA and SRA replace your existing identity provider or sit beside it, because that decision changes your SSO integration plan and your audit scope. For the internal storage database, Apache Syncope 4.1.3 supports PostgreSQL 18 or later, MariaDB 12 or later, MySQL 9 or later and Oracle Database 23 or later. Neo4j 5.26 or later is functional but not considered stable for production, so do not select it for a production deployment. Confirm the database platform your operations team can back up, monitor and restore before you size the deployment, because storage choice drives backup design, high availability and your database licensing position.
Governance features you would give up with Syncope
Apache Syncope is strongest at provisioning, self-service and SSO hub functions. The cards below cover the governance areas where Syncope does not present a comparable layer in the supplied materials, so the team must build, buy or confirm each one before committing. Some of these gaps narrow once midPoint is considered.
Access certification campaigns
Omada runs recurring access reviews where managers and application owners certify who holds which entitlement, and records each decision. Syncope's supplied materials describe provisioning, delegated administration and self-service, not scheduled certification campaigns with reviewer workflows. If your auditors expect campaign evidence, plan either a custom review workflow on top of Syncope or a move to midPoint, which lists auditing among its core features. Ask the Syncope project whether any review component exists in 4.1.3 or is planned.
Segregation of duties and risk analytics
Omada evaluates access combinations against segregation-of-duties rules and surfaces risk on identities and roles. The Syncope materials do not describe a rule engine for conflicting entitlements or a risk scoring layer. Teams moving to Syncope usually either encode SoD rules in provisioning logic, which must be maintained as systems change, or add a separate analytics component. Confirm with the project how Syncope would represent conflicts across target systems before you rely on it for a control.
Lifecycle approvals across many systems
Omada routes joiner, mover and leaver changes and access requests through approval chains that span many target systems. Syncope provides self-registration and self-service, so approval flows for requests tied to several connectors need to be designed and tested. Map each approval path you use today in Omada, note which ones depend on manager or owner decisions, and check whether Syncope's workflow capabilities cover them in your target version before you estimate the migration.
Audit reporting for reviewers
Omada gives compliance reviewers reports on who has access, why it was granted and who approved it. Syncope's supplied materials do not describe a reviewer-facing reporting layer. In midPoint, auditing and simulations are part of the core platform, which narrows this gap. With Syncope, plan for log export to your SIEM and a reporting database, and confirm with the project which audit events are recorded by default.
Role mining and role design
Omada supports role design from existing access data, which helps reduce role sprawl before you migrate. Syncope's materials describe role-based provisioning, not analysis of existing entitlements to propose new roles. midPoint covers role mining, so teams that need to clean up roles before cutover have a documented option there. For Syncope, expect to run the analysis with a separate script or tool against exported entitlements, and confirm that the export format matches your target systems.
Questions buyers ask before switching from Omada to Syncope
What does it cost to run Apache Syncope compared with an Omada subscription?
Syncope has no license fee, since it is distributed under the Apache License 2.0, so the cost is the work and infrastructure around it. Compare an Omada subscription and its implementation program against four components: the servers and database that host Syncope, the staff or partner time to build and maintain connectors and workflows, testing and upgrades, and support if you want it. Infrastructure cost depends on the database you choose. Syncope 4.1.3 supports PostgreSQL 18 or later, MariaDB 12 or later, MySQL 9 or later and Oracle Database 23 or later for internal storage. Ask any Omada or partner quote to break out one-time implementation from recurring subscription and support, and ask your own team to estimate the recurring operations effort.
How long does a migration from Omada to Syncope take?
The duration depends on how many systems you connect, how many provisioning rules you rewrite, and how much of your current Omada setup is custom logic. Syncope's connectors cover SOAP, CSV, PowerShell and Active Directory through the ConnId framework, so systems outside that list need custom connector work. Plan the work in phases: inventory connected systems and attributes, rebuild the identity model and provisioning flows, run both systems in parallel for a set period, then cut over target systems one at a time. No supplied timeline applies to your environment, so ask any implementer for a fixed-scope plan with written deliverables before work starts.
What does the work need from our team?
Expect to need named people in four roles: an identity architect who owns the data model and rules, administrators who know your target systems and their protocols, a security or compliance owner who signs off on access policy, and a platform engineer who runs the database, the Java services and the SSO and gateway components. Your HR source, directory and application owners must confirm attribute mappings and approval paths. Omada's configured workflows are not automatically portable, so someone on your side must document how each request, approval and deprovisioning step currently works before it can be rebuilt.
Can our own team implement Syncope without a partner?
A team with strong Java, directory and identity administration skills can implement Syncope in-house, because the project is open source and the documentation covers installation, the Admin UI, the End-user UI and ConnId connectors. The harder part is governance design: defining roles, entitlements, approval paths and evidence for auditors. Teams without that experience often bring in an implementation partner for a fixed-scope engagement. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts.
Can Syncope replace Omada's access reviews and certifications?
No, not as a complete replacement. Syncope focuses on identity management and provisioning, with delegated administration and self-service for users. It does not provide the campaign-based access certification, risk scoring and reviewer workflows that Omada offers. If access reviews are a regulatory requirement for you, you would need to build that capability, use a separate tool, or consider midPoint, which covers auditing, role-based access control and role mining. Confirm the review features you rely on with each vendor against your own control list before deciding.
Does Syncope handle single sign-on and authentication for our applications?
Syncope includes Web Access (WA), which handles authentication, authorization and single sign-on and supports SAML 2.0 and OpenID Connect, along with Secure Remote Access (SRA), an API gateway with HTTP reverse proxying. Syncope separates identity management from access management, so review how WA fits your application estate before relying on it as your SSO layer. If you already run a dedicated identity provider, you may keep it and integrate Syncope with it instead.
Should we choose Syncope or midPoint if we need governance features?
Choose Syncope when your main need is provisioning, self-registration, self-service and password reset with an Apache-licensed core. Choose midPoint when you need governance features such as auditing, role mining, simulations against production data and a broader governance model. midPoint is developed by Evolveum with support subscriptions available from Evolveum, and it scales to large deployments. Run a proof of concept against your three most complex target systems before deciding, and confirm each platform's current version and support dates on its release page.
What moving from Omada to Syncope involves
The sequence turns Omada's provisioning and self-service behavior into a Syncope deployment that is tested in parallel and then takes over target system provisioning. It also records which governance functions are dropped or rebuilt, so nothing is lost by surprise.
Inventory Omada identities, roles and connectors
Export or document the identity sources, account types, role and entitlement assignments, target system connectors and provisioning rules currently running in Omada. Your Omada administrators and integration owners should lead this, because Omada's configuration is the baseline you are replacing. Confirm with Omada which export formats and API access your subscription or private deployment provides. The step is done when every connected system and every provisioning rule has a line in a written inventory signed off by the application owners.
Decide which governance functions move or drop
Compare the inventory with what Syncope provides: provisioning, delegated administration, self-registration, self-service and password reset, with SSO through Web Access. Syncope does not provide the access certification, role mining or simulation features that Omada offers, so list each of those as moved, rebuilt in another tool, or dropped with a risk owner. Involve compliance and audit leads here, since they decide what evidence they still need. The step is done when every governance function has a documented decision and an owner.
Deploy Syncope and select a supported database
Deploy Syncope Core, the Admin UI, the End-user UI and, if you use it for SSO, Web Access in a test environment inside your own infrastructure. Choose internal storage from the supported list in the Syncope 4.1 getting started guide: PostgreSQL 18 or later, MariaDB 12 or later, MySQL 9 or later, or Oracle Database 23 or later. Neo4j is functional but not considered stable for production, so do not select it for production. Your platform team and DBA own this work. The step is done when the environment starts, the admin console logs in through the chosen authentication path, and backups of the database are tested.
Rebuild ConnId connectors and HR feeds
Recreate each target system connection using ConnId connectors that Syncope supports, such as Active Directory, LDAP, CSV, SOAP and PowerShell, and build the authoritative HR or source feed that Omada currently consumes. Where no suitable connector exists, scope custom connector development as a separate item, because Syncope connectors are Java code behind a uniform interface. Confirm each connector's version and behavior with the connector documentation before you rely on it. The step is done when each connector can read and write in a test target and the HR feed produces the expected identity records.
Port self-service and password reset flows
Rebuild the self-registration, profile update, access request and password reset journeys in the End-user UI, and map each approval step that Omada previously handled to a Syncope workflow or to a process in another tool. Test each flow with a pilot group, including the help desk path for users who cannot reset their own passwords. Confirm with Omada how its request and approval behavior is set up, because the mapping depends on that. The step is done when pilot users complete every flow and the help desk confirms its procedure.
Run Syncope in parallel with Omada
Keep Omada as the system of record while Syncope processes a copy of the same source data and reports what it would provision to each target. Compare the two sets of accounts and entitlements for each connected system, and resolve every difference before any change goes live. Record the reconciliation results and retain them for audit. The step is done when the differences are either zero or explained and approved by the owners of each target system.
Cut over provisioning to target systems
Switch provisioning for one target system at a time from Omada to Syncope, starting with the lowest-risk system, and keep a documented rollback path for each cutover. Disable the corresponding Omada connector only after Syncope has run successfully against that system for an agreed period. Confirm the rollback steps with each system owner before the switch. The step is done when every target system is provisioned from Syncope, Omada has no remaining write access, and the decommissioning evidence is filed.
When midPoint closes the gap better than Syncope
If the Omada requirement goes beyond provisioning and self-service, midPoint is the closer open-source option. It covers provisioning and deprovisioning, identity lifecycle, role-based access control, auditing, self-service access requests and password reset, simulations against production data, and role mining. It also connects to target systems through the same ConnId connector framework that Syncope uses, so connector experience and some connector code may carry over. Syncope's Admin UI and End-user UI cover delegated administration and self-service, but the governance functions listed above are the areas where midPoint is the stronger fit. Before deciding, list which of these Omada features your organization actually uses today, such as certification campaigns or risk scoring, and check each one against both projects' documentation.
Two points are easy to miss. First, midPoint is an identity management system, not an SSO server. Evolveum states that it does not implement the server side of OAuth2, OpenID Connect or SAML, so the authentication hub still needs a separate component. Syncope has its own Web Access hub for SAML 2.0 and OpenID Connect, so this difference matters if you plan to move SSO along with provisioning. Second, the decision should not rest on this page alone. The sibling pages Omada vs midPoint and Migrate from Omada to midPoint walk through lifecycle, access reviews, connectors and cutover in more detail. Use them to confirm which differences apply to your estate, and ask Evolveum or a qualified implementation partner to validate your specific governance workflows before you commit.
How DeployOpen helps you evaluate and move
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so an Omada vs Apache Syncope evaluation can be tested against your real provisioning and self-service requirements before any decision. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
How we scope
- Inventory the target systems, HR sources and self-service flows that provisioning must cover today
- Agree in writing which Omada features are in scope, including any governance features you choose to retire
- Define the test set of joiner, mover and leaver cases used to compare Syncope and midPoint fairly
- Confirm which access reviews, certifications and audit reports must still be produced after the move
How we build
- Stand up a Syncope proof of concept in your own cloud account, data center or air-gapped network
- Build ConnId connectors for Active Directory, SOAP, CSV or PowerShell targets that your environment requires
- Configure the Admin UI delegation model and End-user UI self-registration and password reset flows
- Test single sign-on through Syncope Web Access against your existing identity provider and applications
How we hand over
- Document the configuration repository, connector settings, database choice and backup procedure
- Deliver a gap register that lists each Omada governance feature with its Syncope or midPoint status
- Prepare runbooks for operations, upgrades and connector changes so your team can run the platform
- Provide control evidence and configuration records for your internal and external assessors to review
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Track Syncope release changes and plan upgrades against your own change control process
- Retest provisioning flows after connector, database or directory changes in your environment
- Ask for a written quote that follows from the agreed scope before any work begins
