Migrating from SAP IdM to midPoint: what the work involves
The move from SAP Identity Management to midPoint is a re-platforming of connectors, workflows and role models, not a copy of data. SAP IdM stores its identity data in its own repository and runs provisioning logic through jobs, maps and SPML-based interfaces. midPoint rebuilds that behavior from its own object model: users, roles, organizations, resources and synchronization and provisioning expressions. Your team should expect to redesign each target connection and each approval flow, then validate them against the accounts already in the target systems. Usually an internal platform or IAM team carries this work, supported by an implementation partner for the midPoint design, the connectors and the cutover plan. Confirm early which person owns each SAP IdM job and role, because those owners hold the knowledge that does not appear in the configuration export.
Licensing is the simplest part of the comparison. midPoint is open source under the EUPL-1.2 with Apache 2.0 as a secondary license, and Evolveum states it has no enterprise edition, so there is no license fee to pay. Evolveum sells optional subscriptions: Product Support, with an 8x5 next-business-day or 24x7 SLA, and Platform Subscriptions that add feature development and roadmap influence. Those prices are not published on the subscription page, so ask Evolveum for a written quote. The recurring costs you should budget for are the subscription if you choose one, the servers and PostgreSQL database, and the staff or partner time that runs the platform after go-live. The effort itself depends mainly on two drivers: the number of target systems you must reconnect and the amount of custom SPML logic that has to be rewritten. Inventory both before you request an estimate, and ask any partner to price the work per connector and per workflow, with a fixed scope agreed in writing.
Which SAP IdM capabilities map to midPoint, and which need rework
This table maps the main SAP IdM capabilities to their midPoint equivalents and marks each as a clean fit, a rework item or a gap. Read the status column first, then the notes, to see where migration effort will concentrate. Items marked to confirm depend on connector status that should be checked in the current catalog before scoping.
| Capability | midPoint equivalent | Status and notes |
|---|---|---|
| Provisioning and deprovisioning | Resource-driven provisioning through ConnId connectors, with mappings and sync to target accounts | Clean fit for systems with a supported connector. Rework needed for custom SAP IdM connectors or scripts. |
| Identity lifecycle (joiner, mover, leaver) | Object lifecycle driven by HR or other source resources, with assignments recalculated on change | Clean fit once the HR source is mapped. Rework needed to re-express SAP IdM event rules as midPoint mappings and policies. |
| Role-based access control | Roles, assignments and policy rules, with role mining and simulations to test changes | Clean fit for the role model concept. Rework needed to rebuild role definitions and entitlement mappings from the SAP IdM model. |
| SPML-based provisioning | No SPML interface; provisioning goes through ConnId connectors or SCIM2 endpoints | Rework required. Each SPML integration must be re-implemented as a connector or SCIM feed and tested against the target. |
| SAP R/3 target connector | Connector status to confirm in the Evolveum connector catalog for your SAP release and interface | To confirm. Do not assume coverage; check the catalog and plan a proof of concept against your SAP landscape. |
| SuccessFactors source and target | Community SuccessFactors connector or CSV or SCIM feed, status to confirm in the catalog | To confirm. Test joiner and leaver scenarios before switching the source of truth. |
| Auditing and reporting | Audit records of changes and access, with reports to be configured for your evidence needs | Partial fit. Confirm which audit events and retention your assessors expect, then build the reports. |
| Self-service requests and password reset | Self-service access requests and password reset are part of midPoint's feature set | Clean fit at the feature level. Rework needed for approval workflows and any custom portal screens. |
What moves cleanly and what does not in an SAP IdM exit
The portable material in an SAP IdM exit is the identity data, the business meaning of your roles and the audit obligations, while the executable logic is rebuilt. Identity data extracts from the SAP IdM repository can be loaded into midPoint as the starting population, but they need reconciliation against the authoritative HR source before anything is provisioned. Role definitions can move as documented business intent: write down each role's entitlements, its approvers and the systems it touches, then model it as a midPoint role with its own assignments. Target account mappings, meaning which attribute of the HR record becomes which account attribute in each system, are also worth carrying over, because they are the decisions your auditors will ask about. Audit requirements carry over as requirements, not as code: confirm which events, retention periods and reports your assessors expect, then check that midPoint's auditing covers each one.
What does not move is the custom logic. SPML-based provisioning flows, scripts written against SAP IdM's own interfaces, approval workflows built in its task model, and job schedules built around its scheduler are all tied to that product and must be redesigned. Approval steps should be rebuilt as midPoint approval processes and tested with the same escalation paths your current approvers rely on. SAP-side connectors cannot be reused as-is either. Confirm with Evolveum and with your SAP integrator which SAP target connectors you need, since connector status varies, and plan for the work that remains.
Because midPoint reaches every system through a ConnId connector, each target system needs a connector check before cutover. For each system, confirm the connector exists and its status in the Evolveum connector catalog, test read, create, update and delete against a non-production instance, and verify the account attributes and group memberships your mappings expect. Where a connector is community or experimental, decide whether to accept that risk, build or maintain it yourself, or keep that system on a bridge until a supported path exists. Run these checks early, because a missing connector discovered during cutover can stall the whole migration.
Which data and integrations to move and rebuild
A SAP IdM replacement is mostly a set of data feeds and connectors, not one product switch. Each component below needs its source of truth, its midPoint connector and its export path settled before cutover. Confirm each connector's status in the midPoint connector catalog for your target versions.
HR source feed
SAP IdM usually receives joiner, mover and leaver events from an HR system. In midPoint, that feed can arrive as a CSV export, a SCIM2 endpoint or the community SuccessFactors connector, so confirm which one your HR team can operate. Test how each feed handles rehires, contractors and retroactive changes before you move the source of truth. Ask HR to export a full sample file so you can compare record counts with what SAP IdM currently holds.
SAP target systems
SAP R/3 and SuccessFactors connector status is the first thing to confirm, because it decides whether midPoint can provision SAP accounts directly or whether you need an intermediate file or API. Document every SAP role, authorization object and user type that SAP IdM currently maintains. Plan a test tenant or sandbox system for each SAP target before any production write.
Non-SAP directories
LDAP, Active Directory and Microsoft Entra ID (via the Graph API) are documented midPoint connectors and usually carry the widest group membership load. Map which attributes SAP IdM writes to each directory, including group nesting and naming rules. Confirm how your Entra ID tenant authenticates the connector and which Graph permissions it needs before the first sync.
Database targets
Applications that read access data from a database rely on the DatabaseTable and ScriptedSQL connectors. DatabaseTable covers simple table-based provisioning, while ScriptedSQL suits logic that needs custom SQL. Inventory which tables SAP IdM updates today and who owns their schema. Agree on a rollback statement for each table so a failed run can be reversed.
CSV and SCIM targets
Applications without a native connector can receive accounts through CSV files or a SCIM2 endpoint, and midPoint documents both paths. CSV suits batch handoffs to legacy tools, while SCIM2 suits modern applications that already expose a provisioning API. Confirm the target's SCIM version and whether it supports soft deletes, because the leaver behavior depends on it. Keep file exports under access control and with a retention rule.
Audit and reporting outputs
Compliance teams often rely on SAP IdM reports for access reviews and evidence. midPoint records audit events and supports simulations and reporting, but the report layouts your auditors expect must be rebuilt and checked. List each report, its recipients and its frequency, then compare sample output from both systems for one full review cycle. Whether a given report can be produced without custom work is something to confirm during the pilot.
The migration sequence from inventory to decommission
This sequence moves identity processing from SAP IdM to midPoint in controlled stages, so each population and target system is proven before the authoritative source changes. Each step produces a written artifact that gates the next one, and the final decommission only happens after SAP IdM is no longer needed for rollback or audit evidence.
Inventory SAP IdM jobs, connectors and roles
Catalog every SAP IdM job, scheduled task, connector, workflow, approval step, role and assignment rule, along with the target systems each one touches and the owner of each. Include the attributes mapped from the HR source, the mappings used for SAP and non-SAP targets, and any custom code. The output is an inventory register that assigns each item a disposition: rebuild in midPoint, replace with a different connector, retire, or keep out of scope. Confirm the list with the business owners and the SAP IdM administrators before moving on.
Model roles and connectors in a midPoint test environment
Build the midPoint environment in a non-production setting, sized using the midPoint system requirements for the chosen Java and PostgreSQL versions. Recreate the role model and resource definitions for the pilot targets, and confirm connector status in the Evolveum connector catalog for each system, including whether a SAP or SuccessFactors connector is supported, community or experimental. Use midPoint simulations against a copy of production data to compare the expected assignments with what SAP IdM currently grants. The output is a validated role model and a connector status list with any gaps flagged.
Pilot one HR population on two target systems
Choose one bounded HR population, such as a single business unit, and one or two target systems that have clear owners and reliable test accounts. Run joiner, mover and leaver events for that population in midPoint while SAP IdM stays authoritative, and compare each provisioned account with the one SAP IdM would create. Test approvals and access requests the same way. The output is a pilot report listing every difference, its root cause, and the fix, with a sign-off from the application owners.
Run both systems in parallel with reconciliation
Extend the scope to the remaining populations and targets while both systems run. Schedule reconciliation jobs in midPoint and compare its account and entitlement state with SAP IdM and with the target systems, both on a regular basis and after each change. Classify each mismatch as a role model defect, a connector defect, a data quality issue in the HR source, or an expected difference, and track it to closure. The output is a set of reconciliation results showing the open and closed exceptions, and the parallel run ends only when the owners accept the remaining differences in writing.
Write and rehearse the cutover runbook
Prepare a cutover runbook that names the authoritative source switch, the freeze window for changes to HR data and roles, the order in which target systems are moved, the rollback criteria, and the person who decides on rollback. Rehearse the runbook in the test environment, including a deliberate failure of the HR feed and of one connector. Confirm the backup and restore procedure for the midPoint database and for the SAP IdM data you must keep. The output is a signed cutover runbook with a tested rollback path.
Execute the controlled cutover of the authoritative source
Freeze changes, take a verified backup of both systems, and move the authoritative source for each population from SAP IdM to midPoint in the order set in the runbook. Run an immediate reconciliation after each population moves, and confirm that SAP IdM no longer issues changes for the cut-over population. Monitor the first full cycle of joiner, mover and leaver events closely with the operations team. The output is a cutover record with timestamps, reconciliation results before and after each move, and any rollback decisions taken.
Decommission SAP IdM after the retention period
Once midPoint has run the full cycle for every population and the rollback window has closed, shut down SAP IdM connectors and jobs, then retire the system according to the support timeline your organization has agreed with SAP. Confirm with your compliance team which audit logs, approval records and historical assignments must be exported and retained, and where they will be stored. Check the SAP maintenance dates for your contract, and do not disable SAP IdM before the retention plan is approved. The output is a decommission record listing what was shut down, where the archived evidence sits, and who approved the closure.
How the migration changes with the starting estate
When most provisioned targets are SAP systems, the work centers on SAP role and authorization data rather than on generic account creation. Existing SAP IdM jobs often push user, role and position data into several SAP landscapes, and the migration has to reproduce those mappings in midPoint before any target is switched. Confirm early which SAP connector path you will use for each landscape, because connector status for SAP R/3 and SuccessFactors is a deciding factor and must be verified against the current midPoint connector documentation rather than assumed.
- Dominant scenarios: joiner, mover and leaver for SAP user accounts, role assignment mapped from SAP IdM roles, and periodic reconciliation of SAP authorizations.
- Connectors to confirm: the SAP R/3 and SuccessFactors connector status in your midPoint version, plus any SAP Business Warehouse or GRC integration you depend on.
- Role model porting: SAP IdM role and parameter logic usually needs a rebuilt role model in midPoint, so plan a review of role definitions with the SAP authorization owners.
- Parallel run: keep SAP IdM as the source of truth for SAP targets while midPoint computes the same changes in simulation, and compare the two outputs per landscape.
- Cutover order: switch the smallest SAP landscape first and keep a rollback path to SAP IdM until the reconciliation results match for a full cycle.
Before committing, confirm the connector version, the SAP transport and authorization requirements, and who in your SAP team will own the role content after cutover.
Many organizations run SAP next to Active Directory or LDAP, and in that case the directory is often the most important target and the SAP connections are a subset of the work. Account lifecycle in the directory, group membership and the link between directory identities and SAP users tend to dominate the first phase. The main design question is which system owns each attribute, because two provisioning engines writing to the same directory object during a parallel run produce conflicts that look like random drift.
- Dominant scenarios: directory account creation and group membership, joiner and leaver flows that touch both directory and SAP, and attribute synchronization for contact and manager data.
- Connectors to confirm: the Active Directory and LDAP connector behavior against your domain and OU layout, and the SAP connector status for each SAP target.
- Attribute ownership: document, per attribute, whether SAP IdM or midPoint is the writer during the parallel period.
- Parallel run: run midPoint in read and simulation mode against the directory first, then move write rights one target at a time.
- Reconciliation: schedule reconciliation runs on both sides and review drift reports before each handover.
Before starting, confirm the directory service accounts midPoint will use, the write permissions and any password synchronization requirements, since these vary by environment.
A smaller estate with few target systems and light approval logic can often be migrated in a shorter, more linear sequence. The effort is less about connector breadth and more about making sure the few existing workflows and role rules are documented, because a small team may have no current specification of them. Without documentation, the parallel run becomes the specification, and that is slow. Writing down the existing behavior before any build work begins is usually the highest-value early step.
- Dominant scenarios: basic joiner, mover and leaver processing, a small number of approval flows and a limited role set.
- Connectors to confirm: only the targets you actually use, checked against the connector catalog for supported status and any licensing or maintenance terms.
- Documentation first: export and describe every SAP IdM workflow and role rule, even ones that seem unused.
- Parallel run: can be shorter in calendar terms, but still needs at least one full reconciliation cycle and one leaver test per target.
- Operating model: decide early who runs midPoint after cutover, since a small team may have no one who maintains the platform day to day.
Illustrative example: a company with two target systems and three approval flows may reach cutover with a single project team, but the cost of an unclear operating owner after cutover is often higher than the build cost itself. Confirm the staffing and support model before the cutover date is set.
What drives migration cost and duration, and how to hold it down
This table lists the main drivers of effort when moving from SAP Identity Management to midPoint, why each one moves the work, and how to keep it under control. Read it before scoping, since most of the effort sits in a few drivers that the project team can influence early.
| Driver | Why it moves effort | How to hold it down |
|---|---|---|
| Number of target systems | Each target needs a connector, mapping, test cases and a cutover step. Non-SAP targets without a supported ConnId connector add custom build work. | Inventory every target first, then rank by business criticality. Migrate the high-value targets first and retire low-use ones instead of porting them. |
| Custom SPML and workflow logic | Provisioning logic written against SPML or custom SAP IdM workflows must be re-expressed in midPoint objects, mappings and approval logic. Undocumented logic is the most common source of rework. | Export and document existing workflows and scripts before design. Remove steps nobody uses and rebuild the rest as midPoint policies, not line-by-line ports. |
| Role model complexity | Large numbers of overlapping roles, or roles assigned by hand, need analysis before they can be mapped. midPoint's role mining and simulation features help, but someone must still review the results. | Clean up roles and owners in the source system before migration. Use midPoint simulations against production-like data to check changes before they go live. |
| HR source quality | Inconsistent employee IDs, missing manager relationships or delayed joiner and leaver data cause mismatched accounts and manual correction during parallel running. | Agree the authoritative source and key attributes with HR early. Clean duplicates and test joiner, mover and leaver events on sample data before switching the source of truth. |
| Parallel-run length | Running SAP IdM and midPoint side by side doubles operation of provisioning and reconciliation, and extends the time both systems need support. | Define exit criteria per target system, such as reconciliation results and approval outcomes matching. Ask the implementer to state how long parallel running is planned, and why. |
| Connector gaps needing custom work | midPoint's connector catalog includes supported, community and experimental connectors. Gaps for SAP-specific or older targets may need custom ConnId connectors built and maintained in-house or by a partner. | Check each target's connector status in the Evolveum connector catalog during discovery. Prefer targets with supported connectors, and price custom connector work as a separate, scoped item. |
| Skills in Java, PostgreSQL and midPoint | Connector development requires Java, and the midPoint repository and PostgreSQL need administration. Teams without these skills depend on vendors or hire for them, which adds cost and key-person risk. | Confirm which skills exist internally before choosing a delivery model. Ask for knowledge transfer, runbooks and documented configuration as part of the written scope. |
What usually goes wrong and how to prevent it
Most failed SAP IdM to midPoint migrations fail at the seams: the moment provisioning changes hands, the approval logic that nobody wrote down, and the role definitions that drift while two systems run side by side. The cards below name six recurring risks and a concrete check for each, so cutover decisions rest on evidence rather than assumptions.
Provisioning gaps during cutover
Each SAP IdM job, sync rule and outbound feed must have a named owner in midPoint before the switch. A gap appears when a target system is still fed by SAP IdM but midPoint has no equivalent resource, so joiners receive no access or leavers keep it. Build a written inventory of every provisioning path, mark each one as moved, parallel or retired, and test a leaver case against every target before you stop the old feed. Map every outbound path before cutover.
Unmapped approval workflows
SAP IdM approval steps often live in configuration that teams no longer read. If those steps are not exported and reviewed, midPoint will grant access that the old process would have blocked, or block requests that were routine. Export the approval rules and escalation paths from SAP IdM, write each one as a midPoint approval case with an expected outcome, and walk business owners through the test results. Treat undocumented approvals as missing requirements.
Role model drift between systems
While both systems run in parallel, roles get changed in one place and not the other, so the two models quietly diverge. Auditors then see different entitlements for the same person depending on which system they query. Freeze role changes during the parallel period or route them through one approved change process, and compare effective access per identity on a fixed sample each week. Run a standing role comparison during parallel operation.
Connector status misread as production-ready
midPoint's connector catalog ranges from supported to community and experimental connectors, and the status determines how much support and testing you can rely on. A connector that works in a lab may lack the behavior your production target needs, such as particular attribute mappings or error handling. Check the status of every connector you depend on in the connector documentation, confirm which ones your support level covers, and test each against a non-production copy of the target before go-live. Verify each connector's status before you plan around it.
Orphaned accounts after decommission
When SAP IdM is switched off, accounts it created may remain in target systems with no owner that midPoint recognizes. These orphans keep working and fall outside the access reviews that now run in midPoint. Before shutdown, reconcile target accounts against identity records, decide how each unmatched account is disabled, archived or assigned, and keep a dated record of that decision. Reconcile every target system before shutting SAP IdM down.
PostgreSQL and Java version mismatch
midPoint's system requirements recommend Java 25 for version 4.11 and later, Java 21 for 4.10 and older, and PostgreSQL as the native repository database, ideally on a separate server. Running an unsupported Java or database version, or a version chosen to match an existing SAP database standard, can cause failures that look like provisioning errors. Select the midPoint release first, then pin the Java and PostgreSQL versions its requirements page lists, and confirm the support window for that release. Choose the midPoint release before choosing the runtime stack.
Questions teams ask before migrating from SAP IdM to midPoint
What does a migration from SAP IdM to midPoint cost?
The software license is not the main cost. midPoint is open source with no license fees, so the cost is the work and infrastructure around it: migration services, connector work for SAP and non-SAP targets, servers, PostgreSQL, testing, and the team that operates the platform afterwards. Optional Evolveum support subscriptions are a separate recurring cost, and the Evolveum support subscriptions page lists no prices, so request a quote for them. Current SAP IdM costs (maintenance or a replacement license) are the other side of the comparison. The largest drivers are the number of target systems, how many approval workflows and role models must be ported, and how much of the SAP landscape needs new connectors. Ask every bidder for a fixed-scope quote that itemizes these components.
How long does it take to move from SAP IdM to midPoint?
The duration depends on scope, not on a fixed template. The main variables are the number of HR and target sources, how many SAP and non-SAP systems need connectors, the volume of approval workflows and role definitions to rebuild, and how much parallel running your change process requires. Because SAP has announced the end of mainstream maintenance for SAP IdM in 2027, plan backwards from that date and have the inventory done early. Ask for a written timeline with milestones for each scenario, including the parallel-run period and the decommissioning step. Any duration a vendor gives should be tied to the inventory you provide.
What does our internal team need to provide during the migration?
An external implementer cannot finish the migration without good inputs from your own organization. Expect to provide:
- Access to the authoritative HR source and a named owner for joiner, mover and leaver rules
- Exports or documentation of SAP IdM jobs, workflows, roles and approval rules
- Accounts, service credentials and test tenants for each target system
- Decision makers who approve role models and certification scope
- Operations staff who will run PostgreSQL, the midPoint nodes and the upgrade cycle after handover
The more complete this inventory is at the start, the more accurately a fixed-scope quote can be written.
Can we migrate from SAP IdM to midPoint without an outside partner?
Yes, it is possible in principle, because midPoint is open source and its source code, documentation and connectors are public. Whether it is practical depends on your team's experience with Java applications, identity data models, ConnId connectors and PostgreSQL, and on how many SAP-specific processes you must recreate. Evolveum funds development through subscriptions, training and professional services, so training and consulting are also available from the vendor. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure under a written scope, which can cover some or all of this work while your team builds skills.
Does midPoint have connectors for SAP systems?
midPoint connects to targets through the ConnId framework, and its documented connectors include LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID (Graph API), SCIM2 and SCIMv1. The Evolveum connectors documentation also lists an integration catalog whose status ranges from supported to community and experimental. Confirm in that catalog whether a connector for the specific SAP module you run (for example, SAP R/3 or SuccessFactors) is supported, community or experimental, and which version it targets. Where no suitable connector exists, the usual options are a ConnId connector built for your system, a SCIM feed, or a CSV or database interface, each of which carries its own development and testing effort.
How do midPoint support subscriptions differ from a product license?
midPoint itself carries no license fee because it is dual-licensed under EUPL-1.2 and Apache 2.0 and has no enterprise edition. Evolveum's support subscriptions are a separate, optional, recurring commercial agreement. Its Product Support tier covers resolving product bugs with an 8x5 next-business-day or 24x7 SLA, and its Platform Subscriptions add feature development and roadmap influence. Evolveum's support page lists no prices, so you should request the terms in writing. Unlike a product license, you can run midPoint without a subscription, but you then carry the responsibility for fixes and upgrades, either in-house or through a service provider.
How DeployOpen scopes and runs an SAP IdM to midPoint migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For an SAP Identity Management move to midPoint, we start from a written scope that names each source, target and workflow, then run the migration in stages so provisioning keeps working throughout.
How we scope
- Inventory every SAP IdM connector, job, workflow and role that is in use today, with owners for each.
- Agree in writing which HR source, SAP and non-SAP targets, and approval flows move to midPoint in this engagement.
- Define acceptance tests and the parallel-run period before any build work starts, since engagements are fixed-scope.
How we build
- Configure midPoint resources on ConnId connectors and confirm each SAP and non-SAP connector status before relying on it.
- Port role models and approval logic into midPoint, then compare results against SAP IdM outputs in a test environment.
- Run both systems side by side on non-production data, and document every difference found before cutover.
How we hand over
- Deliver architecture, configuration, runbooks and decommissioning steps for SAP IdM in your own documentation set.
- Walk your operations and security teams through midPoint administration, backup and upgrade procedures.
- Prepare control evidence for your internal auditors or independent assessors, who issue any formal attestation.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan midPoint upgrades against the published release support dates, so your team knows when each version reaches end of support.
- Confirm with Evolveum which support subscription, if any, your team wants alongside DeployOpen's services.
