midPoint vs Apache Syncope: which fits your identity scope
Choose midPoint when your main problem is provisioning and governing accounts across many directories and SaaS systems, and you already have, or plan to run, a separate login layer. midPoint is an identity governance and administration platform, and Evolveum states that it is an identity management system, not an access management or SSO server. It does not implement the server side of OAuth2, OpenID Connect or SAML, so it will not issue the tokens your applications use to log in. Its code is licensed under EUPL-1.2 with Apache 2.0 as a secondary license, and Evolveum states there is no Enterprise Edition. Support comes from optional Evolveum subscriptions, with a Product Support tier for resolving bugs and a Platform tier that adds feature development and roadmap influence. Check the SLA and the price in writing with Evolveum before you assume either tier fits your operating hours.
Choose Apache Syncope when you want identity management and a login hub from one project. Syncope includes Syncope Web Access, which handles authentication, authorization and single sign-on over SAML 2.0 and OpenID Connect, and Secure Remote Access, an API gateway with HTTP reverse proxying. The project is licensed under Apache-2.0, which many legal teams review more quickly than copyleft terms. For the 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 for internal storage, so a team with an existing Oracle or MySQL estate has more choice here than with midPoint, which uses PostgreSQL as its native repository. Confirm those version floors against your own database standards before you commit.
Which platform fits which scenario
This table maps common midPoint and Apache Syncope scenarios to the platform that usually fits better and the condition that makes it so. Treat each row as a starting point: the right choice depends on requirements that you should confirm with each vendor and against your own environment.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Self-hosted SSO hub for web applications | Apache Syncope | Syncope Web Access handles SAML 2.0 and OpenID Connect single sign-on in the same product. midPoint does not implement the server side of SSO, so you would pair it with a separate access management product. |
| Provisioning accounts to Active Directory and SaaS targets with approval workflows | midPoint | midPoint is built around governance features such as certification, role lifecycle and approval processes. Confirm the connectors you need from the ConnId catalog and their support status before committing. |
| Identity lifecycle with synchronization across many internal systems | Either, after a proof of concept | Both use ConnId connectors. Test your specific source and target systems, data volumes and mapping rules in a pilot rather than relying on connector lists alone. |
| Team standardized on PostgreSQL wanting one native repository | midPoint | midPoint uses PostgreSQL as its native repository database and recommends a separate database server. Syncope supports several databases, which matters only if you need that flexibility. |
| Platform must run on MariaDB, MySQL or Oracle internal storage | Apache Syncope | Syncope lists PostgreSQL, MariaDB, MySQL and Oracle Database for internal storage. Confirm the exact supported versions for your target release in the getting started guide. |
| Organization requires paid vendor support with defined response windows | midPoint | Evolveum sells Product Support subscriptions with 8x5 next-business-day or 24x7 SLA options. Ask Apache Syncope's community or third-party providers for equivalent commitments, since none are supplied here. |
| Licensing must avoid copyleft obligations on modifications | Apache Syncope | Syncope is Apache-2.0. midPoint is EUPL-1.2 or later with Apache 2.0 as a secondary license. Have your legal team review how each license applies to your planned changes. |
How midPoint and Syncope are built and what that means for operations
midPoint and Apache Syncope both manage identity data across connected systems, but they are assembled differently. The components below determine how each one is patched, scaled and staffed, and they are the first things to test in a proof of concept.
midPoint application on Linux or Docker
midPoint runs as a Java application that can be installed on Linux in a virtual machine or started from Docker images. The Java version is tied to the release line: midPoint recommends Java 25 for 4.11 and later (Java 21 supported) and Java 21 for 4.10 and older (Java 17 supported). Check whether your base images and patch process can move to the required Java version before choosing a release line.
Native PostgreSQL repository
midPoint uses PostgreSQL as its native repository database and recommends running it on a separate database server. This places database backup, tuning and failover on the same schedule as the identity platform. Ask who owns the database, how backups are restored in a test environment, and whether the team already operates PostgreSQL at the required level.
Multi-node operation and scheduling
Multi-node midPoint needs a sticky HTTP load balancer, a shared central database, cache invalidation between nodes over HTTPS and Quartz for distributed task scheduling. Each element is a place where a misconfiguration can cause duplicate tasks or stale cache state. Plan load balancer session stickiness, node-to-node HTTPS trust and Quartz configuration as part of the design, not as later tuning.
Syncope Core behind a REST interface
Syncope Core provides identity management services and a central configuration repository behind a Jakarta RESTful Web Services 3.1 interface. Other systems, including the Admin UI and End-user UI, call this interface. Staff who automate provisioning will work against this API, so confirm that the team can version, test and monitor REST integrations alongside the core service.
Admin UI and End-user UI
Syncope ships an Admin UI with delegated administration and an End-user UI for self-registration, self-service and password reset. These front ends add user-facing surface area that must be patched, reviewed and tested with the core. Confirm which of these interfaces your help desk and end users will actually use before counting them as part of the operating footprint.
Web Access and SRA components
Syncope Web Access is the hub for authentication, authorization and single sign-on, supporting SAML 2.0 and OpenID Connect. Secure Remote Access is an API gateway with HTTP reverse proxying. midPoint has no built-in SSO server, so it would need an external access management product for this role. Ask which of these components your architecture requires and who will own their certificates, session settings and upgrades.
midPoint vs Apache Syncope feature comparison
This table compares midPoint and Apache Syncope on licensing, identity governance scope, built-in single sign-on, connectors, databases, runtime requirements and vendor support. Read the rows for the capabilities you must have, and treat cells marked to confirm as open questions for the vendor. The main takeaway: midPoint provisions and governs identities, while Syncope includes its own login hub.
| Capability | midPoint | Apache Syncope |
|---|---|---|
| License | EUPL-1.2 or later, with Apache 2.0 as a secondary license. No Enterprise Edition. | Apache-2.0 for the project. |
| Governance focus | Identity governance and administration. Confirm specific certification and workflow features in the vendor documentation. | Identity management that synchronizes identity data across systems. Confirm governance features in the vendor documentation. |
| Built-in SSO | None. Evolveum states midPoint is neither an authentication server nor an SSO server. | Yes. Syncope Web Access handles authentication, authorization and single sign-on. |
| Server-side OAuth2, OpenID Connect or SAML | No server side for these protocols. Its user interface can authenticate against external SSO services. | Web Access supports SAML 2.0 and OpenID Connect. Confirm OAuth2 server support. |
| Connector framework and documented connectors | ConnId. Documented: LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Entra ID, SCIM2 and SCIMv1. | ConnId. Documented: SOAP, CSV, PowerShell and Active Directory. |
| Internal databases and native repository | PostgreSQL as the native repository, ideally on a separate database server. | PostgreSQL 18 or later, MariaDB 12 or later, MySQL 9 or later, Oracle Database 23 or later. |
| Neo4j status | Not covered in the comparison facts. Confirm in the vendor documentation. | Functional but not considered stable for production use. |
| Java requirement | Java 25 for 4.11 and later (Java 21 supported). Java 21 for 4.10 and older (Java 17 supported). | Confirm the required Java version in the Syncope 4.1 documentation. |
| Vendor support options | Evolveum Product Support with 8x5 next-business-day or 24x7 SLA, plus Platform Subscriptions. No prices listed. | Apache project. No vendor subscription is listed here. Confirm commercial support options with the project and third parties. |
midPoint vs Apache Syncope licensing and editions
midPoint is released under the European Union Public License, EUPL-1.2, with the option of later versions of that license, and its repository names Apache 2.0 as a secondary license. Evolveum states that midPoint has no enterprise edition: every line of code is published under open source licenses, and the project describes itself as open source. Evolveum funds development through subscriptions, training and professional services, so the commercial relationship centers on support and roadmap input.
- No gated edition: Evolveum says the full product is open source, so identity governance functions do not sit behind a separate paid build. Confirm that each feature you depend on is available in the release line you plan to run.
- Product Support: These subscriptions resolve product bugs under an 8x5 next-business-day SLA or a 24x7 SLA. Match the window to your operating hours and ask for the SLA terms in writing.
- Platform Subscriptions: These add feature development and roadmap influence on top of support. They suit teams that need a specific capability built into the product.
- No published prices: The support subscriptions page lists no prices, so cost comes from a quote. Ask for the tier, the SLA, the covered deployments and the renewal terms.
- Separate costs: A subscription does not cover implementation, hosting, database administration or integration work. Those costs remain with your team or your implementation partner.
Before you sign, confirm which midPoint release line the subscription covers, because support end dates differ between lines.
Apache Syncope is licensed under Apache-2.0, a permissive license, and its project describes its mission as software for managing digital identities in enterprise environments. This page does not identify a paid edition of Syncope or a commercial support tier. Confirm with the Apache Syncope project or a commercial provider whether one exists before you build a budget, and do not treat the absence of a named edition as a guarantee of free professional support.
- Permissive license: Apache-2.0 allows use, modification and redistribution subject to its notice and attribution conditions. Have your legal team confirm the obligations that apply to your deployment.
- No edition ladder identified: With no paid tier described here, the licensing question is mostly about your own build, hosting and operating model.
- Community support path: Unless you contract a provider, troubleshooting relies on project channels and your own engineers. Plan staffing on that basis.
- Release line: Apache Syncope 4.1.3 and 4.0.8 were both released on September 11, 2026. Confirm which line receives fixes for the timeline you need.
- Commercial providers: Verify any support provider directly with the Apache project or the vendor, and request their scope, SLA and the Syncope versions they cover.
Before shortlisting, ask in writing whether any commercial support exists for your deployment and what it covers.
A fair comparison needs the same questions asked of both projects. Procurement teams should request equivalent information for each option so that support windows, release dates and license obligations can be compared directly rather than inferred from marketing material.
- Support window: midPoint offers 8x5 next-business-day and 24x7 SLA options. Ask whether Syncope support can match your incident response window, and from whom.
- Subscription scope: For midPoint, ask exactly what a Product Support subscription covers compared with a Platform Subscription, including how feature requests are prioritized.
- Release support dates: midPoint 4.8 is supported until October 17, 2028, and 4.10 until November 26, 2027. Ask the Syncope project or its providers for the equivalent dates for the version you intend to deploy.
- License obligations: EUPL-1.2 and Apache-2.0 both carry conditions when you distribute modified code. Have counsel review each license against your planned use.
- Written quotes: Because midPoint publishes no prices, request a written scope and pricing for each option, and compare them on identical assumptions.
If a vendor cannot answer any of these questions in writing, record that gap as a risk in your evaluation.
What drives the running cost of each platform
The running cost of midPoint and Apache Syncope is set less by licence fees, since both are open source, than by the infrastructure they need, the skills your team must keep on hand and the connector work that never stops. For midPoint, the recurring infrastructure line includes application nodes, a separate PostgreSQL server (midPoint recommends running the database on its own server) and the sticky load balancer and shared database that a multi-node setup requires. For Syncope, the line is the chosen internal database, which can be PostgreSQL, MariaDB, MySQL or Oracle, plus any Neo4j instance you add for its non-production graph storage. Ask each vendor or integrator to price these as separate items, with the database engine, the number of nodes and the backup and high-availability design written out.
Skills are the largest recurring cost in most identity projects, and they differ between the two platforms. midPoint work draws on Java (midPoint recommends Java 25 for 4.11 and later, with Java 21 supported) and on PostgreSQL administration, and its configuration lives in XML-based objects that your team must be able to read. Syncope work draws on Java and Jakarta REST, plus the database engine you select. Either way, connector maintenance recurs: each target system (directory, HR source, SaaS application) needs a ConnId connector that must be retested when the target or the connector changes. Upgrades add a further recurring cost, because each midPoint or Syncope line has its own support window and its own migration notes, so budget a regular upgrade cycle rather than a one-off project.
Evolveum's support and platform subscriptions are the main vendor-paid line, and the supplied facts do not give their prices, so request a written quote for the support tier (8x5 next-business-day or 24x7 SLA) and state whether it covers bug fixes only or also feature development. Apache Syncope has no comparable vendor subscription from the project itself, so the equivalent cost is an external support or retainer contract, which you should scope separately. For either platform, ask for one-time build effort, recurring upgrade and connector support effort, and the infrastructure assumptions behind each figure, in the same format, so the two quotes can be compared line by line.
Moving from one platform to the other
This sequence moves identity data, connector logic and governance rules from one platform to the other without disrupting the systems that depend on them. Each step ends with a check that tells the team whether it can proceed. The same order applies in either direction, but the specific work depends on how far the current deployment has been customized.
Inventory connectors, objects and policies
Start by listing every connected system, every object type (users, groups, roles, organizations or entitlements), every provisioning and reconciliation rule, and every approval or workflow step in the current platform. The owning identity engineer produces this inventory, and the security or compliance lead signs off on which policies carry regulatory weight. The step is done when each connected system has a named owner, a connector type and a documented list of attributes it reads or writes. Ask the vendor or a partner to confirm which connectors are supported, community or experimental before you commit to a target.
Map the data model between platforms
Map each object type and attribute in the source platform to its counterpart in the target. midPoint models users, roles, resources and policies through its own object model, while Apache Syncope uses users, groups and any-objects with its own schema and mapping rules. Record every attribute that has no direct equivalent and decide whether it is dropped, derived or stored in a custom field. The step is complete when the team has a signed mapping document that lists unmapped attributes and the reason for each one.
Rebuild connector configurations in the target
Recreate each connector in the target platform using the ConnId framework, which both platforms use, and point it at a test copy of each connected system. Connector settings, credentials, search filters and attribute mappings must be re-entered and checked, because they rarely copy across unchanged. The owning engineer runs read-only queries first, then test provisioning actions against non-production accounts. The step is done when a sample of accounts reads and writes correctly in every connected system.
Recreate governance logic and workflows
Rebuild reconciliation rules, role assignments, approval flows and any custom workflow definitions in the target platform. Expect this to be the most design-heavy step, because workflow definitions and governance policies are not portable between the two products and must be re-expressed in each target's own model. The governance lead reviews each rebuilt rule against the inventory from step one. The step is complete when every rule in the inventory has a target equivalent or a recorded decision to retire it.
Rebuild SSO and access integrations
Identify every application that relies on the identity platform for login. Remember that midPoint does not act as an authentication or SSO server, so single sign-on for those applications typically runs through a separate access management product, while Apache Syncope includes Syncope Web Access for SAML 2.0 and OpenID Connect. Reconfigure each relying application against its new sign-on source and test login, logout and token refresh. The step is complete when each application passes a documented login test in the staging environment.
Migrate the database and run in parallel
Move the data store to the target's supported database, confirming versions against the current vendor documentation, since midPoint uses PostgreSQL as its native repository and Apache Syncope supports several relational databases and Neo4j. Run both platforms in parallel for a defined window agreed before work starts, comparing provisioned accounts, group memberships and audit records between them. The platform owner signs off when the differences are explained and accepted. Ask the implementation partner to state in the written scope how parallel-run results will be recorded.
Cut over and verify live provisioning
Switch authoritative control of provisioning to the target platform in a planned change window, and disable the source platform's write access to connected systems first to avoid conflicting updates. Monitor reconciliation runs and failed provisioning tasks closely during the first cycles. The cutover is complete when the target platform is the only system writing to connected systems and the first full reconciliation cycle produces no unexplained changes.
Decommission the source platform
Once the target has run cleanly, retain a read-only copy of the source database, configuration exports and audit logs for the retention period your compliance obligations require. Then remove connector credentials from the source, revoke its service accounts and shut down its services. Confirm the retention period with your compliance lead and your auditor, not with the vendor. The step is done when the retained archive is verified and the source platform no longer holds live credentials for any connected system.
Implementation effort for midPoint and Apache Syncope
Implementation effort on both platforms is driven less by installation than by the target systems you must connect and the approval logic you must design. On the midPoint side, the database work centers on PostgreSQL as the native repository, ideally on a separate database server, with sizing set by your object volume and the number of nodes behind a sticky HTTP load balancer. On the Syncope side, you choose one of the supported internal storage databases (PostgreSQL 18 or later, MariaDB 12 or later, MySQL 9 or later, or Oracle Database 23 or later) and confirm that choice against your DBA standards before deployment. Neo4j is functional but not considered stable for production, so do not plan around it. Both platforms also need a Java runtime that matches the release you pick, so check the midPoint system requirements for the Java version tied to your target release.
Connector work is where most of the schedule risk sits. Both platforms use the ConnId framework, so you will test each target system (directory, HR source, SaaS application or database) against the connector you select, covering create, update, disable and delete behavior, plus edge cases such as multi-valued attributes and renamed accounts. Syncope's Web Access hub provides SAML 2.0 and OpenID Connect single sign-on for its own consoles and connected applications, so you need a design for that hub, its certificates and its client registrations. midPoint does not act as an SSO server. Its own UI authenticates against an external SSO service, so you must select and configure that service as a separate workstream. Test identity source design, hardening and the handover of runbooks as distinct phases, and ask your implementation partner to deliver runbooks for backup, restore and upgrades with each one.
Projects usually run long for three reasons: undocumented target systems, approval workflow design, and connector edge cases. Ask the target system owners for their provisioning rules, account lifecycles and existing scripts before the estimate is written, because gaps there are expensive to fill later. Define approval flows in writing, including who approves what and what happens on timeout, since those decisions shape both platforms' workflow configuration. Record the connector edge cases you have found and agree which are in scope. Put all three into the written scope before work starts, along with the upgrade path for the release line you select, and confirm the support window for that line with Evolveum or the Apache Syncope project directly.
Common questions about midPoint and Apache Syncope
Can a team run midPoint or Apache Syncope without a partner?
Yes, both are open source and can be deployed in your own infrastructure without a vendor contract, but the work is significant. Both need a Java application server, a supported relational database and an identity model designed by someone who understands your sources. midPoint is licensed under EUPL-1.2 or later with no Enterprise Edition, and Evolveum sells subscriptions for support, so a support contract is optional rather than a gate to features. Apache Syncope is Apache-2.0 licensed. The deciding factors are how many authoritative sources you connect, how many approval and certification flows you need, and whether your team has run identity projects before. Ask your team to inventory connectors, data owners and joiner, mover and leaver rules before choosing a path, and treat a partner as one option among several.
What skills does a team need to run either platform?
Expect to need engineers who know Java, PostgreSQL administration, LDAP or Active Directory, and the ConnId connector framework both platforms use. midPoint recommends Java 25 for version 4.11 and later, with Java 21 supported, and Java 21 for 4.10 and older. midPoint can run on Linux in a virtual machine or from Docker images, and multi-node setups need a sticky HTTP load balancer, a shared central database and cache invalidation between nodes. Syncope adds a Jakarta RESTful Web Services 3.1 interface, an Admin UI and Web Access for single sign-on if you use it. Governance designers, who write mappings, roles and approval logic, are often the scarcest skill. Confirm named owners for each role before the project starts.
What drives the cost of an identity governance project?
The main cost drivers are the number and complexity of connected systems, the number of identity sources you must reconcile, the depth of approval and certification workflows, and the amount of custom connector or mapping work. Cost components include internal staff time, infrastructure, database operations, any subscription fees for vendor support, and external consulting or implementation work. One-time costs cover design, build, data cleansing and cutover. Recurring costs cover upgrades, connector maintenance, patching and support. For midPoint, Evolveum publishes support tiers but no prices on the subscriptions page, so ask for current pricing directly. Request a quote that separates design, build, testing, cutover and run-state support.
Can midPoint provide single sign-on for our applications?
No, midPoint does not provide single sign-on on its own. Evolveum states that midPoint is an identity management system, not an access management or SSO server, and it does not implement the server side of OAuth2, OpenID Connect or SAML. It provisions accounts to access management systems instead. Syncope, by contrast, includes Syncope Web Access, which handles authentication, authorization and single sign-on with SAML 2.0 and OpenID Connect. If you choose midPoint, plan a separate SSO product such as Keycloak, authentik or Zitadel, and confirm how each application will authenticate and receive provisioned accounts. Verify integration details in your own environment before committing.
Which database should we choose for midPoint or Syncope?
Choose a database your operations team can back up, patch and monitor. midPoint uses PostgreSQL as its native repository database and recommends running it on a separate database server. Apache 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, and lists Neo4j 5.26 or later as functional but not considered stable for production. For most teams already running PostgreSQL, the choice is simple. If your standard is Oracle or SQL Server, confirm support for your exact version with each vendor before design. Database choice also affects high availability, backup windows and licensing costs.
How hard is it to move between midPoint and Syncope later?
Switching is a re-implementation rather than a data export. Both platforms store identity data, roles, mappings and connector configuration in their own models, so you cannot simply copy objects across. The effort depends on how many connectors, mappings and approval flows you built, how clean your source data is, and whether you can run both platforms in parallel during cutover. Both use ConnId connectors, which reduces some connector rework, but governance logic and role models usually need redesign. Keep your requirements, role catalog and mapping documentation in a platform-neutral form from day one. Ask any implementation partner for a written migration approach before committing to either path.
How does DeployOpen scope a midPoint or Syncope engagement?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers and air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for a scope document that lists connected systems, identity sources, governance workflows, database and operating environments, and handover deliverables. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.
How DeployOpen helps you choose, implement or migrate
DeployOpen works on midPoint vs Apache Syncope as a self-hosted implementation partner, inside your own cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Confirm whether you need governance, provisioning or built-in SSO, since midPoint and Syncope differ on that point.
- Map your authoritative sources and target systems to ConnId connectors and note which ones need validation.
- Agree the database engine, Java version and hosting model in writing before any build starts.
- Record which Syncope Web Access or external SSO components are in or out of the written scope.
How we build
- Deploy the chosen platform in your infrastructure with the database and runtime versions confirmed for your release line.
- Configure connectors, mappings and approval workflows against your own systems rather than sample data.
- Test provisioning, deprovisioning and access reviews in a staging environment before production cutover.
- Document configuration, connector settings and the evidence needed for compliance readiness reviews.
How we hand over
- Deliver runbooks covering installation, upgrades, backups and routine operational tasks for your team.
- Walk your administrators through governance objects, role design and connector troubleshooting.
- Provide a written record of decisions, versions and open items so the next team can continue the work.
- Confirm handover acceptance against the written scope and deliverables agreed at the start.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Plan upgrades against the vendor release calendar, so your team knows which release lines are supported.
- Schedule periodic security testing of the identity platform and its connected systems if you want it.
- Ask for a quote built from the written scope, since DeployOpen does not publish a price list.
