The Deadline Behind the Deadline
Most SAP organisations know they have a 2027 problem. Fewer know they have two, and almost nobody has drawn them on the same calendar in the right order. Here is the sequence, on one page.
The dates
SAP Access Control 12.0, Process Control 12.0 and Risk Management 12.0 all reach end of mainstream maintenance on 31 December 2027. Extended maintenance runs to 2030. After that, customer-specific maintenance only.
That much isn’t in dispute.
The scope is wider than three products
Seven products convert into the successor release. The three above, plus audit management, business integrity screening, and the UI masking and logging components.
Most organisations are tracking one of the seven — usually access control, because that’s the one with an audit finding attached to it. The other six move on the same schedule.
The prerequisite
This is the part that changes the shape of the decision.
The successor release requires SAP S/4HANA 2025, or SAP S/4HANA Foundation at that release level.
Your control platform is downstream of your ERP decision. Not adjacent to it. Downstream.
So it’s a sequence, not a set of choices
ECC, then S/4HANA 2025 or the Foundation, then the new GRC release. Two legs. One deadline. In that order.
That distinction matters because most organisations are treating these as parallel workstreams. The ERP programme has an owner, a budget, a steering committee. The GRC platform has a different owner, usually in risk or internal audit, with its own budget and its own committee. Both are tracking 2027. Neither has the dependency on their plan.
Working the calendar backward
Take the second leg first. It’s the one people underestimate.
A GRC migration — scoping, configuration, ruleset rework, testing, user acceptance, cutover — is commonly estimated at twelve to eighteen months. Treat that as an estimate rather than a fact, but it’s the right order of magnitude for anyone who has done one.
Now the first leg. An ECC to S/4HANA move is measured in years, and it has to be complete — not started, not in wave two — before the GRC leg can begin.
Work backward from December 2027 and the decision date sits well inside 2026. For most organisations that means this year, not next.
What the frozen path costs
The obvious response is extended maintenance. Take the three years, sequence calmly, land it by 2030.
That’s legitimate and a lot of organisations will do it. But it should be bought with a clear view of what it contains.
A release in extended maintenance keeps running. What stops is everything behind it: security patches, legal and regulatory updates, support for new modules. And by definition, new capability — a frozen release receives corrections, not features.
Which means anything that ships in a future release ships somewhere you aren’t. Including agent governance. Agent identity, registries, runtime controls, evidence trails — all of that is future-release work, arriving in versions after the one you froze, during precisely the period when agents show up in your estate.
Extended maintenance buys time. It doesn’t buy capability. Those are different purchases and the business case usually only prices the first one.
On cost: SAP publishes an extended-maintenance premium of two percentage points on the maintenance basis for its Business Suite 7 core applications. Whether the same figure applies to the GRC products specifically is worth confirming with your account team rather than assuming — it isn’t stated in the same place.
What this piece is not about
Three things deliberately left out, because each one deserves its own treatment and none of them changes the sequencing argument.
Third-party support is a real option used at scale, and it changes the ERP question. It doesn’t remove the control-platform question.
If you’re running S/4HANA public cloud, most of this doesn’t apply to you in the same form.
And SAP Cloud Identity Access Governance is a different path with no S/4 prerequisite. It’s also, by independent assessment, narrower than access control on segregation-of-duties depth and emergency access. That’s a comparison worth doing properly, and this isn’t it.
The honest caveat
The end-of-maintenance dates are firm. The successor’s availability is planned, and those plans have already moved once.
That cuts both ways. It argues against rushing to a release that isn’t stable. It also argues against assuming the deadline moves because the successor did. SAP extended ECC once and a lot of people read that as a pattern. It might be. Plan as though it isn’t.
Where to start
Not with a migration plan. With two questions.
Which leg are you on — and is it actually complete, or complete for the entities that matter?
And who owns the sequence? Not the ERP programme. Not the GRC platform. The dependency between them.
If the answer to the second question is a shrug, that’s the finding. It’s also the cheapest thing on this page to fix.