Is midPoint the right SAP IdM alternative for a mixed SAP and non-SAP estate?
SAP Identity Management fits best when SAP is the center of gravity and the team already runs SAP's stack, while midPoint fits when the identity landscape is mostly non-SAP, when the organization wants an open-source platform with no license fee and source it can read and change, or when the 2027 end of mainstream maintenance is the trigger to consolidate several provisioning tools. Neither answer is settled by the product list alone. The decision turns on three questions: how well each platform covers the SAP systems you actually run, who will operate the platform after go-live, and how much migration work your team can absorb while provisioning keeps running.
Start with SAP connector coverage, because it is the item most likely to change the answer. The ConnId-based connectors documented for midPoint include LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID, SCIM2 and SCIMv1, and the integration catalog lists further connectors with statuses that range from supported to community and experimental. Do not assume an SAP R/3 or SuccessFactors connector exists or is supported. Ask Evolveum in writing for the current status of each SAP module and the SuccessFactors integration you need, and ask whether any gap would be filled by a custom ConnId connector, a SCIM feed or a CSV feed from your HR system. Record each answer against the specific SAP transactions, interfaces and target systems in your inventory.
Then test the operating model. midPoint runs on PostgreSQL, a Java runtime, and either Linux virtual machines or Docker images, and a multi-node deployment needs a sticky HTTP load balancer, a shared database and task scheduling across nodes. If your team has no Java or PostgreSQL operations experience, plan for an implementation partner or a support subscription from Evolveum, and budget for both the recurring platform team and the one-time connector and workflow work. If the SAP connector gap is large, a hybrid approach that keeps SAP IdM for SAP targets during a staged transition may be safer than a single cutover. Confirm that decision before you sign a renewal for SAP IdM, because a short extension can buy the time a parallel run needs.
Which platform fits which scenario
This table matches common SAP IdM situations to the platform that usually fits better, with the condition that makes each advantage matter. Read each row against your own landscape, then confirm SAP connector status and support terms with the vendors before deciding.
| Scenario | Better fit | Why |
|---|---|---|
| SAP-centric estate with little non-SAP provisioning | SAP IdM successor path (confirm with SAP) | If most provisioning targets are SAP systems, SAP's own roadmap and connector support carry more weight than a generic connector framework. Confirm what SAP supports for your release. |
| Mixed SAP, Active Directory, Entra ID and SaaS estate | midPoint | midPoint ships documented connectors for LDAP, Active Directory, Microsoft Entra ID and SCIM2, so one governance model can cover SAP and non-SAP targets. Verify each SAP connector against your release. |
| Strict self-hosting or sovereignty requirement | midPoint | midPoint runs on Linux virtual machines or Docker images inside your own network, with no mandatory cloud service. Cloud-only successors are unsuitable where data must stay on premises. |
| Team with Java and PostgreSQL operations skills | midPoint | midPoint is written in Java and uses PostgreSQL as its native repository, so existing operators can run it without a new stack. Note that the team must also own upgrades and multi-node scheduling. |
| Team wanting a vendor-run SAP roadmap | SAP or Microsoft successor path | If you want the vendor to own SAP-specific features and upgrades, a vendor platform reduces the in-house burden. Ask each vendor which SAP releases and modules their successor covers. |
| Organization needing a commercial support contract either way | midPoint with an Evolveum subscription, or a vendor contract | Evolveum offers Product Support and Platform Subscriptions with 8x5 next-business-day or 24x7 options, so support is available without a license fee. Compare response terms in writing against any vendor contract. |
How the provisioning models differ in practice
The most important difference is how daily work gets done. In SAP Identity Management, provisioning is driven by jobs and mappings that move data between the identity store and target systems, and the team usually thinks in terms of job runs, mapping logic and the status of individual tasks. midPoint works differently: it models identities, roles and assignments as objects, and each target system is reached through a ConnId connector that presents one uniform interface over the target's own protocol. Operators therefore spend less time tracing how a job touched a system and more time checking what an identity should hold and why. Before comparing effort, inventory your own SAP IdM deployment: which jobs, mappings, custom Java or scripts, and SAP and non-SAP target connections are actually in use. The structure of each deployment is different, and the inventory determines how much of the logic maps across directly.
Teams used to SPML-style provisioning jobs often find the first change is conceptual. Requests in SPML are typically operations applied to a target, while midPoint computes the desired state from assignments and then reconciles the target against it. That means a leaver is handled by removing assignments, not by sending a delete request, and the outcome depends on the role model behind it. Plan for a period where operators learn to read midPoint's resource and shadow views, and to use simulations against production data before enabling a change. Confirm in your own environment which SPML operations and custom event handlers your jobs rely on, because each one needs an explicit counterpart in midPoint or a deliberate decision to drop it.
A role model redesign is usually the largest piece of work in this move. Existing SAP IdM roles often grew by accumulating target entitlements, so a direct translation tends to carry duplicates and exceptions into midPoint. Expect to define business roles, application roles and their inducements, decide which assignments are automatic and which need approval, and document the rules that decide them. midPoint's role mining can help find patterns in existing access, but the results still need review by application owners. Ask your SAP and identity teams to agree on who owns each role and how changes are tested, since simulations only prove a change behaves as designed, not that the design is correct.
Capabilities side by side
This table compares SAP Identity Management with midPoint across provisioning, governance, SAP connectivity and licensing. Where our research does not cover an SAP IdM capability, the cell tells you what to confirm with SAP for your licensed release, so use the SAP column as a checklist for your vendor review. Connector status for SAP R/3 and SuccessFactors is the deciding factor for SAP-heavy landscapes.
| Capability | SAP Identity Management | midPoint |
|---|---|---|
| Provisioning, deprovisioning and lifecycle | Confirm with SAP which provisioning protocols and joiner, mover and leaver events your licensed release covers. | Provisioning, deprovisioning and identity lifecycle, driven by ConnId connectors to target systems. |
| Role-based access control | Confirm the role model, role assignment and role maintenance features in your SAP IdM release. | Role-based access control is part of the platform, with roles and assignments managed inside midPoint. |
| Access requests and approvals | Confirm the self-service request and approval workflow features in your SAP IdM release and any custom work they need. | Self-service access requests are included. Confirm approval flow options against the current release documentation. |
| Certification and auditing | Confirm which certification campaign and audit reporting features SAP IdM provides and whether they need add-ons. | Auditing is part of the platform. Confirm certification campaign scope against the current release documentation before relying on it. |
| Password reset and self-service | Confirm password reset and self-service features, including any separate SAP component required. | Self-service password reset is included in the platform. |
| Simulations and role mining | Confirm whether simulation and role mining tools are included in your license or sold separately. | Simulations against production data and role mining are included in the platform. |
| SAP R/3 and SuccessFactors connectivity | Confirm the supported SAP R/3 and SuccessFactors integration paths and the SAP release each one requires. | SAP R/3 is not among the core documented connectors. Confirm SuccessFactors and R/3 connector status and version in the connector catalog. |
| Non-SAP connectors | Confirm the supported non-SAP connector list and whether each connector is licensed separately. | Documented connectors include LDAP, Active Directory, Microsoft Entra ID, SCIM2, CSV and database tables, with more in the catalog. |
| License and support model | Commercial license with maintenance. Confirm fees, extended maintenance terms and end-of-maintenance dates directly with SAP. | No license fee and no enterprise edition. Optional Evolveum support subscriptions offer 8x5 or 24x7 SLA options. |
How SAP R/3 and SuccessFactors connectivity compares
SAP connectivity is the question most likely to decide whether midPoint can take over from SAP IdM. The cards below cover what midPoint offers on the SAP and SuccessFactors side, the fallback feeds when a connector falls short, and the checks you must run before committing to a source of truth.
SAP R/3 coverage on midPoint
midPoint's documented connector list does not name an SAP R/3 connector, so SAP coverage has to be confirmed connector by connector. Ask Evolveum and the integration partner which SAP interfaces are supported, which are community or experimental, and whether they match the SAP release and user administration objects you manage today. Treat any SAP account, role or authorization object you cannot confirm as an open item for the design phase.
SuccessFactors as an HR source
If SAP IdM receives joiner, mover and leaver events from SAP SuccessFactors, midPoint needs an equivalent input. Check whether the community SuccessFactors connector covers the employee data, effective dating and event timing your processes rely on. Confirm who maintains that connector after go-live, because its status is not the same as a supported connector.
CSV or SCIM feed fallback
Where no suitable connector exists, a CSV or SCIM feed can carry the same data. midPoint documents CSV, SCIM2 and SCIMv1 connectors, so an export from an SAP system or an intermediate service can often replace a direct interface. The cost is an extra component to schedule, monitor and reconcile, and the feed format and delete handling must be agreed with the SAP team before testing.
ConnId's Java connector model
midPoint reaches each system through the ConnId framework, where every connector is Java code behind a uniform interface that speaks the target's protocol. This makes connectors inspectable and testable, but it also means a custom SAP connector is a software development task with its own build, test and upgrade cycle. Ask whether the team has Java developers who can maintain that code for the life of the platform.
Testing connector maturity
Connector status ranges from supported to community and experimental, so each connector in scope needs a written status and a test result. Run each one against the SAP release and customization level in use, covering create, update, disable, delete and reconciliation. Keep the results as evidence for the migration plan and for any later audit of provisioning controls.
SAP-side interfaces to confirm
Before choosing connectors, confirm which SAP-side interfaces your environment exposes for user administration, such as the interfaces used by SAP IdM today, and whether they are available, licensed and permitted for an external system. Also confirm which SAP and SuccessFactors API versions are in use, since an interface change can break a connector silently. Record the answers in the inventory that precedes any design work.
Approvals and certification: where each platform stands
SAP IdM routes access requests and approvals through workflows and provisioning logic that many SAP teams have tuned over years of use. The model tends to be strongest where requests follow SAP-centric roles and attribute-driven rules. The exact approval and certification features depend on the SAP IdM release you run, your custom workflows and any add-on components, so confirm them against SAP's documentation for your release before drawing conclusions.
- Request and approval model: Requests usually flow through workflows configured by the SAP IdM team, with approvers defined in the workflow design. Document each step, timeout and escalation path as it works today.
- Who configures it: Specialist SAP IdM administrators make most changes, and SAP consultants are often involved in larger ones. Plan changes as projects with testing, not as routine administration.
- Certification campaigns: Confirm whether periodic reviews are built in or come from a separate governance product, and whether reviewers can act on individual entitlements or only on whole roles.
- Evidence produced: Audit trails of requests, approvals and provisioning actions are the main evidence. Ask which records are retained, where they are stored and how long they can be queried.
Export your current workflow definitions and the results of your last two review cycles before comparing, so the migration baseline reflects what auditors have actually reviewed.
midPoint includes self-service access requests, auditing and role mining among its core capabilities, so request handling, change records and role analysis are part of the base product. Approval routing and certification depth are the areas to examine closely. Confirm both in the documentation for the release you intend to run, since a workflow model that suits one organization may need custom configuration for another. The midPoint releases page lists the supported versions to check against.
- Self-service access requests: Users request roles or resources through the midPoint interface, and each request is tracked with its own status. Confirm that the approver options you need, such as manager, role owner or resource owner, are available.
- Approval configuration: Approval chains are configured by administrators within midPoint's workflow model. Confirm whether your sequential and parallel approvals, delegation during absence and escalation rules can be built without custom code.
- Auditing: midPoint records changes made through the platform. Confirm the event coverage, the storage target and the retention period you need to answer evidence requests.
- Role mining and simulation: Role mining can inform role design before a review, and simulations against production data show the likely effect of a change. Use them to estimate review scope before a campaign launches.
Run one representative approval chain and one certification campaign in a non-production instance, using your own roles, before committing to the design.
Neither column of this comparison replaces a test against your own approval and review rules. Use the same scenarios on both platforms, and record which steps need custom work, who signs off on each design decision and what evidence an assessor would receive at the end. This gives you a fair basis for the decision and for the migration plan that follows.
- Scenario set: Pick a joiner request that needs manager and application owner approval, a sensitive entitlement that needs a second approver, and a delegated approval during an absence.
- Certification scope: Define the reviewers, the review frequency, what happens when a reviewer does not respond, and how exceptions are recorded and approved.
- Evidence package: List the reports, logs and exports an auditor will ask for, and check that each one can be produced without manual reconstruction.
- Customization effort: Count the custom workflow steps or scripts each scenario requires. Ask any implementation partner or vendor to base their estimate on this list.
Keep the scenario results with the migration plan so that approvals and reviews are validated before SAP IdM is switched off.
Where identity data lives and who controls it
Moving from SAP Identity Management to midPoint changes where the identity store, connectors and audit trail run. The cards below cover the hosting choices, the multi-node layout, the boundary between identity management and single sign-on, and what your organization still has to evidence to auditors.
Self-hosted in your own estate
midPoint runs on Linux in a virtual machine or from Docker images, in your own data center or cloud account. That keeps identity records, connector credentials and audit data under your control rather than with a vendor-hosted service. Check which hosting zone, backup location and administrator access model your data residency rules require, and document who holds root access to the application and database hosts.
Shared PostgreSQL repository
midPoint uses PostgreSQL as its native repository, ideally on a separate database server. The repository holds the identity model, roles, assignments and task state, so it becomes the most sensitive component to back up and restore. Confirm your database high availability, encryption at rest and backup retention before go-live, since losing the repository means losing the governance state that SAP IdM currently keeps in its own store.
Multi-node layout and load balancing
Multi-node deployments put several midPoint nodes behind a sticky HTTP load balancer, share one central database, and invalidate caches between nodes over HTTPS. Quartz coordinates distributed task scheduling. Plan the network paths between nodes, the TLS certificates used for cache invalidation, and the failover test you will run before cutover. Each node is part of your attack surface, so include all of them in patching and access reviews.
Identity management, not single sign-on
midPoint 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, although its own user interface can authenticate against an external SSO service. Where SAP IdM currently sits alongside your SSO stack, keep the authentication and token issuance design with your identity provider and decide explicitly which system is the source of truth for each application login.
Audit evidence you still produce
midPoint provides auditing of provisioning and governance changes, but an audit still needs evidence of how controls operate. Your organization must define the control owners, access review cadence, approval rules and retention periods, then export logs and reports from midPoint and the connected systems. Independent auditors assess the result. DeployOpen can prepare the systems, controls and evidence for that assessment, but does not issue audit reports or certifications.
Ownership of operations after go-live
A self-hosted midPoint deployment needs named owners for patching the Java runtime, PostgreSQL, the midPoint releases and each connector. Confirm which release line you will run and its support end date, and whether you will buy a Evolveum support subscription or rely on an internal or partner team. Write these responsibilities into the operating model before cutover, so that governance evidence keeps being produced after the SAP IdM contract ends.
What each option costs to own over time
The cost of SAP Identity Management is mostly recurring and sits outside the product itself. Ask your SAP account team for the current maintenance or license terms in writing, including what extended support covers after mainstream maintenance ends, because that line drives the renewal math. Add the SAP-side services you consume every year (basis administration, transport and patch cycles, consulting on the Identity Center and its connectors), and the connector costs for SAP and non-SAP targets. Most of these are paid to SAP or a partner, and each new target system tends to add another connector line. The one-time costs are the migration itself: the inventory, the role model rework, and parallel running while both systems provision.
midPoint carries no license fee, so the recurring costs shift to infrastructure and people. Servers or virtual machines, a separate PostgreSQL server (midPoint recommends running the database on its own host), backups, and a platform team that patches Java and midPoint, runs upgrades and owns the connectors all recur. Evolveum offers Product Support subscriptions for product bugs, with an 8x5 next-business-day or 24x7 SLA, and Platform Subscriptions that add feature development and roadmap influence. Its support subscriptions page lists no prices, so request them in writing. Implementation work (HR source mapping, connector builds, approval and certification design) is a one-time cost, whether delivered by your staff, Evolveum, or a partner such as DeployOpen under a fixed-scope agreement.
Several factors move both totals. On the SAP side, the number of target systems, the count of SAP connectors in use and how many custom approval flows you rely on drive cost upward. On the midPoint side, connector maturity matters: documented connectors such as LDAP, Active Directory and Microsoft Entra ID are less work than community or experimental connectors from the integration catalog, so check each target's status before you price it. Ask any quote to separate one-time migration effort from annual run cost, to state which connectors are supported versus community, to list the Java and PostgreSQL versions it assumes, to show who carries upgrade testing, and to name the support tier included. Run the same target list through both quotes so the comparison is like for like.
What a move from SAP IdM to midPoint involves
The sequence below takes SAP IdM from inventory to decommissioning while provisioning keeps running, with a checkpoint at each stage so nothing changes ownership before it is tested.
Inventory SAP IdM jobs, sources, targets and approvals
The identity team, with the SAP IdM administrators, lists every job, HR or other authoritative source, target system, attribute mapping, scheduled task and approval workflow currently in production. Owners of each target system confirm what accounts they expect to receive and which ones are manual today. The inventory is done when every SAP IdM job maps to a named owner and a documented target, and when there is a list of workflows that approvers actually use, including those that exist only as custom code.
Confirm connector coverage on the midPoint side
For each target in the inventory, the platform team checks whether midPoint has a supported, community or experimental ConnId connector, or whether a CSV, SCIM or database feed is a realistic path. SAP-specific targets need particular attention, because connector status varies by system and version and must be confirmed with Evolveum and tested in your own environment. Output: a coverage table that marks each target as supported, community, custom build or open question, with the person accountable for resolving each open item.
Design the role model and approval flows
Business owners and the IGA team translate the existing SAP IdM roles and approval paths into midPoint roles, assignments, policies and approval workflows. This is where most rework happens, because SAP IdM roles often carry history that no longer matches how people work. midPoint's role mining and simulation features can help test candidate roles against production data before anyone relies on them. The step closes when each role has an owner, an entitlement list and an approval rule that the business has signed off in writing.
Build a parallel environment and test joiner, mover and leaver flows
The platform team installs midPoint in a separate environment, typically on Linux or from Docker images with PostgreSQL as the repository, and connects it to non-production copies of sources and targets. Test cases cover joiners, movers and leavers, including edge cases such as rehires, leave of absence and terminations with pending access. midPoint runs in simulation or against test targets while SAP IdM continues to manage production. The check is a reconciled test report showing that midPoint produces the same account state as SAP IdM for the agreed scenarios.
Cut over the source of truth in controlled waves
Teams move target systems one group at a time from SAP IdM to midPoint, starting with lower-risk systems. For each wave, provisioning ownership switches on a defined date, the previous job is disabled rather than deleted, and reconciliation runs confirm that accounts match expected state. Rollback steps are written and rehearsed before each wave. Authoritative HR data continues to feed both systems during the overlap so that no account is left without a source. The wave is complete when its reconciliation report is clean and the SAP IdM job for that target is inactive.
Run in parallel, then decommission SAP IdM
After the final wave, SAP IdM stays available in read-only or standby mode for a parallel run agreed with the audit and compliance owners, so that historical records and recertification evidence can be compared. Teams archive SAP IdM configuration, job logs, role definitions and approval history according to retention rules, then shut down its servers and database. Decommissioning should be scheduled well before SAP's end of mainstream maintenance for SAP IdM, which is in 2027. The step closes with a signed decommission record and an archived evidence set.
What buyers ask before choosing midPoint over SAP IdM
How much effort and time does a move from SAP IdM to midPoint take?
The effort depends on the size of the identity landscape, not on a fixed formula. The main drivers are the number of target systems, how many of them need a new or customized ConnId connector, how many roles and approval workflows must be rebuilt or simplified, how clean the HR source data is, and how many systems must run in parallel during cutover. Each of these should be sized from your own inventory before anyone agrees on a schedule. Ask any provider for a written scope that lists each connector, workflow and data source, with the deliverables and timeline tied to that list. Because SAP IdM support ends in 2027, the timeline also depends on when you start.
Can our own team migrate to midPoint without an outside partner?
A capable team can do it, but it needs the right skills in place. midPoint is written in Java, uses PostgreSQL as its native repository database, and is configured through XML objects, so engineers should be comfortable with Java build and runtime tooling, database administration and backup, and Linux operations. Identity design is the harder skill: role models, access policies, approval logic and reconciliation rules must be designed deliberately, not copied from SAP IdM. Many teams split the work, keeping the identity design in-house and bringing in outside help for connector work, performance tuning or cutover planning. Assess those skills honestly before deciding.
What does the migration need from our side?
The work needs time and access from people who know your systems. Expect to provide a complete inventory of SAP IdM jobs, mappings, roles and workflows, documented HR source rules, admin access to the target systems and test accounts, and named owners who can approve role definitions and sign off on test results. Security and compliance staff should agree early which controls and evidence you need, because midPoint's auditing and certification features must be configured to match them. Clear ownership on your side is often the factor that most affects the schedule.
Do we need a midPoint support subscription?
No. midPoint has no license fee and no enterprise edition, so the software itself is free under its EUPL and Apache 2.0 licenses. Evolveum offers optional subscriptions: Product Support for resolving product bugs, with an 8x5 next-business-day or 24x7 SLA, and Platform Subscriptions that add feature development and roadmap influence. The page lists no prices, so request a quote for the level you need. Many organizations choose a support subscription for production assurance, while others rely on internal staff and community resources. Your decision should reflect how much in-house capacity you have and how critical identity services are to your operations.
Does midPoint connect to SAP systems out of the box?
Not in the same way SAP IdM does. midPoint connects to target systems through ConnId connectors, and the documented connector list includes LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID, SCIM2 and SCIMv1, plus an integration catalog whose status ranges from supported to community and experimental. Before committing, confirm the current status of the SAP R/3 and SuccessFactors connectors with Evolveum, and test them against your SAP release, authorization model and transport landscape. Where a connector is missing or immature, budget for building or hardening one, or for an intermediary that exposes SAP through SCIM or CSV.
When is staying with SAP IdM the better answer?
Staying is the better answer when your identity landscape is almost entirely SAP, your SAP IdM connectors and workflows work reliably, and your team already runs SAP IdM well. It may also be right if your internal capacity for Java, PostgreSQL and identity engineering is low and you cannot add it, or if a contractual or policy requirement favors a single SAP-supported path. Check SAP's published maintenance dates for your release before deciding, because mainstream maintenance for SAP IdM ends in 2027. If you do stay for now, plan the successor in parallel so the decision is not forced by a support deadline.
How DeployOpen helps you decide and move
DeployOpen works from a written scope for SAP Identity Management vs midPoint, so the decision and the migration plan rest on your own systems, data and approval rules. We plan, implement, integrate, document and support midPoint inside your own infrastructure, including the SAP and non-SAP connections your landscape needs.
How we scope
- Inventory SAP and non-SAP target systems, HR sources and the provisioning paths each one uses today
- Map current approval workflows, role models and certification campaigns against midPoint's capabilities and open gaps
- Agree deliverables, timelines and responsibilities in writing before any work starts, since most engagements are fixed-scope
How we build
- Deploy midPoint in your own cloud accounts, data center or air-gapped network, with PostgreSQL and the chosen Java runtime
- Build or adapt ConnId connectors for SAP and other targets, and test each one against non-production systems first
- Configure roles, approvals, certification and audit logging, then run simulations against representative data before cutover
How we hand over
- Document architecture, connector configuration, role and approval design, and the runbooks your operations team will use
- Run knowledge transfer sessions with the people who will operate midPoint after the engagement ends
- Provide backup, upgrade and parallel-run procedures so provisioning continues while you decommission the existing system
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Plan midPoint upgrades against the published release and support dates your team confirms with Evolveum
- Coordinate with your own auditors on the evidence your compliance assessment will request, since DeployOpen does not issue attestations
