Omada vs midPoint: which to choose

Which identity governance platform fits your organization

Choose Omada when your priority is a managed governance service and you accept operating inside Microsoft Azure, either as Omada Identity Cloud on Omada's SaaS platform or as Identity Cloud Private in your own Azure tenant. In that model your team consumes governance as a service and shifts day-to-day platform operation to the vendor. Choose midPoint when governance must run in infrastructure you control, whether that is your own data center, an air-gapped network or a cloud account you manage, and when you have engineers who can operate a Java platform backed by PostgreSQL. midPoint carries no license fee because Evolveum publishes every line of its code under open source licenses, so your spend moves to infrastructure, staff and, if you want it, a support subscription. The right answer usually follows from the requirement you cannot negotiate.

Four factors decide the choice. The first is hosting requirements: midPoint runs on Linux in a virtual machine or from Docker images, so a security or residency team that insists on your own network boundary can be satisfied directly. The second is in-house operating skills: midPoint recommends Java 25 for version 4.11 and later and Java 21 for 4.10 and older, uses PostgreSQL as its native repository, and multi-node deployments need a sticky HTTP load balancer, a shared database and Quartz for task scheduling. Check the system requirements against your platform team's skills. The third is the connector landscape, where each target system must be matched against midPoint's catalog, whose support status ranges from supported to community and experimental. The fourth is the budget model, which asks whether recurring cost sits with a vendor subscription or with a staffed team.

Before you decide, write down the target systems, the HR source and the review cycles you must support, then send that list to Omada and ask in writing which items it covers in each deployment model. Put the same list to midPoint and to any partner you consider. If you want vendor-backed support for midPoint, review the Evolveum support subscriptions page, which describes 8x5 next-business-day and 24x7 SLA options for product bug resolution, and confirm current terms and prices directly with Evolveum. Plan the version calendar too: midPoint 4.8 is a long-term support release until 17 October 2028, and 4.10 is supported until 26 November 2027. Your decision memo should name who runs the platform after go-live, because that person determines whether the open-source option saves money or moves cost elsewhere.

Scenarios where each option is the better fit

This table matches common operating conditions to the option that usually fits them better, so you can test each row against your own constraints. Read each row as a condition first and a recommendation second, since the right answer often depends on who will run the platform and where identity data may live. The main takeaway is that the decision turns on residency rules, staffing and how you want support and roadmap commitments delivered.

Scenario	Better fit	Why and when it matters
Identity data must stay in your own infrastructure under a residency rule	midPoint, or Omada Identity Cloud Private if your Azure tenant satisfies the rule	midPoint runs on Linux virtual machines or Docker in your environment. Confirm with Omada whether Identity Cloud Private meets your residency and access requirements before ruling it in.
Team wants a vendor-operated service and does not want to run software	Omada	Omada Identity Cloud is delivered as SaaS on Microsoft Azure, so the vendor operates the platform. This matters when your team has little capacity for patching, database operations and upgrades.
Team has Java and PostgreSQL skills and wants one product in dev, test and production	midPoint	midPoint is written in Java, uses PostgreSQL as its native repository and has no license fee or enterprise edition. Cost then centers on infrastructure and staff time, which your team can control directly.
Organization needs vendor-backed roadmap commitments and a contractual SLA	Omada, or midPoint with an Evolveum support subscription	Evolveum offers Product Support with 8x5 next-business-day or 24x7 SLA options and Platform Subscriptions that add roadmap influence. Ask Evolveum for the specific SLA terms in writing, as they differ by subscription.
Connector coverage for a specific target system is the deciding factor	Depends on the target system	midPoint's ConnId connectors cover LDAP, Active Directory, Microsoft Entra ID, SCIM2 and others, with some marked community or experimental. Verify the exact connector status for each target before deciding.
Need a single product that also provides SSO and web access management	Omada, with a separate SSO product	midPoint is an identity management system and does not implement the server side of OAuth2, OpenID Connect or SAML. Plan a separate identity provider for SSO whichever governance product you choose.
Organization wants to inspect and modify the governance code	midPoint	All midPoint code is published under EUPL-1.2 with Apache 2.0 as a secondary license, and Evolveum describes it as open source, not open core. Your security or development team can audit and patch it directly.

How midPoint covers lifecycle, access reviews and risk

The core of midPoint's documented scope is identity lifecycle and provisioning: provisioning and deprovisioning, role-based access control, auditing, self-service access requests and password reset, simulations against production data, and role mining. For an Omada customer, the practical question is which of these map to the processes you run today, such as joiner, mover and leaver handling driven from an HR source, role assignments tied to business roles, and how changes are logged for audit. Simulations and role mining deserve a specific test: run them against a copy of your own identity and entitlement data, and check whether the output is useful for the roles you actually maintain.

Access certification campaigns and risk scoring are the areas where this page cannot confirm midPoint capabilities, so do not assume them. Check the midPoint documentation for certification or review campaigns, reviewer workflows, and any risk or anomaly scoring, then build a test case for each one using your own accounts and approval rules. Ask Evolveum directly if a feature is missing or only partly covered. On the Omada side, lifecycle, review and risk features should be confirmed against Omada's current documentation and a demo on your own data. Do not accept a feature list as proof. Compare the same scenario on both platforms, including the number of manual steps and who signs off each decision.

Keep one boundary clear in the design. 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. Its own user interface can authenticate against external SSO services, but single sign-on for applications remains a separate component that you select, deploy and operate. If your Omada deployment currently provides or depends on sign-on features, add that component to the scope and cost comparison before you decide, and plan how application access decisions will reach that SSO layer.

Capability comparison: Omada Identity Cloud and midPoint

This table compares the identity governance capabilities that matter in an Omada replacement decision, with midPoint facts where Evolveum has documented them and confirmation items where Omada's current feature set must be verified in writing. Read each row as a question to put to both vendors, then check the answer against a proof of concept on your own systems. The main takeaway is that midPoint's capabilities are documented publicly, while Omada's must be confirmed against the specific edition and modules you plan to buy.

Capability	Omada Identity Cloud	midPoint (open source)
Lifecycle and provisioning	Confirm with Omada which joiner, mover and leaver workflows and target system provisioning are included in your edition	Covers provisioning, deprovisioning and identity lifecycle, per Evolveum
Access requests and self-service	Confirm request catalog, approval chains and self-service password reset in your contract scope	Covers self-service access requests and password reset, per Evolveum
Role-based access control	Confirm role model, role lifecycle and separation-of-duties support with Omada	Covers role-based access control, per Evolveum
Access reviews and risk features	Confirm review campaign types, risk scoring and certification workflows with Omada	Access review and risk scoring need validation in your deployment, as the supplied documentation does not detail them
Role mining	Ask Omada whether role mining is included and how it is licensed	Included, per Evolveum
Simulations	Ask Omada whether policy or assignment simulations run against production data	Simulations against production data, per Evolveum
Auditing	Confirm audit log retention, export formats and evidence reports with Omada	Auditing is a documented core capability, per Evolveum; confirm report formats for your assessor
Connectors	Confirm the connector list for your target systems and whether custom connectors are billed separately	ConnId framework with LDAP, Active Directory, Microsoft Entra ID, SCIM2 and more; check each connector's support status
Scale	Ask Omada for the largest identity count in a comparable production deployment	Evolveum states scale up to 100 million identities
Deployment models	SaaS on Microsoft Azure, or Identity Cloud Private in the customer's Azure tenant	Runs on Linux in a virtual machine or from Docker images, in any environment you control
SSO and access management	Confirm whether SSO or access management is included or sourced from another product	Not an SSO or access management server; pair with a separate identity provider
Support model	Subscription with terms set in the contract; confirm SLA and escalation path	Open source with optional Evolveum Product Support subscriptions offering 8x5 or 24x7 SLAs

How midPoint connects to your systems through ConnId

Every identity platform lives or dies by its connectors. midPoint reaches target systems through the ConnId framework, so the question for an Omada buyer is less about feature parity on paper and more about which connectors your current estate depends on and whether each one has a tested midPoint equivalent.

The ConnId framework

ConnId is the connector layer midPoint uses. Each connector is Java code behind a uniform interface that speaks the target system's native protocol, so midPoint core logic stays the same whether it provisions to a directory, a database or a SaaS API. For an Omada customer, the practical step is to inventory every Omada connector in use and map each one to a ConnId connector or a custom build before planning cutover.

Documented midPoint connectors

midPoint's documented connectors include LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID through Graph API, SCIM2 and SCIMv1. Entra ID and Active Directory are the first checks for an Azure-based Omada estate, since Omada Identity Cloud is delivered on Microsoft Azure. Confirm the exact connector version and the attributes, group models and entitlement types you need against the documentation before you assume parity.

Connector status across the catalog

The wider integration catalog does not carry one level of support. Connectors range from supported to community and experimental, and the status determines who fixes defects and how quickly. Treat any connector that is only community or experimental as a project risk, and decide in advance whether your team or an implementation partner will own its maintenance.

Building or maintaining an unsupported connector

For an application with no supported connector, the cost is engineering time to write, test and maintain a ConnId connector, plus ongoing work after every upgrade of the target system. Ask who will write it, who will test it against the target's API versions, and who will be paged when it fails. Omada's packaged connectors reduce this work where they exist, so the gap should be measured application by application.

HR source integration

Joiner, mover and leaver events usually start in an HR system, and the HR feed determines the accuracy of every downstream account. Whether you use a file, a database table or an API, define the authoritative attributes, the effective dates and the handling of rehires and contractors before you configure midPoint. Confirm with your HR team how the existing Omada feed is structured so that the midPoint source reproduces it.

Auditing your Omada connector dependencies

List every Omada connector currently in production, the target system it serves, the attributes it writes and the owner of each integration. For each one, record whether a midPoint equivalent exists, its support status, and the test that proves it behaves the same in a non-production environment. Connectors without a tested equivalent should be on the critical path of the migration plan, not in an appendix.

Where each option runs and who controls the data

Omada Identity Cloud in its SaaS form runs on Microsoft Azure in an environment that Omada operates. Your organization consumes the service and administers its configuration and connectors, while Omada is responsible for the application and its hosting under the agreement you sign.

Data location: Identity records, roles, access requests and audit logs sit in Omada's Azure environment. Ask which Azure regions hold your tenant data and where backups and support access originate.
Who operates it: Omada runs the application, infrastructure, patching and upgrades. Your team manages policies, sources, connectors and user administration.
Vendor access: Confirm in writing when Omada staff can reach your identity data, which approval process applies, and how that access is logged and shown to you.
Evidence you produce: You still own evidence for administrator access reviews, connector credential handling and approvals of provisioning decisions. Request Omada's current third-party assurance reports and map them to your control set.

Before an assessment starts, check the shared responsibility split in the contract and confirm which controls Omada covers and which fall to your team.

Subscription licensing versus open source with optional support

The core licensing difference is simple to state. midPoint is an identity governance and administration platform whose repository is licensed under the European Union Public License (EUPL-1.2), with Apache 2.0 as a secondary license, so there is no license fee to pay for the software itself. 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, not open core. Evolveum funds development through subscriptions, training and professional services, with midPoint developers working on it full-time. What you pay for with midPoint is therefore labor and support, not access to features. Omada, by contrast, is priced through a subscription, so the recurring cost is tied to the contract rather than to the software you run.

If you want vendor-backed support, Evolveum offers two subscription types. Product Support subscriptions resolve product bugs under either an 8x5 next-business-day or a 24x7 SLA. Platform Subscriptions add feature development and roadmap influence on top of that. The Evolveum support page lists no prices, so you will need to request a quote for the tier that matches your hours and escalation needs. On release support, midPoint 4.8 (Curie) is a long-term support release supported until 17 October 2028, which is the safer choice for a regulated deployment that expects a long run time. midPoint 4.10 (Braille) is supported until 26 November 2027. midPoint 4.9 support ends on 18 October 2026, and midPoint 4.11 is planned for 21 October 2026. Confirm the current status of each release on the midPoint releases page before you choose a version.

Whatever the vendor, ask for the terms in writing. For Omada, request the subscription agreement, the renewal conditions, any price escalation clause, the support SLA with its response and resolution targets, and what happens to your data and configuration at termination. For midPoint, the software cost is zero, but a support contract is optional, so compare Evolveum's written SLA against what your internal team can cover on its own. Document which support tier you are buying, what it excludes and how roadmap requests are handled, since a Platform Subscription influences priorities but does not guarantee specific features. These answers will shape the total cost model and the exit plan.

What each option costs to own and operate

Omada costs arrive as a vendor contract plus implementation work, while midPoint removes the license line and moves cost into infrastructure, operations and connector work. The cards below separate one-time from recurring spend so you can build a like-for-like comparison from written quotes.

Omada subscription or Azure consumption

For Omada Identity Cloud, the recurring cost is the vendor subscription and any Azure consumption it bills or depends on. For Identity Cloud Private, you also carry Azure resources in your own tenant. Ask the vendor to separate the subscription fee from consumption, state what drives each one (identity volume, connected sources, environments), and say which items renew annually. Recurring costs usually dominate this card's total over the contract term.

Omada implementation program

Vendors commonly require a structured implementation program before go-live, covering configuration, connector setup, HR source integration and access review design. Treat this as one-time effort, but confirm whether the vendor mandates partner-led delivery and whether post-go-live changes fall back under the same program. Ask for named deliverables and who pays for rework when source data is inconsistent.

midPoint licensing and support

midPoint is published under EUPL and Apache 2.0 with no license fee, so the software line is zero. An Evolveum support subscription is optional and recurring. Its Product Support tier offers 8x5 next-business-day or 24x7 SLA options, and Platform Subscriptions add feature development. The page lists no prices, so request a quote for the tier you need and confirm what it covers.

Infrastructure and database operations

midPoint runs on Linux virtual machines or Docker images and uses PostgreSQL, ideally on a separate database server. Multi-node deployments add a sticky HTTP load balancer, a shared database and Quartz task scheduling. Costs recur for compute, storage, backups and high availability, and they rise with identity count and the number of environments such as test and production. Check the system requirements before sizing.

Team that operates and upgrades

This is the largest recurring line for midPoint: staff or a partner who run the platform, apply patches and move between feature releases. Upgrade frequency drives effort. Plan around the release that matches your support window, and budget for Java runtime changes between releases, since the platform requires specific Java versions. Confirm whether your partner quote includes upgrade testing and out-of-hours support.

Connector development and migration

Connectors for systems outside the documented catalog are written as Java code behind the ConnId framework, so custom connectors are a one-time build cost with recurring maintenance each time a target system changes. Migration from Omada adds one-time work to rebuild connectors, roles and access review processes. Ask a quote to list included connectors, the support status of each, and the migration assumptions it relies on.

What a move from Omada to midPoint involves

The sequence moves identities, connectors and approval processes into midPoint in stages, so each target system is proven in a non-production environment before provisioning is cut over with a rollback path. The result is a documented, tested midPoint configuration that matches what Omada does today.

Inventory the Omada configuration
Export and document what Omada currently governs: identity sources, the population of identities, roles and their assignments, every connected target system, and the access request and review processes that run on top of them. Your team and the DeployOpen team review this inventory together, because the Omada admin console is the record of how each rule behaves today. The step is done when the inventory is signed off by the business owners of each system and each process has a named owner.
Map each connector to a ConnId connector
For every target system in the inventory, identify the matching midPoint connector. midPoint uses the ConnId framework, and its documented connectors include LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID through the Graph API, SCIM2 and SCIMv1. Where no documented connector exists, check the integration catalog for supported, community or experimental options, or plan custom ConnId development. Confirm each mapping against your own target system versions. The step closes with a connector matrix that names the connector, its status and the owner of any gap.
Rebuild the HR source integration
Recreate the authoritative feed that drives joiner, mover and leaver events. Move the HR source mapping, attribute transformations and correlation rules into midPoint resources and synchronization configuration, then test them against a copy of HR data. Check that the same people correlate to the same accounts and that departures trigger the same deprovisioning. The step is complete when a test population produces the expected identity states in midPoint and the differences from Omada are documented and accepted.
Port approval and review workflows
Translate Omada's access request approvals and access certification campaigns into midPoint workflows, approval rules and certification definitions. Confirm which approvers, escalation paths and review scopes carry over, and list any capability Omada provides that you will rebuild differently. Ask your team and DeployOpen to test each workflow with named test users. The step closes when every approval and review path has been walked end to end and the audit trail is confirmed to record the same decisions.
Run parallel provisioning in non-production
Stand up midPoint in a non-production environment connected to test or staging copies of each target system. Run it in parallel with Omada against the same test data, and compare the accounts, entitlements and role assignments each produces. Use this period to tune performance, scheduling and error handling, and to confirm that the operational runbooks cover monitoring, backups and upgrades. The step is done when the differences between the two platforms are reconciled and the test results are approved by the system owners.
Cut over provisioning target by target
Move provisioning one target system at a time instead of switching everything at once. For each system, freeze changes in Omada for the affected population, hand provisioning to midPoint, reconcile accounts and confirm that joiner, mover and leaver events behave as tested. Keep Omada's connector configuration available so the cutover can be reversed. The step is complete when each target has run in production under midPoint for an agreed observation period and its owner has signed off.
Execute and document the rollback plan
Write the rollback plan before the first cutover. It should state the triggers for rollback, who decides, the steps to return provisioning to Omada for each target, and how account states are reconciled afterwards. Test the rollback in non-production at least once. Ask your DeployOpen team and any Evolveum support provider to confirm the plan against your environment. The step closes when the plan is approved, tested and filed with the change records that compliance and audit teams will review.
Confirm the timeline and scope in writing
The effort depends on the number of target systems, the complexity of your roles and the quality of the Omada configuration. No duration is set for this work on this page, so ask for a timeline in the written scope before work starts. Confirm which parts of the inventory, connector work, workflow ports and cutovers are included, what the client team provides, and how parallel running and rollback testing are counted. The detailed migration path is covered on the migration page, which expands each stage above.

Questions buyers ask before choosing midPoint over Omada

How does the cost of running midPoint compare with Omada subscriptions?

midPoint has no license fee, so the comparison is about components rather than a subscription line. Omada costs are a subscription plus implementation work. midPoint costs are infrastructure (application servers, a PostgreSQL database, load balancing for multi-node setups, backups), the engineering time to design and maintain connectors and roles, and an optional Evolveum support subscription. Evolveum offers Product Support with an 8x5 next-business-day or 24x7 SLA, and Platform Subscriptions that add feature development and roadmap influence, but its page lists no prices. Ask Evolveum for a quote for the tier you need, and build a component model for both options using your own connector count and identity volume.

How long does a migration from Omada to midPoint take?

No supplied source gives a duration, so the timeline depends on your own inventory. The main drivers are the number of target systems that need connectors, the quality of your role model and existing access request and review processes, how many authoritative HR sources feed identities, and whether you run Omada and midPoint in parallel before cutover. Connectors that already exist (LDAP, Active Directory, Microsoft Entra ID, SCIM2) are faster to adopt than custom ones built on ConnId. Ask any implementation partner for a fixed-scope plan that lists these items and the acceptance tests for each cutover step.

Can an internal team run midPoint without an outside partner?

Yes, many teams operate midPoint in-house, but it requires people who understand identity governance and Java-based systems. Routine work includes monitoring, patching the platform and Java runtime, managing backups, reviewing role and assignment changes, and maintaining connectors when target systems change their APIs. Evolveum's subscriptions and training are one route to vendor-level expertise. DeployOpen can plan, implement, harden, back up, upgrade and document a midPoint deployment inside your infrastructure, and it offers retainers for ongoing support. Decide early which tasks stay in-house and which you buy as support.

What skills does the team need to operate midPoint?

The team needs Java and PostgreSQL operations skills, plus identity governance knowledge. midPoint recommends Java 25 for version 4.11 and later (Java 21 supported) and Java 21 for version 4.10 and older (Java 17 supported). It uses PostgreSQL as its native repository database, ideally on a separate database server. Operators should also know:

Linux administration, or Docker image deployment
Multi-node setup with a sticky HTTP load balancer, a shared central database and cache invalidation over HTTPS
ConnId connector development and troubleshooting, since connectors are Java code

Confirm current requirements in the midPoint system requirements page before you pick a Java version.

Can midPoint replace Omada if our estate is only on Azure?

midPoint can manage Azure-hosted systems, but you should check the connectors you need. midPoint documents a Microsoft Entra ID connector based on the Graph API, and it also supports Active Directory, LDAP and SCIM2, which cover many Azure-connected targets. Azure-only estates still need a database, a runtime and a hosting plan for midPoint, which can run on Linux virtual machines or Docker in your Azure subscription. Verify each connector's status in the connector catalog, since statuses range from supported to community and experimental, and test your highest-risk target systems first.

Do we need an Evolveum subscription to run midPoint in production?

No, midPoint is open source with no license fee, and the code is published under EUPL-1.2 with Apache 2.0 as a secondary license. Evolveum states that midPoint has no enterprise edition. An Evolveum subscription is optional. Product Support covers resolution of product bugs with an 8x5 next-business-day or 24x7 SLA, and Platform Subscriptions add feature development and roadmap influence. Choose a subscription if your risk model requires a vendor response commitment, or if you need a voice in the roadmap. Ask Evolveum to confirm the current terms in writing.

Does DeployOpen provide independent compliance certification for midPoint?

No, DeployOpen does not issue audit reports, attestations or certifications. It prepares systems, controls and evidence for compliance assessments, such as access review records, provisioning logs, role documentation and change records. Independent auditors and certification bodies perform the assessment and issue any report or certificate. Before the engagement starts, confirm with your auditor which evidence they need, how they want it stored, and the retention period they expect. The written scope should list these deliverables so the evidence matches the assessment.

How DeployOpen helps you evaluate, implement or migrate

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted midPoint inside your own cloud accounts, data centers or air-gapped networks. We start with a written scope that matches your lifecycle, review and connector requirements to what midPoint covers, so you can decide on evidence rather than on vendor claims.

How we scope

Inventory your Omada lifecycle, access request and review processes, and the HR and target systems they touch
Map each Omada capability to midPoint features, connectors or custom work, and mark the gaps explicitly
Agree deliverables, timelines and responsibilities in writing before any work starts, as engagements are fixed-scope

How we build

Deploy midPoint in your environment, with PostgreSQL, the multi-node layout and the Java version your release requires
Build and test ConnId connectors for your target systems, including any connectors you need to develop or customize
Run security testing on the deployment and its integrations, and prepare the configuration and evidence your compliance assessors will ask for

How we hand over

Document the architecture, role model, connector configuration, runbooks and backup and restore procedures
Train your administrators on lifecycle workflows, access reviews and connector operations in your own environment
Support parallel running and cutover checks, with rollback steps written down before provisioning changes go live

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the implementation
Plan midPoint upgrades around the release lifecycle, so your team knows which versions are supported and when
Confirm with Evolveum which support subscription fits your SLA needs, since DeployOpen does not resell Evolveum subscriptions

Omada vs midPoint