What the SAP Identity Management end of maintenance means for your provisioning
Plan the successor and the staged cutover now, and choose between Microsoft Entra ID Governance, a self-hosted midPoint or another IGA product based on your sovereignty requirements and the operating model you can sustain after go-live. SAP ends mainstream maintenance for SAP Identity Management in 2027 and points customers toward Microsoft Entra, so the decision is no longer about whether to move but about where the joiner, mover and leaver logic, the approval workflows and the audit evidence will live afterwards. DeployOpen plans and implements the migration, but the choice of vendor stays with your organization.
Start with an inventory of what SAP IdM actually does today. List every HR or authoritative source feeding it, every target system it provisions to (SAP and non-SAP alike), each SPML or connector interface in use, the role and assignment model, the approval and recertification workflows, and the scheduled jobs that run deprovisioning. Confirm with the owners of each target which accounts are created by SAP IdM and which are created manually, because those gaps are where a cutover fails quietly. Ask your SAP account team for the current maintenance terms in writing, and confirm them against your own contract rather than relying on secondary summaries.
Treat the cutover as a parallel run, not a switch. Keep SAP IdM as the system of record while the successor processes a copy of the HR feed in simulation or read-only mode, then compare the planned changes against what SAP IdM would do. Only after the differences are explained should the successor take over one target system or one population at a time, with a tested rollback path. Provisioning never stops if each step has a named owner, a defined comparison, and a date agreed with the business before work begins.
What the 2027 deadline requires from your identity team
SAP IdM's end of mainstream maintenance in 2027 turns identity provisioning into a dated migration project. The four requirements below connect: each one determines whether the successor can take over provisioning, keep joiners, movers and leavers running, and leave evidence an auditor can follow.
Name every system SAP IdM touches
Start with a complete list of every source and target that SAP IdM provisions to today, including SAP ERP and S/4HANA, SuccessFactors, Active Directory, mail, file shares and any SPML or custom connectors. For each one, record the protocol, the owner and whether the successor has a supported or community connector for it. Gaps found here set the scope of any Entra ID Governance, midPoint or other IGA evaluation, so confirm them with the vendor before choosing a platform.
Keep joiners and leavers flowing
Provisioning and deprovisioning must not stop during the move. Identify the processes that create accounts for new hires and remove access for leavers, and decide which system remains authoritative for each one at every stage. Plan a cutover per process rather than one switch for all systems, and test that a leaver disabled in the old system is also disabled in the new one during the overlap period.
Prove access changes stayed controlled
Auditors will ask who changed access during the cutover and under which approval. Export the current approval workflows, certification campaigns and role definitions from SAP IdM, and map each one to where it will run in the successor. Retain logs from both systems for the overlap period, and confirm with your auditor which evidence they will accept for the handover, since the decision on sufficiency rests with them.
Run both systems in parallel
A parallel run only works if the decision is made early enough to build the successor, load the role model and test it against non-production data. Set an internal decision date, agree the scope with the business owners of each connected system, and confirm the support model for the platform you choose, including who patches it and who responds to incidents. Late decisions compress testing and push provisioning changes into the same weeks as the cutover.
Confirm the operating model
Decide who operates the successor after go-live. Options include an internal platform team, an external partner under a fixed-scope agreement, or a vendor support subscription on top of an internal team. Each option carries different recurring costs and different skills requirements. Ask any provider for a written statement of which tasks they perform, which remain with your team, and how upgrades will be scheduled against the release calendar.
How the midPoint release calendar shapes the timeline
The midPoint release calendar sets the outer limits of your planning window, so read it before you fix an internal deadline. According to the midPoint releases page, midPoint 4.9 support ends on 18 October 2026, and midPoint 4.11 (Čapek) is a feature release planned for 21 October 2026. midPoint 4.10 (Braille) is supported until 26 November 2027, and midPoint 4.8 (Curie) is a long-term support release supported until 17 October 2028. A team that starts a pilot on 4.9 would therefore be on a line that ends support within weeks, which is a poor foundation for a migration that must run into 2027.
Choose a supported line at the start and write down the upgrade path from it. For most migration programs, the long-term support line is the safer base because it gives the longest runway for connector work, role model changes and the parallel run with SAP IdM. A feature line such as 4.10 gives access to newer functions but requires an upgrade before its support ends. Plan that upgrade as a named work item with its own test cycle, and check the Java requirement too: midPoint recommends Java 25 for 4.11 and later and Java 21 for 4.10 and older, so the runtime upgrade may need a separate change request.
Confirm SAP's own maintenance terms and dates in writing before you set the internal decommissioning deadline. Ask SAP for the exact end of mainstream maintenance for your SAP IdM release, the terms of any extended maintenance option, and whether security fixes continue during that period. Then compare those dates with the midPoint line you select, and build the cutover plan so that the last SAP IdM dependency is removed before the earliest date that applies to your environment.
Which successor fits: Entra ID Governance, midPoint or another IGA product
This table compares Microsoft Entra ID Governance, self-hosted midPoint and other commercial IGA products against the constraints that matter when SAP IdM support ends. Read each row against your own SAP, HR and on-premises targets, and treat every connector and licensing claim for SAP as a point to confirm in writing before you choose.
| Criterion | Microsoft Entra ID Governance | Self-hosted midPoint | Other commercial IGA (SailPoint, Saviynt, One Identity) |
|---|---|---|---|
| Path SAP points customers toward | Cloud path referenced by SAP as the successor to SAP IdM | Not an SAP-named successor; chosen by the customer on its own terms | Vendor-specific paths; confirm each vendor's migration offer for SAP IdM |
| Delivery model | Cloud service in Microsoft's hosting | Self-hosted in your cloud account, data center or air-gapped network | IdentityIQ is on-premises or hybrid; Saviynt and Omada-style offerings are cloud-delivered; confirm per product |
| Connectors for Microsoft targets | Native Microsoft integration; confirm coverage for your specific targets | Microsoft Entra ID connector via Graph API documented in the ConnId catalog | Connector coverage varies; confirm Entra ID support in writing |
| Connectors for SAP targets | Confirm SAP coverage and licensing with Microsoft and SAP before committing | SAP-specific connectors need an assessment; the SuccessFactors community connector is a starting point to test | Confirm SAP connectors and the licensing for them with each vendor |
| Generic protocols | Confirm supported protocols for non-Microsoft targets | ConnId connectors include LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, SCIM2 and SCIMv1 | Confirm SCIM and CSV support for your targets |
| Licensing model | Subscription; confirm pricing and what SAP targets require with Microsoft | No license fee; optional Evolveum support subscriptions, consulting and training | Commercial subscription; obtain a written quote that lists modules and connectors |
| Recent product direction | Not covered by the supplied facts; confirm roadmap with Microsoft | midPoint 4.10 supported until November 26, 2027; 4.8 LTS supported until October 17, 2028 | SailPoint announced IdentityIQ 9.0 on October 6, 2026 as its modernization path for on-premises customers |
| Who operates it afterwards | Microsoft operates the service; you own configuration and governance | Your team or a partner runs it; Evolveum sells support subscriptions | Vendor operates the SaaS or licensed product; on-premises variants need your team or a partner |
| Data residency and on-premises reach | Depends on your tenant and region; confirm for on-premises systems | Full control over where identity data and connectors run | Depends on deployment; confirm for on-premises and sovereign requirements |
What to inventory now, before any tool is chosen
Whichever successor you choose, the migration depends on what SAP IdM does today, often without anyone having written it down. The six areas below are the items teams most often discover only after cutover, when a feed stops or an approval step no longer fires.
Source systems and the HR feed
Record every system that feeds identities into SAP IdM, not only the main HR system. For each feed, name the owner, the schedule, the file or interface format, and the rules that map job codes to roles. Note what happens when a feed is late or malformed. Many SAP IdM installations quietly skip bad records, so the first sign of a gap is often a joiner who cannot log in on day one.
Target systems and connector types
List every target system SAP IdM provisions to, with the connector or interface it uses, the account types it creates, and the credentials it holds. Include systems reached only through custom scripts or flat files. Confirm the connector status for each target in the successor you evaluate, because a system with no maintained connector becomes a manual task at cutover.
Approval and certification workflows
Document every approval path, including who approves, the escalation rules, the timeouts, and the conditions that trigger manual review. Capture certification campaigns too: their reviewers, frequency, and what a reviewer can change. Approval steps often depend on attributes that exist only inside SAP IdM, so a workflow that looks simple on a diagram can break when moved.
Role model and its owners
Export the role and entitlement catalog and assign a named business owner to each role. Record which roles are assigned by rule and which by hand, and which users hold roles that no current rule explains. Duplicate or orphaned roles are common in long-running deployments and are expensive to rebuild, so decide early whether to clean the model before migrating it.
Custom code and scripts
Identify every custom ABAP, Java, script, report or scheduled job tied to SAP IdM. Note its purpose, its trigger, the data it reads and writes, and whether its author still works in the organization. Custom code is the most likely item to be missing from any inventory built from configuration exports alone, and it often runs leaver clean-up or reporting that nobody lists as a dependency.
Audit evidence the business relies on
List the reports, logs and sign-off records that auditors, risk teams and regulators receive from SAP IdM today, and how often each is produced. Confirm the retention period for each record and where it is stored. Evidence that exists only as a screen in SAP IdM must be exported or reproduced before the system is retired, and the auditors should agree in advance what counts as equivalent evidence.
How to stage the migration so provisioning never stops
This sequence moves identity provisioning from SAP Identity Management to a successor one population and one connector at a time, so every change has a tested fallback and a recorded result before the old system is switched off.
Confirm scope and successor in writing
Agree in writing which SAP IdM jobs, connectors, HR feeds, approval workflows and target systems are in scope, and which successor you are moving to: Microsoft Entra ID Governance, midPoint or another IGA product. Name the owner of each target system and the person who signs off the cutover. Done when the scope document lists every provisioning job and connected system, and each has an owner and a chosen successor connector or feed.
Build a provisioning inventory from SAP IdM
Export the current state from SAP IdM: source systems, jobs and schedules, attribute mappings, role assignments, approval rules and the accounts each job manages in every target. Mark which jobs run on which schedule and which depend on others. Done when you can trace every account in a target system back to the SAP IdM job or manual process that created it, and gaps are logged as open items.
Stand up the successor in your own infrastructure
Install the chosen successor in your own environment with its database, backup and monitoring, and connect it to a non-production copy of the HR source and two or three test targets. Your infrastructure team and the implementation partner, if you use one, do this work. Done when the successor can read the HR source, provision to a test target, and the test results are recorded in a runbook that operations can follow.
Port the highest-risk connectors first
Start with the connectors whose failure would block joiners, revoke access late or lock out privileged users, such as directory and core SAP or financial targets. For each one, confirm the successor's connector status against the documentation, map the attributes, and test create, update, disable and delete. Done when each high-risk connector passes the same test cases as its SAP IdM job in the non-production environment, with differences logged.
Run parallel reconciliation and resolve drift
Run the successor in read-only or simulation mode alongside SAP IdM and compare what each system would do for the same identities and targets. Investigate every difference, decide which system is correct, and correct the rule or the data. Repeat until the differences are explained and agreed. Done when a full reconciliation cycle shows no unexplained differences for each population in scope.
Move the source of truth one population at a time
Choose a small, low-risk population, such as one business unit or one contractor group, and make the successor the authoritative source for it while SAP IdM stops provisioning that group. Keep the SAP IdM job available but inactive for those identities. Monitor joiner, mover and leaver events and access reviews for that group before adding the next one. Done when the chosen population has completed a full cycle of changes with no unplanned access loss or duplicate accounts.
Keep a documented rollback for each step
Before each population moves, write a rollback procedure: how to reactivate the SAP IdM job, which connectors to point back, how to reconcile accounts created during the window, and who approves the reversal. Rehearse it in the non-production environment. Done when each cutover step has a tested rollback record that names the owner and the trigger conditions for using it.
Decommission SAP IdM after audit evidence is captured
Once every population is migrated and stable, export and retain the evidence auditors will ask for: job definitions, change history, access review results, approval records and reconciliation reports from the SAP IdM period. Confirm with your auditors and compliance team which records they need and for how long. Only then shut down SAP IdM. Done when the retained evidence is indexed, stored under your records policy, and the decommissioning is approved in writing.
What running midPoint asks of your team after go-live
Once midPoint is live, the work shifts from building to operating a Java application with a database behind it. midPoint recommends Java 25 for version 4.11 and later (Java 21 is supported) and Java 21 for 4.10 and older (Java 17 is supported), so your team needs a JDK patch process that matches the release line you choose. The repository is PostgreSQL, and Evolveum recommends running it on a separate database server rather than on the midPoint host. Confirm the database backup, restore and failover approach with your DBA before cut-over, because the identity data, role model and audit history all live there.
midPoint runs on Linux in a virtual machine or from Docker images. For more than one node, you need a sticky HTTP load balancer in front of the nodes, a shared central database, and working cache invalidation between nodes over HTTPS. Quartz handles distributed task scheduling, so verify that reconciliation and synchronization tasks fire on one node only. Put these checks into your runbook and test a node failure in a non-production environment. Review the midPoint system requirements with your platform team before sizing the environment.
Evolveum sells two kinds of subscription. Product Support covers resolution of product bugs, with either an 8x5 next-business-day or a 24x7 SLA. Platform Subscriptions add feature development and roadmap influence. The supplied support information lists no prices, so request a written quote for your scope, covering the SLA tier, the number of environments, and whether you need feature work. Compare that recurring cost with the internal on-call and upgrade effort your team would otherwise carry, and remember that upgrades between release lines are work you will schedule, test and sign off whichever support tier you choose.
Who decides what: CISO, IT operations and the identity team
The CISO owns the risk position while SAP IdM still runs and the evidence that auditors will ask for once it is replaced. The deadline that matters is the end of mainstream maintenance for SAP IdM in 2027, and the decision needs to land early enough to leave room for parallel running and decommissioning. Before the decision, the CISO should be able to answer the questions below.
- Risk of standing still: What happens to access control if an unpatched SAP IdM component is found after maintenance ends, and who accepts that risk in writing?
- Audit evidence: Which access reviews, approval records and provisioning logs must survive the cutover, and in which format do auditors expect them?
- Sovereignty and hosting: Does any regulator or internal policy require identity data to stay on-premises or in a specific jurisdiction, which would weigh Microsoft Entra ID Governance against self-hosted midPoint?
- Decision deadline: Which date is the internal go or no-go, and what is the latest point at which a migration can still finish before SAP IdM is decommissioned?
Inputs to provide to DeployOpen or another partner: a list of applicable frameworks and the controls they test for identity lifecycle, the current audit findings on identity, and a signed risk owner for the transition. Confirm the maintenance terms directly with SAP before relying on any date in an internal plan.
IT operations decides where a successor runs, how it is patched and who is awake when provisioning fails. A self-hosted midPoint deployment uses PostgreSQL as its native repository, a sticky HTTP load balancer and shared state for multi-node setups, so the operations team has to size and staff those components before the platform is chosen, not after. The questions below set the operating model.
- Infrastructure: Will midPoint run on Linux virtual machines or from Docker images, and does the existing hosting platform support that pattern?
- Database: Who owns the PostgreSQL server, its backups and its failover, and is a separate database server available as midPoint recommends?
- Upgrades: Which midPoint release line will be used, and how will Java and PostgreSQL versions be kept current, given the Java version the chosen release requires?
- On-call: Who receives an alert when a connector stops provisioning at night, and what is the escalation path to the identity team?
Inputs to provide to DeployOpen or another partner: current hosting standards, the database platform and backup tooling in use, the change calendar and freeze windows, and the on-call rota with its existing monitoring stack. Confirm the current system requirements for the release you select with Evolveum before sizing hardware.
The identity team holds the knowledge that determines how hard the migration will be: which target systems exist, how roles are modeled, which approvals are live and which connectors the business depends on. Most of the effort sits here, and this team's answers decide whether the cutover can be staged so that provisioning never stops. Its questions come first in practice.
- Connectors: Which target systems does SAP IdM provision to today, and which of them have a connector in the midPoint catalog at a supported status, versus community, experimental or custom work?
- Role models: How many roles and role assignments exist, and which are duplicated, orphaned or assigned by hand, so they are not carried over unexamined?
- Approvals: Which request and approval workflows must be ported, and which owners sign off on each one?
- Cutover plan: Which population moves first, how long will SAP IdM and midPoint run in parallel, and what rollback step exists if a target system rejects accounts?
Inputs to provide to DeployOpen or another partner: an export of the target system list, role and assignment counts, the approval workflow inventory, HR source feeds, and a list of systems that cannot tolerate a change in provisioning timing. Ask for the connector status of each target system in writing, because the catalog status changes between releases.
Questions buyers ask before choosing a successor or hiring help
How much does an SAP IdM migration to midPoint cost?
No fixed figure can be given without a scope, because the cost comes from the work, not from the software. midPoint has no license fee, so the cost components are the people who plan and build the migration, the connector work, the servers and PostgreSQL that run it, the test environments, and any support subscription you choose. The main drivers are the number of connectors, the number of target systems, how many custom approval workflows and role models must be ported, and how long both systems run in parallel. Ask for a written scope that lists each of these items separately, with what is one-time and what recurs, before comparing quotes.
What makes an SAP IdM migration take longer?
Duration depends mostly on the same factors as cost: how many systems must be connected, how complex the role model is, how many approval and certification processes must be rebuilt, and how many sources of truth feed identities today. Parallel run length also matters, because you cannot switch off SAP IdM until midPoint has proven provisioning for each scenario. No duration is stated here because the researched facts do not supply one. Ask any provider to break the timeline into phases with named exit criteria for each target system, and check it against the SAP IdM maintenance end date in your own contract.
Can our internal team migrate from SAP IdM without outside help?
Some teams can, especially where they already run Java or Linux services and have staff who understand their SAP IdM job chains and role model. Most teams need support in three areas: mapping SPML-based provisioning and approval logic onto midPoint's model, building or validating ConnId connectors for SAP and non-SAP targets, and designing the parallel run and cut-over without stopping provisioning. An independent review of the migration plan is also useful. Decide early which of these your team will own and which you will buy, and write that split into the scope.
What does the internal team need to provide during the migration?
Plan for named owners rather than a shared mailbox. You will need an owner for the HR source of truth, one for each target system, someone who can approve role and access model decisions, and someone who can grant access to the SAP IdM configuration and its job logs. You also need test systems for each target that behave like production, and read access to source and target systems during discovery. Without a test target, simulations and connector tests cannot be checked properly. Confirm these needs, including access approvals and change windows, in the written scope before the work starts.
Does a self-hosted midPoint need a support subscription?
No. midPoint is licensed under EUPL-1.2 with Apache 2.0 as a secondary license, and Evolveum states that it has no enterprise edition, so you can run it without paying a license fee. Evolveum does offer Product Support subscriptions for resolving product bugs, with an 8x5 next-business-day or 24x7 SLA, and Platform Subscriptions that add feature development and roadmap influence. Whether you need one depends on how much you can absorb internally if a production issue occurs. Ask Evolveum for current pricing, since its support page lists none, and compare that with the support cost of your own team and any partner.
Does DeployOpen issue audit reports for the migrated identity platform?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies. Where your organization is preparing for a compliance assessment, DeployOpen can help make the access review, provisioning logs and role documentation ready for that assessment. Agree the exact evidence list with your auditor before the migration starts, and put the deliverables in a written scope.
What does a DeployOpen engagement cover for this migration?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including midPoint. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the scope to name which SAP IdM scenarios, connectors and parallel run stages are included, and which remain with your team.
How DeployOpen plans and stages an SAP IdM migration
DeployOpen approaches SAP Identity Management end of maintenance 2027 as a staged engagement inside your own infrastructure, starting with a written scope. We plan, implement, test, document and hand over the replacement platform, and we can stay on as a support retainer after handover.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists the SAP IdM inventory: connected systems, provisioning jobs, approval workflows and role models.
- We confirm which successor path fits your sovereignty, licensing and on-premises requirements before design begins.
- Quotes follow from the written scope, so ask for each cost component to be itemized in the proposal.
How we build
- We stage migration by connected system so that provisioning continues while each source and target moves over.
- Connectors are built or configured against your own source and target systems, with test results recorded per connector.
- Old and new platforms run in parallel for a period agreed in the scope, with reconciliation reports comparing account states.
- Test cases for joiner, mover and leaver processing are documented and run against non-production copies before cutover.
How we hand over
- Handover includes architecture documentation, runbooks, configuration exports and the evidence needed for your own assessments.
- We document the decommissioning steps for SAP IdM, including data retention and access removal, as agreed in the scope.
- Your team receives training on day-to-day operations, role changes and access request handling in the new platform.
- Backup and recovery procedures are tested and written down before the old system is switched off.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrade planning follows the midPoint release schedule, so your team knows which versions reach end of support and when.
- Support scope, response expectations and any vendor subscription are confirmed in writing, not assumed.
- DeployOpen prepares systems and evidence for compliance assessments, while independent auditors issue any audit reports.
