Oracle Identity Governance vs Apache Syncope: which fits your identity manager
If you run Oracle Identity Manager or OIG and want a lighter, self-hosted identity manager, Apache Syncope fits a narrower scope of provisioning, workflow and self-service under the Apache License 2.0, while OIG-style certification and segregation of duties (SoD) requirements usually point toward midPoint. Syncope is a credible option when your core need is synchronizing identities across systems, handling user self-registration and password reset, and running delegated administration. It is a weaker fit when auditors expect formal access certification campaigns and SoD rules applied across roles and entitlements, because those controls are central to midPoint's governance model and are not a focus of Syncope's documentation.
The decision turns on three things. First, the certification and SoD controls your auditor expects: write down each control, its evidence and the reviewer who signs off, then check whether Syncope or midPoint produces that evidence without custom code. Second, the number of connected systems and their types, since each one needs a ConnId connector and its own reconciliation rules. Third, the skills you have in-house. Both platforms are Java applications, but midPoint's documented stack centers on PostgreSQL and a specific Java release per version, while Syncope supports several databases, including Oracle Database 23 or later. Confirm current Java and database requirements for the exact release you plan to deploy before you size the team.
Run a short proof of concept against two or three of your real target systems, with your highest-risk approval flow included. Ask each vendor or community for the reconciliation and certification behavior you need, and check the Syncope release you select against the Apache Syncope downloads page and the midPoint release notes. The platform that handles your certification and SoD cases with the least custom work is usually the one to take forward.
Which option fits which scenario
This table maps common Oracle Identity Governance requirements to whether Apache Syncope or midPoint is the better starting point. Read each row against your own OIG configuration, since the fit depends on which OIG features your organization actually uses.
| Scenario | Better fit | Why |
|---|---|---|
| Small to mid-size estate with mostly directory and database targets and self-service password reset | Apache Syncope | Syncope's ConnId connectors cover Active Directory, LDAP-style directories and database targets, and its End-user UI handles self-registration, self-service and password reset. Confirm that your OIG targets and reset flows fit these connectors and screens. |
| Estate needing formal access certification campaigns and segregation of duties policies | midPoint | Certification campaigns and segregation of duties are areas where midPoint's governance features need evaluation against your OIG use. Confirm the exact certification and SoD rules you run today before choosing, and test them in a pilot. |
| Team wanting a lighter Apache-licensed stack | Apache Syncope | Syncope is distributed under the Apache License 2.0 and is an Apache Software Foundation project. midPoint is dual-licensed under EUPL-1.2 and Apache 2.0, so confirm which license terms your legal team accepts. |
| Team with an existing Java and Apache skill base | Either, depending on the target model | Both are Java platforms, so existing Java skills transfer. Syncope suits teams comfortable with Jakarta REST and its Admin UI, while midPoint suits teams comfortable with its XML-based object model and PostgreSQL repository. Confirm this against the skills you actually have. |
| Regulated audit that asks for documented review evidence | midPoint, after a feature check | Auditors expect documented reviews, approvals and reports tied to identity decisions. Confirm which review, audit and reporting outputs your auditor expects from OIG, then verify that the chosen platform produces the same evidence. DeployOpen prepares evidence but does not issue audit reports. |
How Apache Syncope covers provisioning, ConnId connectors and self-service
Apache Syncope puts provisioning, delegated administration and self-service in one Java platform, and its core is reached through a Jakarta RESTful Web Services 3.1 interface backed by a central configuration repository. Syncope Core provides the identity management services, so the same REST API that automates provisioning also serves the Admin UI and End-user UI. For an Oracle Identity Manager team, the practical question is which of your current OIM processes map to Syncope's built-in objects (users, groups, resources, mappings and tasks) and which need custom code. Walk through your OIM resources, forms and scheduled tasks one by one against the Syncope documentation before you assume parity.
The Admin UI provides delegated administration, so help desk and application owners can act within scopes you define, while the End-user UI handles self-registration, self-service and password reset. Connectivity to external systems runs through the ConnId connector framework, and the documented examples include SOAP, CSV, PowerShell and Active Directory. Confirm that each of your target systems has a ConnId connector that is maintained for your version, because a missing connector means custom development on your side. Workflow customization is also a point to check: Syncope supports changes to its processes, but you should test those changes against your own approval chain, including who approves, in what order and with what evidence retained.
Syncope also separates identity management, which synchronizes identity data across systems, from access management, which handles authentication and authorization. Web Access (WA) is the component for authentication, authorization and single sign-on, supporting SAML 2.0 and OpenID Connect, and Secure Remote Access (SRA) acts as an API gateway with HTTP reverse proxying. If your OIM deployment only provisions accounts, Syncope's split may fit well with an existing identity provider. If you rely on OIM for access request approvals that feed sign-on decisions, plan how Web Access and your approval logic will work together and verify it in a test environment.
Where OIG certification and segregation of duties would need midPoint
Certification, segregation of duties and role design are the governance controls most often tied to an OIG renewal. Each card below names one control area, what to confirm in Apache Syncope's documentation and tests, and where midPoint's supplied capabilities are the closer match.
Access certification campaigns
Certification campaigns ask reviewers to confirm that each user still needs the access they hold, and they produce evidence for auditors. Confirm whether Syncope provides campaign scheduling, reviewer assignment, decision recording and revocation without custom code, and whether those decisions can be exported as evidence. Ask for a worked example against your own directory. If the campaign engine is missing or thin, plan for midPoint, which covers auditing and role-based access control as part of the core platform.
Segregation of duties policy
Segregation of duties (SoD) rules block combinations of entitlements, such as a user who can both create and approve a payment. Check whether Syncope can express conflict rules across roles and resources, and whether it blocks or flags a conflicting request before it is granted. Test one conflict pair end to end. midPoint's role-based access control model is designed around roles and assignments, so it is the closer match if your SoD rules are role-based and must be enforced at assignment time.
Role-based access control design
Role design decides how many roles you maintain and how easily a change to one role propagates to every user who holds it. Confirm how Syncope models roles, how entitlements are mapped to target systems, and how role changes are applied to existing identities. Run a test where one role is modified and inspect the resulting account changes. midPoint's role-based access control is a core part of its governance model, which makes it the closer match for complex role hierarchies.
Role mining
Role mining analyzes existing entitlements to suggest candidate roles, which is useful when an OIG deployment grew without a role model. Syncope's documentation should be checked for any equivalent analysis tooling. If it is absent, you will need to export entitlement data and run the analysis elsewhere. midPoint lists role mining among its supplied capabilities, so it is the closer match when role discovery is part of the migration scope.
Simulations against production data
Simulations show the effect of a role or policy change on real identities before anything is applied. Ask whether Syncope can preview account changes, conflicts and policy outcomes against production-like data without writing to targets. Run a dry-run on a copy of your directory. midPoint lists simulations against production data among its supplied capabilities, so it is the closer match when change impact must be shown to approvers before rollout.
Audit reporting
Auditors ask who requested, approved and received each access change, and when. Confirm whether Syncope records these events in a form you can query and retain, and whether reports can be produced without a custom database extract. Request a sample audit report and check it against your evidence list. midPoint lists auditing among its supplied capabilities, so it is the closer match if audit trails must cover the full request and certification history.
Capability, commercial product and open-source platform side by side
This table compares the main Oracle Identity Governance capability areas with Apache Syncope. Where a cell says to confirm, the detail was not verified for this comparison, so check it against Oracle documentation and your own configuration before you decide. Syncope's strongest fit is provisioning, connectors and self-service, while certification and segregation of duties need separate evaluation.
| Capability | Oracle Identity Governance | Apache Syncope |
|---|---|---|
| Provisioning and deprovisioning | Commercial identity governance category covering account lifecycle across connected targets. Confirm supported lifecycle events with Oracle. | Identity management service that synchronizes identity data across connected systems. Confirm event handling in the 4.1 documentation. |
| Connector framework | Oracle-supplied and partner connectors on the Oracle middleware stack. Confirm the connector catalog for each target system. | ConnId connectors, with documented examples including SOAP, CSV, PowerShell and Active Directory. |
| Workflow and approvals | Request and approval workflows built on the Oracle SOA Suite stack. Confirm the approval designer features with Oracle. | Not covered by the supplied facts. Confirm workflow and approval options in the Syncope documentation. |
| Self-service and password reset | Self-service request and password management in the product category. Confirm the exact end-user features in your version. | End-user UI supports self-registration, self-service and password reset. |
| Delegated administration | Administrative roles and delegated access are part of the product category. Confirm how delegation is modeled in your deployment. | Admin UI includes delegated administration. Confirm the permission model against your access policy. |
| Single sign-on | Typically paired with Oracle access management products. Confirm the integration scope and licensing with Oracle. | Web Access hub supports SAML 2.0 and OpenID Connect for authentication and single sign-on. |
| Certification (access reviews) | Access certification is a core product category. Confirm review campaign features and evidence exports with Oracle. | Not covered by the supplied facts. Confirm whether access reviews exist or need a separate tool. |
| Segregation of duties | Commercial product category with policy-based checks. Confirm rule types and where SoD rules are enforced. | Not covered by the supplied facts. Plan for SoD rules through another platform or custom development if needed. |
| Supported databases | Oracle stack deployments use Oracle Database. Confirm the supported database versions with Oracle. | PostgreSQL 18 or later, MariaDB 12 or later, MySQL 9 or later and Oracle Database 23 or later for internal storage. |
Where identity data lives and who controls the platform
Apache Syncope removes the license fee, but the operating responsibility stays with your team: where the data sits, how the database is protected, and who holds the keys. The cards below cover the decisions that an Oracle Identity Governance exit forces you to make before cutover.
Data stays in your infrastructure
Syncope Core stores identity records, the configuration repository and provisioning state in infrastructure you choose, whether that is your data center, an air-gapped network or a cloud account you control. Nothing in the Apache License 2.0 sends identity data to the project or to a vendor. Confirm where logs, exports and backups are copied, because those copies carry the same personal data as the live system.
Hosting model decisions
Decide between on-premises virtual machines, containers or cloud accounts that your team administers. Each option changes patching, network placement and who responds to host incidents. Oracle Identity Governance usually runs on WebLogic and SOA Suite hosts that your team already operates, so check whether those skills, monitoring and change processes carry over to the Java and container runtime you choose.
Database choice and backup
Syncope supports PostgreSQL 18 or later, MariaDB 12 or later, MySQL 9 or later and Oracle Database 23 or later for internal storage, as listed for version 4.1.3. Neo4j 5.26 or later is functional but not considered stable for production. Confirm these versions against the getting started guide and your own database support policy, and test restores of the identity database on a schedule, not only backups.
Trust boundaries across components
Syncope Core manages identities, Web Access handles authentication and single sign-on through SAML 2.0 and OpenID Connect, and Secure Remote Access proxies HTTP traffic. Each boundary needs its own network rules, service accounts and certificates. Connector credentials for target systems such as Active Directory are a separate trust relationship, so map which component holds each secret and limit what it can reach.
Audit log retention
Oracle Identity Governance produces audit records that many regulated teams already retain for review. Syncope and its connected systems will produce their own logs, and you must define how long they are kept, where they are shipped and who can read them. Agree retention periods with your compliance and records teams before cutover, and confirm that the audit trail for each provisioning change can be reconstructed from the stored records.
Key and credential ownership
Your security team owns the keys that protect the platform: database credentials, connector service account passwords, TLS certificates and signing keys for single sign-on. No license vendor holds these on your behalf, so rotation, storage in a secrets manager and emergency revocation become your procedures. Document who can rotate each credential and test that rotation does not break connected targets.
What drives the cost of running Syncope versus OIG
The largest difference in running cost is the license line: Oracle Identity Governance carries Oracle license and annual support fees, while Apache Syncope is licensed under Apache-2.0 and carries no license fee. Around that line, the OIG bill also includes the WebLogic and SOA Suite infrastructure it runs on, the Oracle Database that stores its data, and specialist staff who understand that stack. On the Syncope side, the recurring costs are the servers or virtual machines, the database (Syncope supports PostgreSQL, MariaDB, MySQL and Oracle Database for internal storage), staff time to patch and upgrade the platform, and support if you buy it from a third party. Confirm the supported database versions for your chosen release in the Apache Syncope downloads page before you price the database tier.
Several costs are one-time and several recur. One-time costs include the implementation itself, connector work for each target system, and migration testing against production-like data. Connector effort is usually the largest variable: Syncope uses the ConnId framework, and the connectors you need (for example, Active Directory, SOAP, CSV or PowerShell) may need configuration or custom development for each system that OIG connects to today. Recurring costs include hosting, patching, database maintenance, backups, and staff time for each upgrade, which includes retesting every connector. What drives these costs up is the number of target systems, custom workflows, and the number of certification campaigns you must evidence. What drives them down is a smaller connector list and a stable set of roles.
Before you ask for a quote, prepare a written scope that lists the connector inventory, the number of identities in scope, the approval and certification workflows you must keep, and the audit evidence your assessors will request. Ask the implementer to price each connector separately, to state which tests are included, and to say who owns upgrades after go-live. Syncope does not provide certification campaigns or segregation of duties analysis in the way OIG does, so ask whether those controls will be built, bought, or handled by another product. DeployOpen does not publish prices, and a quote follows from the written scope. Confirm the Syncope features you need with the project documentation and your own environment before any figure is agreed.
What moving from OIM to Apache Syncope involves
The sequence moves OIG's provisioning, approval and self-service behavior onto Syncope in stages, with each stage checked against the same target systems before WebLogic and SOA Suite are retired. It produces a documented, reconciled Syncope deployment and a signed-off decommission plan for the Oracle stack.
Inventory OIG resources, roles and approval flows
Start by listing every connected target, each role or entitlement model, the approval and request flows, and the certification campaigns that run today. The configuration export from OIG is an input to this inventory, since it shows the artifacts OIG holds, but it does not cover everything. Identity records, account links, and audit history must be extracted separately, and your team should confirm which of these your compliance obligations require you to keep. Done means a reviewed inventory signed by the application owners, with each item marked as keep, redesign or retire.
Map each target to a ConnId connector
For every target in the inventory, identify the ConnId connector Syncope would use and confirm it is available in your Syncope release. Syncope documents connectors such as SOAP, CSV, PowerShell and Active Directory, but connectors for other systems may be community-built or may need to be written, so check each one against your own target versions rather than assuming coverage. Where a connector is missing, record the build or licensing work as a separate item. Done means a connector matrix that names each target, its connector, its owner and any open gap.
Model identity types, schemas and provisioning policies
In a Syncope test environment, define the identity types, attribute schemas, and provisioning mappings that replace OIG's user and account model. Decide which attributes are authoritative, how group or role membership maps to target entitlements, and which provisioning rules fire on create, update and disable events. Test each rule against sample identities and confirm the output on each target. Done means a documented data model and a set of test cases that pass against non-production targets.
Port approval workflows and self-service flows
Rebuild the approval paths and self-service actions that users and managers rely on, including access requests, registration, and password reset. Syncope provides an Admin UI with delegated administration and an End-user UI for self-registration, self-service and password reset, and its workflow support is where approval logic is defined. Walk each rebuilt flow with the business owners, because approval chains often contain undocumented exceptions from OIG. Done means each flow in the inventory has an agreed Syncope equivalent, a test script, and an owner's sign-off.
Run reconciliation and parallel provisioning
Run Syncope and OIG side by side against the same targets for a defined observation period that your change board sets. Reconcile the accounts and entitlements each system reports for the same identities, and investigate every difference until the cause is known and the difference is either fixed or accepted in writing. Keep OIG authoritative for production changes during this period so that any discrepancy can be traced. Done means a reconciliation report with zero unexplained differences for the agreed scope.
Hand over Syncope and retire WebLogic and SOA Suite
Once reconciliation is accepted, move production authority to Syncope, keep OIG in read-only mode for the retention period your audit and records policies require, and then decommission the WebLogic domain, SOA Suite components and the related Oracle Database schemas. Confirm the backup and restore procedure for the retained OIG data before shutdown, and confirm the retention period with your compliance team and legal advisers, since it is set by your obligations rather than by the software. Done means a signed decommission record, a verified archive of OIG data and updated operating documentation for Syncope.
Questions buyers ask before choosing Apache Syncope over OIG
What does switching from Oracle Identity Governance to Apache Syncope cost?
The license line item disappears, but the switch has one-time and recurring costs that you should price separately. One-time costs include discovery of existing OIG resources, rebuilding connectors and workflows, testing, and parallel running against the same targets. Recurring costs include the infrastructure to run Syncope, database operations, patching, and staff time. Apache Syncope is licensed under Apache-2.0, so there is no software license fee, but any commercial support or implementation partner is a separate line. Ask any provider for a written, fixed-scope quote that lists each deliverable, and ask your own team to estimate the hours it will spend on connector and workflow rebuilds.
How much effort does an OIG to Syncope move take, and what does it need from my team?
Effort is driven mostly by how many target systems, custom Java plugins, approval processes and reconciliation rules your OIG environment contains. Syncope uses ConnId connectors, and its documented set includes SOAP, CSV, PowerShell and Active Directory, so any target without a matching connector needs custom work. Your team will need people who know the identity data model, the target system owners, and Java and Jakarta REST skills for customization. Plan for a parallel run against the same targets before retiring OIG. Use an inventory of your OIG resources as the first deliverable to size the work honestly.
Can an in-house team run this migration without an outside partner?
A capable in-house team can do it if it has the skills, the time and the test environments, but many organizations choose outside help for the parts that are unfamiliar. The questions to answer first are whether your staff has prior experience with Syncope or ConnId, whether they can maintain the deployment after go-live, and whether they can staff the migration alongside current operations. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your own infrastructure under a fixed-scope written agreement, so a partner can take a defined piece of the work. Compare that against your own capacity before deciding.
Does Apache Syncope cover the certification and segregation of duties controls an auditor expects?
Not on the basis of the facts available here, so verify this before you commit. Syncope documents provisioning through ConnId, an Admin UI with delegated administration, an End-user UI for self-service and password reset, and Web Access for single sign-on. The supplied information does not describe access certification campaigns or segregation of duties rule engines in Syncope. Ask the Apache Syncope project and your own compliance team to map each control your auditor tests against the features you would use, and build a test for each one. Where a control is missing, decide whether you will build it, add a complementary tool, or use a platform that documents it, such as midPoint.
Which database should I choose for Apache Syncope, and why?
Choose the database your organization can operate, back up and patch with confidence, and check that it is on the supported list. The Apache Syncope 4.1 getting started guide lists PostgreSQL 18 or later, MariaDB 12 or later, MySQL 9 or later and Oracle Database 23 or later for internal storage. Neo4j 5.26 or later is functional but not considered stable for production. Consider your existing skills and backup tooling, your licensing position if you currently run Oracle Database for OIG, and the operational load the identity store will create. Test restore procedures before go-live.
What does an Apache Syncope support subscription cover?
The supplied facts do not describe Apache Syncope's support tiers, so you should not assume any specific response times or coverage. Apache Syncope is an Apache Software Foundation project, and its project resources differ from a commercial support contract. If you need guaranteed response times, ask whether a third-party provider offers a support agreement, and ask for the response commitments, escalation path, supported versions and exclusions in writing. Compare that with the support model you have today under OIG so the gap is visible before the decision.
When is midPoint a better choice than Apache Syncope for replacing OIG?
midPoint is the better fit when you need identity governance functions closer to what OIG provides, including provisioning and deprovisioning, role-based access control, auditing, self-service access requests, simulations and role mining. midPoint is developed by Evolveum, is dual-licensed under EUPL and Apache 2.0, and connects to targets through the ConnId framework, so connector work is comparable. Evolveum offers Product Support and Platform Subscriptions with stated SLA options, but the supplied facts list no prices. Choose Syncope if your need is lighter identity management with a strong self-service focus. Test both against your own top ten controls and your largest connector before deciding.
How DeployOpen works on this
DeployOpen plans and implements self-hosted open-source identity platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Oracle Identity Governance to Apache Syncope or midPoint, we start by agreeing what the project must cover, then build, test, document and hand over the result.
How we scope
- We agree in writing which Oracle Identity Manager or OIG connectors, roles, approval flows and audit needs the target platform must cover.
- We map each certification and segregation of duties requirement to a named gap, so you can see early where Syncope needs supplementary tooling or midPoint is the better fit.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy the chosen platform in your environment, including its database, ConnId connectors and self-service and password reset flows.
- We build connectors to your Active Directory, HR source and target applications, then test reconciliation against non-production copies of your data.
- We harden the deployment and produce runbooks, configuration records and evidence that your internal and external auditors can review.
How we hand over
- We document the configuration, connector mappings, workflow definitions and operational procedures so your own team can run the platform.
- We run knowledge transfer sessions with administrators and security staff, and agree a test plan for each handover item.
- We confirm backup and restore procedures and the upgrade path for the release you deploy, with your vendor or the project confirming supported versions.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing after the initial handover.
- We can help you plan and test upgrades between platform releases, and retest connectors and workflows after each change.
- Your Evolveum or Apache Syncope support options are a separate decision, and we help you compare them against your own service requirements.
