SAP made the choice for its customers. If you’re running SAP Identity Management today, you need to move off it, while also managing one of the biggest overhauls your SAP landscape will ever go through: the move to RISE with SAP.
That’s two deadlines could be landing on the same desk at the same time. SAP has confirmed that mainstream maintenance for SAP Identity Management ends December 31, 2027, with extended maintenance available only until 2030 at additional cost, and SAP has been direct about what comes next: there is no successor product.
SAP’s own Cloud Identity portfolio is explicitly not a like-for-like replacement and isn’t built to serve as a central identity system spanning both SAP and non-SAP environments. It’s happening right as the core ERP architecture, hosting model, and integration patterns underneath everything get rebuilt through RISE.
Treating identity governance as a footnote to the RISE timeline is a mistake many teams make once. It needs its own workstream, its own milestones, its own risk plan running in parallel with the rest of the project.
RISE with SAP shifts a lot of infrastructure administration over to SAP as the managed service provider, including Basis, the technical layer that keeps an SAP system running underneath the actual business applications, and that changes who owns identity lifecycle processes, role provisioning, emergency access, and segregation-of-duties controls once the new environment goes live.
Companies that treat the SAP IDM retirement as a straight swap, the same processes dropped into a new tool, tend to find out the hard way. Usually after go-live! Provisioning breaks, entitlements go orphaned, and both show up as audit findings. Sometimes it’s worse: business users locked out of systems they need to do their jobs.
What Changes Under RISE, In Practice
Today, if you run SAP on-prem or in a customer-managed cloud, your team owns the full stack, infrastructure, Basis administration, and identity governance all sit under one roof, even if IDM handles the identity piece separately.
Under RISE, SAP takes over infrastructure and Basis administration as the managed service provider.
That split matters more than it sounds: emergency access procedures that assumed direct system access now have to route through SAP’s managed operations model.
Segregation-of-duties controls that were validated against your own infrastructure team now need to account for SAP’s operational staff as a party with system-level access.
Role provisioning workflows built around your team making backend changes directly may need to be redesigned around SAP’s change-management process instead.
None of this is insurmountable, but it has to be planned for, it doesn’t happen automatically just because RISE promises a “managed” experience.
SAP IDM Is Reaching Its End of Life: Here’s What to Do
With SAP IDM retirement and the transition to RISE with SAP converging, identity governance requires careful planning. Read this guide and discover:
A safer path starts with real discovery, not a quick inventory pass. Every identity management workflow, every business role, every custom provisioning rule and downstream integration tied to SAP IDM needs mapping, because years of customization rarely get documented as they happen.
This is the discovery phase One Identity’s migration approach is built around, precisely because skipping it is where most SAP IDM retirements go wrong.
From there, access requirements get mapped against the target RISE architecture. Role design should take advantage of the simplified authorization model in the new environment instead of dragging old ECC roles over unchanged.
Where the IGA platform sits inside a RISE landscape matters just as much: how it talks to SAP’s managed operations, and whether segregation-of-duties controls still hold once infrastructure ownership splits between the customer and SAP.
For organizations whose identity governance needs extend beyond the SAP estate, spanning non-SAP applications, cloud infrastructure, and cross-system segregation-of-duties requirements, that breadth is the deciding factor, not just what happens inside SAP.
Sequencing carries its own weight here, and there are really only three options, each with a different risk profile:
Retire SAP IDM Before the RISE Cutover
You get a clean identity foundation before the bigger transformation lands, but you’re rebuilding governance twice in short order: once for the new IGA platform, again when the new environment’s authorization model changes what you’re governing.
Run both in parallel. Fewer total transitions, but it means managing two major, interdependent projects at once with shared stakeholders and overlapping risk windows, which can be a resourcing and coordination challenge more than a technical one.
Retire SAP IDM After the RISE Cutover
You design the new IGA platform around the target architecture from day one, which avoids rework, but it also means running SAP IDM past its comfort zone during the RISE transition, on a system that’s already being told it’s on its way out.
There’s no universally right answer, it depends on how much of your provisioning logic is genuinely SAP-specific versus how much spans non-SAP systems, and how much parallel-project bandwidth your team actually has. But picking a sequence deliberately, with the tradeoffs above in view, beats discovering the tradeoffs mid-project.
The organizations that get this right treat the SAP IDM sunset as a chance to rebuild identity governance for the SAP environment they’ll run for the next decade, not as a forced swap they’re stuck executing on someone else’s timeline. The ones that skip the planning tend to find their gaps the same way every time: during an audit, or during an outage that hits the business exactly where it hurts.
One Identity has walked SAP customers through this exact transition, with a certified SAP connector, coverage across on-prem, hybrid, and SaaS environments, and a migration methodology built specifically for organizations retiring SAP IDM while moving to RISE with SAP. Mainstream maintenance ends December 31, 2027, and a migration planned around your RISE timeline takes longer to execute well than it does to postpone.
The choice isn’t whether identity governance tools change when SAP IDM retires; the choice is whether that change happens on your terms, mapped and sequenced in advance, or shows up later as the orphaned entitlement or the locked-out user nobody planned for.
