There Is No New Version of SAP Identity Management to Upgrade To

SAP Identity Management customers face an unusual decision. The normal response to ageing enterprise software is to plan an upgrade. That option does not exist here. SAP Identity Management 8.0 is the final functional release, SAP has announced the end of maintenance, and the supported future sits in a different architecture. Your programme therefore needs to be treated as a migration of identity services and governance controls, not as a technical version change.

The immediate planning date is 31 December 2027. SAP also describes extended-maintenance options through 2030, but that additional runway should be used to reduce migration risk, not to postpone discovery. The exact contractual scope, price and eligibility of extended maintenance must be confirmed for your SAP estate. It does not create a new SAP IdM product generation or remove the need to choose a target model.

This guide explains what that distinction means in practice. It gives programme owners, IAM architects, security leaders and application owners a concrete way to inventory SAP IdM, select a target architecture, migrate in controlled waves and preserve the evidence that auditors will expect.

The executive answer: do not start by recreating SAP IdM task by task in a new tool. Start by identifying the business outcomes and controls that must survive. Decide which capabilities belong in SAP Cloud Identity Services, an enterprise identity governance platform, Microsoft Entra, or another authoritative system. Then migrate one complete identity journey at a time, with reconciliation and rollback evidence.

The dates and decisions that matter

SAP’s published guidance is clear about the direction. In February 2024, SAP stated that maintenance for SAP Identity Management ends in 2027, with extended-maintenance options available until 2030. SAP also positioned SAP Cloud Identity Services as central to its cloud identity strategy and described integration with partner identity systems. Later guidance from SAP and Microsoft documented a joint effort to help customers move SAP IdM scenarios toward Microsoft Entra and SAP Cloud Identity Services.

For the exact maintenance position applicable to your contract, consult SAP Note 3268799 in the SAP for Me portal and confirm it with your SAP account team. Public articles are useful planning evidence, but the authenticated note and your contract govern commercial support.

Why “no version to upgrade to” changes the work

An upgrade keeps the product’s basic responsibility intact. Data models may change and connectors may need testing, but the upgraded platform still owns substantially the same jobs. A replacement programme is different because those jobs can move to several services.

A typical SAP IdM estate may perform source ingestion, identity correlation, lifecycle rules, role assignment, approval workflows, SAP provisioning, non-SAP provisioning, password-related processes, reconciliation, reporting and custom orchestration. Years of local extensions can make the platform both an identity system and a catalogue of undocumented business decisions.

A direct object-for-object rebuild would carry those historical decisions into the target before anyone has asked whether they are still useful. It can also force one new product to imitate every feature of the old one, even when a capability now belongs in a better authoritative service.

The right unit of migration is therefore a governed identity outcome. Examples include:

• a new employee receives the standard access for a legal entity and department;
• a manager change removes inherited authority and assigns the new approval path;
• a contractor expires on the agreed date;
• a privileged SAP role requires an owner, a risk check and time-limited approval;
• a leaver loses access in every connected target and the result is reconciled;
• an access reviewer can see why access exists and record a defensible decision.

Each outcome crosses data, policy, workflow, provisioning and evidence. Migrating the whole outcome gives you something that can be tested and accepted. Migrating isolated technical tasks produces activity without proving that the business control still works.

Establish the current behaviour from configuration and logs

Before selecting a platform, build an evidence-based map of the current estate. Workshops alone are not enough. People remember the important processes, but rarely every scheduled job, exception, script, role hierarchy or downstream dependency.

Use configuration exports, job schedules, logs, connector definitions, role data, reconciliation results and service records. Compare the technical inventory with interviews from HR, application ownership, security, audit and operations. Where documentation and production differ, record the production behaviour and the owner who decides what the future behaviour should be.

At minimum, capture the following:

This inventory has two outputs. The first is a scope baseline: what exists, who owns it and how critical it is. The second is a disposition decision for every item: retain, redesign, replace, merge or retire. An object with no owner and no demonstrated use should not automatically become migration scope.

Data cleanup belongs here. Microsoft’s migration guidance explicitly recommends removing obsolete integrations, access rights and roles before migration. Moving bad data faster does not improve governance. It only makes the new platform responsible for older uncertainty.

Choose the target operating model before the target product

The target architecture should say which system makes each decision, which system executes it and where evidence is stored. Product selection is part of that design, but it is not the design itself.

SAP’s current direction centres SAP Cloud Identity Services for cloud identity needs. Identity Provisioning supports user and group lifecycle operations across source and target systems, while the Identity Directory and SCIM interfaces provide standard ways to manage identity data. Microsoft’s published migration scenario combines SAP Cloud Identity Services with Microsoft Entra capabilities. That pattern may be appropriate when Entra already provides the organisation’s identity, access and governance foundation.

It is not the only possible enterprise model. A self-hosted identity governance platform may be required when the organisation needs direct infrastructure control, broad non-SAP connectivity, complex identity correlation, portable configuration or a governance layer that spans several identity providers. The architecture must follow requirements that you can verify, rather than a slogan such as “cloud first” or “like for like.”

Evaluate candidate designs against explicit responsibilities:

A design is incomplete if two systems can independently change the same entitlement and no precedence rule exists. It is also incomplete if a workflow records “approved” but nobody can prove that the target application applied the change.

Build a migration factory in five controlled phases

A successful SAP Identity Management migration is repeatable. The first wave establishes a method; later waves use the same gates, evidence and ownership model.

1. Discover and classify

Complete the inventory, link every item to an owner and group the estate into migration domains. A domain could be an identity population, an application family or a complete lifecycle journey. Score each domain for business criticality, data quality, customisation, control impact, integration complexity and available test coverage.

Choose a pilot with enough substance to test the method, but avoid making the most critical and customised SAP process your first attempt. A useful pilot has a cooperative application owner, representative identity data, measurable provisioning outcomes and a realistic approval path.

2. Define the target control

Write the future-state behaviour in business terms before configuring it. For a joiner, specify the trigger, minimum data, standard access, exceptions, approval ownership, expected completion time and evidence. For a leaver, specify the authoritative end signal, disablement sequence, retained accounts, urgent termination path and reconciliation threshold.

Translate those statements into acceptance tests. This prevents the project from declaring success because a connector returned HTTP 200 while a critical role remained assigned in the application.

3. Build and prove the pilot

Create the target integration in a staging environment with production-like data protection. Test normal flows and failure paths: missing manager, duplicate identity, delayed source, rejected approval, target timeout, partial provisioning and rollback.

Run reconciliation before and after each scenario. The evidence pack should show the input event, policy decision, human decision where required, requested technical change, target result and reconciled state. Security and application owners should accept the result together.

4. Operate controlled coexistence

A staged migration usually means SAP IdM and the target services coexist. Coexistence is safe only when writing authority is explicit. For every application and entitlement class, document which platform may create, modify and delete. Disable duplicate schedules and prevent two engines from racing to enforce different desired states.

Use comparison reports during the observation window. Differences must be classified: expected design change, data timing, configuration error, source-quality issue or target failure. Do not hide unexplained differences inside a tolerance percentage.

5. Migrate waves and decommission deliberately

Move subsequent domains through the same entry and exit gates. The programme board should see outcome-based measures: identities reconciled, controls accepted, exceptions resolved, rollback rehearsed and evidence complete.

Decommissioning is its own workstream. Stop inbound feeds and scheduled jobs in a controlled order, archive configuration and audit records under the retention policy, revoke service accounts, remove network paths, close operational queues and assign ownership for remaining historical evidence. A server that is merely switched off is not a completed decommission.

The controls most likely to be lost

Migration teams naturally focus on provisioning because it is visible and technically testable. Governance can degrade quietly if the programme does not test the reason behind the change.

Watch these areas closely:

• Direct assignments: access outside the role model may be legitimate, emergency access or accumulated debt. Classify it before moving it.
• Role ownership: an imported role without an accountable owner cannot support a reliable request or review process.
• Approval context: reproducing an approval step is insufficient if the approver no longer sees the user, business purpose, risk, duration and conflicting access.
• Separation of duties: preserve the rule, scope, exception authority, mitigating control and evidence of the decision.
• Mover behaviour: department and manager changes often reveal hidden dependencies that joiner tests miss.
• Non-human identities: service accounts need owners, purpose, credentials handling and expiry rules even when they do not follow HR events.
• Execution evidence: distinguish requested, approved, sent, applied, verified, failed and unknown. These are different states.
• Historical records: agree what must remain searchable after SAP IdM is retired and how its integrity will be protected.

A practical acceptance rule: for every high-risk access change, an independent reviewer should be able to answer who requested it, which policy was evaluated, who approved it, what the target actually changed, whether that state was reconciled and when it will be reviewed again.

What a credible plan contains

A programme can be ready to execute before every product detail is settled. It cannot be ready without ownership, evidence and decision dates.

Use this minimum checklist:

• An executive owner accepts that this is a replacement programme, not an SAP IdM upgrade.
• The plan works backward from 31 December 2027 and reserves time for stabilisation and decommissioning.
• Extended maintenance is treated as a separately confirmed contingency.
• Every source, target, workflow, role set, custom job and audit report has an owner and disposition.
• Current data quality is measured before target configuration begins.
• The target operating model assigns authority for lifecycle, governance, provisioning, authentication, reconciliation and evidence.
• Pilot scope includes a complete identity journey and realistic failure cases.
• Coexistence rules prevent duplicate writers.
• Wave exit criteria require reconciled target state and accepted control evidence.
• Rollback is tested for changes that can materially interrupt access or business operations.
• Historical evidence, retention, service-account removal and infrastructure shutdown are included in decommissioning.
• Procurement, security review and contractual decisions are scheduled early enough to avoid becoming the critical path.

If several of these answers are still unknown, the next useful investment is discovery and target design. Buying licences first will not answer them.

How easyIGA fits into the decision

For organisations considering a self-hosted governance model, easyIGA provides a business layer over the open-source midPoint identity governance engine. It is designed to make access requests, approvals, reviews and evidence understandable to business users while keeping policy and provisioning in the governance engine. Self-hosted by default, on your own infrastructure, in your own jurisdiction. For organisations without suitable infrastructure, an EU-hosted deployment operated by our team is available on request.

That makes easyIGA relevant where the SAP IdM replacement must govern both SAP and non-SAP systems, preserve customer control of identity data and configuration, and connect human decisions to technical outcomes. It does not remove the discovery work described in this guide. No platform can safely infer which custom SAP IdM behaviours are required, which are obsolete and which encode undocumented controls.

The first engagement should therefore produce a current-state inventory, target responsibility model, prioritised migration waves and pilot acceptance criteria. Those outputs remain useful even if the final architecture combines several products.

Contact our team if you want a technical review of an SAP IdM estate or a workshop to define the first migration wave. Bring the real connector list, job schedule, role catalogue and control evidence. A useful assessment starts with what the platform actually does.

Confirm the product scope before choosing a platform

For an SAP IdM replacement, test the required SAP and non-SAP operations with your actual application versions. The easyIGA evidence overview explains recorded approvals, grants made elsewhere and missing history. Retain failed changes in the migration record so unresolved work stays visible. Our team’s 14+ midPoint implementations inform the planning and delivery of this work.

Continue with the implementation

Use the SAP IdM migration readiness checklist to record owners, evidence and pass conditions. For target selection, read the IGA guide.

Sources and verification notes

Product scope and editorial wording updated on 24 September 2026. The original source-check dates below remain the dates of those checks.

The factual statements in this article were checked against the following primary sources on 11 September 2026:

1. SAP, “Preparing for SAP Identity Management’s End-of-Maintenance in 2027”, https://community.sap.com/t5/technology-blog-posts-by-sap/preparing-for-sap-identity-management-s-end-of-maintenance-in-2027/ba-p/13596101
2. SAP, “Update on the SAP Identity Management migration to Microsoft Entra”, https://community.sap.com/t5/technology-blog-posts-by-sap/update-on-the-sap-identity-management-migration-to-microsoft-entra/ba-p/13742820
3. SAP, “Advantages of Proactive SAP IDM Migration”, https://community.sap.com/t5/technology-blog-posts-by-sap/advantages-of-proactive-sap-idm-migration/ba-p/14042339
4. SAP Note 3268799, maintenance strategy for SAP Identity Management (SAP login required), https://me.sap.com/notes/3268799
5. SAP Identity Management 8.0 Upgrade Guide, https://help.sap.com/doc/c48ff06e7e76450480ef93e5357381d5/8.0/en-US/IDM_UpgradeGuide.pdf
6. Microsoft Learn, “Migrate identity management scenarios from SAP IDM to Microsoft Entra”, https://learn.microsoft.com/en-us/entra/id-governance/scenarios/migrate-from-sap-idm
7. Microsoft Cloud Adoption Framework, “Identity and access management for SAP platform”, https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/sap/eslz-identity-and-access-management
8. SAP Help, “Identity Provisioning API”, https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/identity-provisioning-api
9. SAP Help, “Onboarding and Provisioning”, https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/onboarding-and-provisioning
10. SAP Help, “User and Group Creation in Identity Directory”, https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/user-and-group-creation-in-identity-directory
11. Image: imgix on Unsplash, https://unsplash.com/photos/server-racks-in-data-center-klWUhr-wPJ8; licence: https://unsplash.com/license

Maintenance and licensing terms can vary by contract. Confirm the applicable SAP Note and commercial terms with SAP before using them as a binding programme assumption.