SAP IDM to midPoint Migration
SAP Identity Management reaches end of maintenance on December 31, 2027. SAP offers no direct on-premise successor for complex, multi-system identity environments. We Know Identity migrates SAP IDM deployments to midPoint — preserving your SAP integrations while eliminating proprietary platform dependency.
The Situation: SAP IDM End of Maintenance
SAP has confirmed that SAP Identity Management (SAP IDM) 8.0 reaches end of mainstream maintenance on December 31, 2027. A one-time extended maintenance option exists until December 31, 2030, but at significant additional cost and with no feature development.
More significantly, SAP will not deliver a direct on-premise successor for complex identity governance across mixed SAP and non-SAP environments. SAP’s own cloud portfolio — Identity Authentication Service (IAS), Identity Provisioning Service (IPS), Identity Access Governance (IAG), and Identity Directory Service (IDS) — covers SAP cloud application authentication and basic provisioning. It does not replace SAP IDM as a central identity governance platform for organizations with Active Directory, LDAP, HR systems, custom applications, and complex lifecycle automation.
Critical Risks of Remaining on SAP IDM
- No security patches after 2027 — or 2030 if extended maintenance is purchased
- No support for modern SAP cloud products — IAS, BTP, and S/4HANA cloud integrations require updated connector patterns SAP IDM cannot deliver
- SAP-proprietary architecture — SAP IDM’s UME-based store, workflow engine, and connector framework are unique to the product and cannot be migrated incrementally
- Talent scarcity — SAP IDM administrators and developers are increasingly rare as the platform is deprecated
- Growing compliance risk — access reviews, SoD enforcement, and lifecycle automation become harder to evidence as the platform ages
- Extended maintenance cost — the 2030 extension requires a one-time charge that may exceed the cost of migration itself
Why Migrate Now, Not in 2026 or 2027
Industry guidance consistently estimates 24 to 36 months for a structured SAP IDM migration across a complex environment. That means organizations that have not started planning in 2025 or early 2026 are already at risk of a compressed, high-pressure cutover window.
Organizations that migrate now — rather than waiting — gain:
- Runway for proper architecture: a phased migration allows connector-by-connector transition without service disruption
- Time to map IDM workflows properly: SAP IDM’s task-based workflow model differs from midPoint’s policy-based provisioning; re-design requires structured analysis time
- SAP R/3 connector stability: RFC-based SAP connectors require careful testing across your ABAP landscape before full cutover
- Budget control: rushed migrations are always more expensive; phased delivery spreads cost and reduces risk
- Team enablement: your operations team needs time to learn midPoint’s architecture before they own it
SAP’s Alternatives — And Their Limitations
SAP recommends its Cloud Identity portfolio and has partnered with Microsoft to position Microsoft Entra ID as a migration path. Both have genuine use cases, but neither is a complete SAP IDM replacement for organizations managing complex on-premise identity environments.
SAP Cloud Identity (IAS / IPS / IAG)
- Designed for SAP cloud application identity, not multi-system governance
- IPS handles basic provisioning to SAP targets; complex lifecycle logic requires custom scripting
- No built-in access certification or SoD outside SAP IAG’s narrow scope
- Cannot provision to Active Directory, LDAP, or non-SAP line-of-business applications
- Locks identity governance into SAP’s cloud platform commercial model
Microsoft Entra ID (SAP-recommended path)
- Strong for Microsoft ecosystem and SSO; weaker for complex IGA governance workflows
- SAP provisioning via Entra relies on SAP IPS as a middleware layer — complexity remains
- Per-user licensing at enterprise scale adds significant ongoing cost
- Governance features (access reviews, SoD, role engineering) require additional Microsoft IGA licensing
- Replaces SAP vendor dependency with Microsoft vendor dependency
Why midPoint for SAP IDM Migration
midPoint is purpose-built for the class of problem SAP IDM was solving: complex identity lifecycle governance across heterogeneous enterprise systems. It covers SAP and non-SAP targets in a single platform, with no per-user licensing and no dependency on a single vendor’s commercial roadmap.
1. Native SAP Connectors
Evolveum provides a production-grade SAP R/3 connector using RFC/BAPI calls for user account and role provisioning. SuccessFactors is supported via SCIM and OData-based connectors. Both integrate directly into midPoint’s provisioning engine.
2. Full IGA Governance Suite
midPoint includes role engineering, SoD conflict detection, access certification campaigns, approval workflows, and audit-ready reporting — the governance capabilities SAP IDM customers relied on and that SAP’s cloud portfolio does not fully replace.
3. No Per-User Licensing
midPoint is licensed per deployment, not per managed identity. For organizations managing thousands or hundreds of thousands of accounts, this is a fundamental cost advantage over both Microsoft Entra IGA and SaaS-based IGA platforms.
4. HR-Driven Lifecycle Automation
SAP HCM and SuccessFactors are common joiner/mover/leaver event sources in SAP IDM environments. midPoint’s HR integration framework handles these sources natively, with fine-grained lifecycle rules replacing SAP IDM’s task-based provisioning logic.
5. On-Premise and Hybrid Deployment
midPoint deploys on-premise, on Kubernetes, or in a hybrid model. For organizations with data residency requirements, regulatory constraints, or on-premise SAP infrastructure, this flexibility matters — and is not available in SAP’s cloud IGA portfolio.
6. Vendor Independence
Open-source core with commercial support from Evolveum. Your identity platform is not subject to SAP or Microsoft pricing decisions. Configuration, connectors, and governance rules belong to your organization — not locked inside a proprietary platform.
What WKI Handles in an SAP IDM to midPoint Migration
SAP IDM migrations involve more than installing midPoint. The migration requires analysis of existing IDM roles, task flows, connector configurations, and organizational data structures, followed by careful re-implementation in midPoint’s architecture.
SAP Connector Engineering
Configuration and testing of SAP R/3 (RFC/BAPI), SAP SuccessFactors (SCIM/OData), and SAP HCM connectors within midPoint. Attribute mapping, schema extension, account correlation, and entitlement management aligned to your SAP landscape.
Workflow and Policy Re-design
SAP IDM uses task-based provisioning workflows. midPoint uses policy-based provisioning with role-driven mappings. We translate your existing IDM task flows into midPoint’s role model, lifecycle states, and approval workflows — preserving logic without copying legacy design patterns.
Identity Data Migration
Extraction of identity data from SAP IDM’s UME-based identity store, correlation with authoritative HR and directory sources, and import into midPoint with proper account linkage, shadow account mapping, and relationship data integrity.
Non-SAP System Connectors
Most SAP IDM environments also manage Active Directory, LDAP directories, databases, and custom applications. We build or configure midPoint connectors for your full system landscape — not just the SAP targets.
Governance Setup
Role model design, SoD rule implementation, access certification configuration, and audit reporting aligned to your compliance requirements — rebuilding the governance layer your organization depends on, but in a maintainable modern platform.
Parallel Run and Cutover
Phased cutover with parallel operation of SAP IDM and midPoint during transition. Reconciliation checks, data validation, and sign-off gates before each system is decommissioned from IDM scope.
Migration Approach
We structure SAP IDM migrations in four phases, designed to reduce risk, preserve governance continuity, and give your team time to build operational confidence before SAP IDM is decommissioned.
Phase 1 — Discovery and Architecture Design
4–6 weeks
Inventory of all SAP IDM connectors, provisioning tasks, and data flows. Documentation of the existing role model, workflow logic, and organizational rules. Architecture design for midPoint that maps your current IDM logic to midPoint’s native provisioning and governance model. Connector strategy: which systems will use existing midPoint connectors versus requiring custom development.
Phase 2 — midPoint Build and SAP Connector Configuration
8–14 weeks
midPoint deployment on your target infrastructure. SAP R/3 connector configuration: user provisioning, role assignment, and account lifecycle. SuccessFactors or SAP HCM connector configuration for HR-driven joiner/mover/leaver automation. Initial role model implementation based on the architecture design. Core lifecycle rules: onboarding, off-boarding, position changes, and access requests.
Phase 3 — Non-SAP Connectors, Governance, and Testing
6–10 weeks
Build and test connectors for Active Directory, LDAP, databases, and any custom systems currently managed by SAP IDM. Governance layer configuration: SoD rules, access certification, approval workflows. Functional and integration testing across the full connected system landscape. Reconciliation testing: data alignment between midPoint shadow accounts and target systems.
Phase 4 — Parallel Run, Cutover, and Handover
4–8 weeks
Parallel operation of SAP IDM and midPoint on a system-by-system basis. Validation that provisioning events in midPoint produce identical outcomes to the legacy IDM system. Cutover of each system scope when reconciliation confirms accuracy. SAP IDM decommission planning. Operations handover: runbooks, configuration documentation, monitoring setup, and team training.
Frequently Asked Questions
+ How long does a typical SAP IDM to midPoint migration take?
Most complex SAP IDM environments require 6 to 18 months for a complete migration, depending on the number of connected systems, the complexity of existing provisioning logic, and the scope of governance requirements. Industry guidance from Evolveum and SAP partners consistently recommends allowing 24 to 36 months for planning and execution in large enterprises. Smaller deployments with fewer connectors can move faster.
+ Can midPoint handle our SAP R/3 and SuccessFactors integration?
Yes. Evolveum maintains a production-grade SAP R/3 connector that uses RFC/BAPI calls to provision users and roles in SAP R/3, ECC, and S/4HANA. SuccessFactors integration is available via SCIM and OData-based connectors. Both connectors handle account creation, attribute management, role assignment, and account lifecycle operations. WKI has hands-on experience configuring these connectors within complex SAP landscapes.
+ Why not migrate to SAP Cloud Identity Services instead?
SAP Cloud Identity Services (IAS, IPS, IAG) covers authentication and basic provisioning for SAP cloud applications. It cannot replace SAP IDM’s function as a central identity governance platform for mixed SAP and non-SAP environments. Organizations with Active Directory, LDAP, custom applications, and complex joiner/mover/leaver automation will find SAP’s cloud portfolio insufficient for their full identity governance scope. midPoint was designed specifically for this multi-system governance problem.
+ Why not migrate to Microsoft Entra instead?
Microsoft Entra is SAP’s recommended partner for IDM migration, and it is a strong platform for Microsoft-centric environments. However, the SAP provisioning path through Entra still relies on SAP IPS as a middleware layer, so complexity is not eliminated. Entra IGA licensing adds per-user cost at scale. Organizations looking for a vendor-neutral, on-premise-capable, fully open governance platform — without SAP or Microsoft lock-in — find midPoint a more appropriate architectural fit. The right answer depends on your existing environment and strategic direction.
+ What happens to our existing SAP IDM roles and provisioning tasks?
SAP IDM uses a task-based provisioning model with MX scripts and UME-based identity storage that is specific to the platform. These cannot be directly imported into midPoint. The migration involves analyzing your existing tasks and workflows, extracting the underlying business logic, and re-implementing it in midPoint’s policy-based provisioning model. This is design work, not just data migration. WKI conducts a structured discovery phase to document your current IDM logic before any implementation begins.
+ Can we migrate in phases rather than a full cutover?
Yes, and this is the approach WKI recommends. Phased migration moves one system scope at a time from SAP IDM to midPoint, running both platforms in parallel during each transition window. This reduces cutover risk, allows validation of each connector before proceeding, and keeps identity operations stable throughout the project. Full cutover from SAP IDM is the final phase, not the starting point.
+ What about the extended maintenance option until 2030?
SAP offers extended maintenance through December 31, 2030 for an additional one-time charge. This buys time but does not change the fundamental situation: SAP IDM will not receive new features, modern SAP cloud integrations will remain unsupported, and the platform will continue to require scarce specialist skills. Extended maintenance is a risk management option, not a strategic solution. If your organization needs 12 to 18 additional months to execute a proper migration, it may be appropriate — but it should be planned as a migration runway, not a permanent strategy.
+ What does WKI need from our side to start a migration?
A discovery engagement starts with access to your SAP IDM configuration documentation, a system landscape overview, and interviews with your IAM and SAP technical teams. We do not require full system access initially — the first phase is primarily a documentation and architecture review. We provide a structured questionnaire before the first engagement so your team can prepare efficiently.
Start Your SAP IDM Migration Planning
A structured assessment will map your current SAP IDM environment, identify the right midPoint architecture, and produce a realistic migration roadmap with timeline and cost estimates.
For Decision-Makers
SAP Identity Management reaches end of maintenance in December 2027, with no direct on-premise successor for complex multi-system environments. Extended maintenance until 2030 costs more than many migrations. Organizations that start now gain the 24–36 month runway needed for a proper phased transition — avoiding the compressed, high-risk cutover that comes from waiting. We migrate SAP IDM deployments to midPoint while preserving your SAP integrations, eliminating per-user licensing costs, and removing single-vendor dependency.