When planning a move from SAP Governance, Risk, and Compliance (GRC) 12.0 to SAP GRC for SAP HANA 1.0, it can be difficult to decide when to start. The platform is available and GRC 12.0 has a maintenance deadline, but neither fact tells you whether moving now is right for your organization.
For GRC and security leaders, the maturity of the new platform, the condition of your current environment, and the timing of wider SAP programs should shape that decision.
It helps to think of this in two phases: when to carry out the technical migration, and when to start preparing for it. For many organizations, the first can wait until 2027, but the second should begin now. This article explains the maintenance change, how to judge the migration window, and what to prepare now.
Mainstream maintenance for SAP GRC 12.0 ends on December 31, 2027. This applies to SAP Access Control 12.0, SAP Process Control 12.0, and SAP Risk Management 12.0. SAP has indicated that extended maintenance will run through 2030, followed by customer-specific maintenance.
Existing systems will keep operating, but extended maintenance is not automatic: its availability, cost, and technical conditions can vary by customer contract and landscape. Organizations planning to remain on GRC 12.0 should confirm their position with SAP early, then decide how long they want to keep investing in the older platform.
SAP's future development is moving to SAP GRC for SAP HANA 1.0, also known as GRC 2026, which brings the current applications onto a common HANA-based foundation. This first release focuses mainly on that technical modernization; as the platform matures and gains functionality, the case for migration will become stronger.
Customers with a stable GRC environment and no wider program dependency may gain little from moving immediately, because they would be transferring working processes to a platform that is still maturing. Waiting until early summer 2027 gives customers more time with the release and still leaves several months before mainstream maintenance ends. As a result, problems can be fixed or the plan adjusted without the deadline dictating every decision.
An S/4HANA or RISE with SAP program that depends on GRC can shift that timetable. If GRC needs to be in place before go-live to support risk and control reporting in the new S/4HANA environment, an earlier move may reduce risk across the larger program.
The destination must also fit the future application strategy, with several routes available:
Most of these routes concern access governance. For Process Control and Risk Management, IAG is not relevant; the choice is instead between SAP GRC for SAP HANA 1.0 and, where the organization's cloud direction supports it, SAP Risk and Assurance Management (RAM), the cloud counterpart to Process Control.
The choice depends on current usage, cloud adoption, integration needs, reporting obligations, risk tolerance, and existing investments. Treating the work as a version upgrade before resolving those questions could carry the wrong architecture forward.
For a more complete comparison of these architecture choices, read Turnkey's GRC modernization guide for SAP-centric organizations.
Waiting to migrate is not the same as waiting to prepare. Any migration timetable has to account for the condition of the current environment. Years of customization and operational change often leave teams without a complete account of the functions in use, the processes that depend on them, or the intended behavior of custom code. If discovery begins only after the project starts, the first part of the schedule can disappear into working out what the existing system actually does.
Starting that preparation now reduces uncertainty without committing the organization to an immediate move. Teams can document the current estate, establish the testing baseline, address HANA readiness, and remove data or roles that do not need to be carried forward. When the chosen migration window arrives, the project can focus on the move itself rather than beginning with an open-ended investigation.
Leaving the migration until late 2027 can increase costs in four ways:
Preparation should begin with how GRC is used in practice. Review operating procedures with their owners, then inventory functionality, integrations, custom code, automated scripts, master data, and dependencies across Access Control, Process Control, and Risk Management. This is particularly important when the technical team can identify a customization but the business cannot explain its purpose.
How much testing is needed also depends on how deeply each application is used. Access Control customers running end-to-end provisioning must validate more integrations and custom behavior than those using periodic risk analysis. Process Control may rely on fragile automated control scripts. Risk Management may include version-specific key risk indicator (KRI) or key performance indicator (KPI) automation.
The inventory should feed directly into a formal regression test pack. For every material scenario, document the steps, expected behavior, and expected result, with particular attention to customizations, provisioning flows, automated controls, and KRI or KPI scripts. A usable test pack gives the migration team an objective way to find defects and prove that each process still works after the move. It also protects the current environment during routine upgrades in the meantime.
Before the chosen migration window opens, aim to have:
With these in place, the migration becomes a planned technical exercise rather than an investigation against a deadline, and the organization can choose its migration window on business grounds rather than having it set by the end of mainstream maintenance.
Turnkey's GRC Modernization Assessment helps customers decide when to move and what must happen first. It assesses the current GRC environment against the organization's SAP plans, risk requirements, people, processes, and technology, then produces a prioritized roadmap for immediate preparation and the longer-term migration.