SAP GRC for HANA: Upgrade or Architecture Decision?
Thousands of organizations will evaluate SAP GRC for HANA over the next 18 months, and most will evaluate it the wrong way. They will treat it as a technical and/or license upgrade: a maintenance deadline, a database migration, a project plan. It is neither small nor routine. It is a commitment to a governance architecture you will live with for a decade, made at the exact moment enterprise governance requirements are changing faster than at any point since the platform was first designed.
The deadline behind the decision
All legacy GRC customers will need to migrate.
The commercial terms are straightforward. Existing S/4HANA customers can move under their current maintenance agreement without purchasing a new license. However, legacy GRC (any database) customers will require a new contract. The technical prerequisites are not trivial: the platform runs only on the SAP HANA database, and the underlying stack must be upgraded to SAP S/4HANA Foundation. Industry estimates put a typical GRC migration project at 12 to 18 months including testing and cutover.
What the upgrade delivers
Credit where due. SAP GRC for HANA modernizes a platform that needed it:
- HANA-based processing for performance at scale
- A refreshed Fiori user experience across GRC modules
- A streamlined firefighter process within SAP environments
- Joule AI capabilities applied to existing processes such as firefighter log review
- A supported lifecycle well beyond the 2027 deadline
- Continuity for the SAP authorization model your team already knows
For organizations whose critical processes live almost entirely inside SAP, and whose application portfolio will stay that way, this is a reasonable path. Familiarity has real value.
What the upgrade does not change
Here is the part that gets lost in migration planning: SAP GRC for HANA modernizes the technology stack, not the governance architecture. The platform remains built around SAP authorization constructs, designed for a world where the ERP was the application portfolio.
That world is gone for most mid-to-large enterprises. Finance runs through SAP and Coupa. HR data lives in Workday or SuccessFactors. Sales operates in Salesforce. Access requests flow through ServiceNow. And a fast-growing population of AI agents, RPA bots, and API service accounts now holds access inside core business workflows.
Measured against that reality, ERP-native governance tools share a set of structural limits:
SoD analysis stops at the application boundary. A user who can approve a purchase order in one system and post a payment in another holds a real violation that no single-application ruleset will ever see. Cross-application analysis becomes manual work: exports, spreadsheets, reconciliation.
Emergency access governance stays inside the ERP. The firefighter model is mature for SAP. There is no equivalent native coverage for elevated access in the SaaS applications where critical processes increasingly run.
Non-human identities have no lifecycle. AI agents and bots do not follow request-approve-certify cycles. Their entitlements are granted programmatically and change without human review. Governance models designed for human access constructs were not built for this, and auditors have started asking.
Identity lifecycle remains someone else’s platform. Provisioning, deprovisioning, and certification across the full application portfolio still depend on external identity infrastructure, which preserves the fragmented architecture most organizations are trying to consolidate away from.
ITSM integration means custom connectors. Organizations that have standardized workflows on ServiceNow keep building and maintaining their own bridges, and keep absorbing the technical debt when either platform changes.
Six questions before you commit
The decision becomes clearer when leadership answers specific questions rather than defaulting to inertia:
- Do we need SoD analysis that crosses the SAP ERP boundary?
- Are we deploying AI agents, copilots, or RPA bots into ERP and SaaS workflows, and what governs their access?
- Are we consolidating our identity governance stack or adding to it?
- Have we standardized operational workflows on ServiceNow?
- Is our SaaS portfolio growing, and what is the governance coverage model for it?
- Does the platform we are committing to carry the innovation roadmap our requirements will demand in five years?
If most answers keep you inside SAP, the upgrade path serves you well. If several point beyond it, you are not making an upgrade decision. You are choosing between extending the architecture of the last decade and building the architecture for the next one.
Both answers can be right. Guessing cannot.
Pathlock’s position in this conversation is straightforward: preserve full SAP governance depth while extending coverage to every application and identity that ERP-centric GRC was not designed to reach. One platform for cross-application SoD, elevated access across SAP and SaaS, non-human identity governance, and audit-ready evidence, with 500+ out-of-the-box compliance rules across 140+ enterprise applications and reports accepted by Big 4 audit firms.
Frequently Asked Questions
When does support for SAP GRC 12.0 end?
Mainstream maintenance for SAP Access Control 12.0 ends on December 31, 2027. Extended maintenance is expected to be available beyond that date at an additional cost. Typical GRC migration projects run 12 to 18 months, which places the practical decision window in 2026.
Is SAP GRC for HANA a new product or an upgrade?
It is the designated successor to SAP Access Control 12.0, Process Control 12.0, Risk Management 12.0, and other GRC solutions deployed on HANA. Existing S/4HANA customers can adopt it under current maintenance agreements without a new license, but it requires the SAP HANA database and an upgraded S/4HANA Foundation stack. Legacy GRC customers will need a new contract.
Does SAP GRC for HANA cover non-SAP applications?
The platform remains centered on SAP environments and the SAP authorization model. SoD analysis, emergency access management, and certifications for applications such as Workday, Salesforce, or Coupa are not planned capabilities.
What should we evaluate before migrating?
Ask whether your governance requirements extend beyond SAP: cross-application SoD, SaaS elevated access, non-human identity governance, identity lifecycle integration, and ITSM-native workflows. If so, these must be considered in your evaluation.
Get the full gap analysis
We have published a full gap analysis to support this evaluation. It covers what SAP GRC for HANA 1.0 includes, where the structural gaps sit, a side-by-side capability assessment, and the complete leadership decision framework. Download the whitepaper: Beyond the Upgrade: An Assessment of SAP GRC.
