← All insights

GRC in the S/4HANA migration: rebuild, don't carry forward

The move to S/4HANA forces every organisation to rebuild its access model. That's not a chore to minimise, it's the best chance in a decade to fix controls properly. The instinct to copy the old design forward squanders it.

For years, the honest answer to "when will we clean up our SAP roles and segregation of duties?" was "not on a live system." Rebuilding access on a running production environment is high-risk and rarely justifiable on its own. So access debt accumulates, and everyone learns to live with it.

The S/4HANA migration changes that. Moving off legacy ECC isn't a simple upgrade, the data model changes, transactions are reorganised, and the authorisation concept has to be rebuilt regardless. For the first time in years, roles, SoD and controls are on the table anyway. The only real decision is whether to rebuild them well or recreate the past.

The carry-forward trap

Under deadline pressure, the tempting shortcut is to lift the existing role model and replicate it on the new platform. It looks faster and lower-risk. It's neither, in any meaningful sense.

Copying your roles into S/4HANA doesn't migrate your access model. It migrates your access debt, and recreates on day one the exact risk the project was supposed to fix.

Every redundant role, every over-broad assignment, every unresolved conflict and every "temporary" grant comes across intact. The organisation spends a fortune on a transformation and arrives with the same control problems it started with, now embedded in a system expected to last another decade. The migration's single biggest governance opportunity is spent avoiding work that will have to be done eventually anyway, under worse conditions, on a live system.

What rebuilding well looks like

Treating the migration as a controls rebuild rather than a controls copy means a few deliberate choices:

• Design from real usage. Use what people actually do, drawn from genuine transaction behaviour, as the basis for the new roles, rather than replicating whatever existed before.
• Build segregation of duties in. Keep conflicting duties out of roles from the first design, so you don't inherit a remediation backlog on the new platform.
• Scope privileged and emergency access deliberately. Rebuild Firefighter and sensitive access as part of the design, not as an afterthought once go-live pressure hits.
• Make the model legible and maintainable. Roles whose purpose is clear, that map to real jobs, and that can be governed lightly afterwards.

The result is a control environment that's clean on go-live day and defensible at the first audit, rather than one that needs remediating the moment the programme ends.

Why it's been so expensive, and what's changing

If rebuilding is so clearly better, why does carry-forward keep winning? Because doing it properly has traditionally been slow and costly. The risk-and-controls workstream, role design, SoD, sensitive access, process controls, has meant specialist teams working for months, at a cost that runs well into six figures on a large programme. Faced with that, under a fixed deadline, many teams understandably reach for the shortcut.

That economic equation is what's now shifting. The expertise involved in this work, knowing how to mine usage, design least-privilege roles, derive a sensible SoD ruleset, and validate it against live configuration, is increasingly something software can carry out, not just advise on. Agentic AI can read an estate's real behaviour and generate a controls design from it in a fraction of the time a manual rebuild takes, then keep monitoring and re-tuning that design after go-live.

The significance isn't just speed or cost, though both matter. It's that "rebuild properly" stops being the expensive option that gets cut and becomes the practical default. When designing clean controls from live data costs less than copying the old ones forward and remediating later, the carry-forward trap loses its main excuse.

The window won't stay open

Migrations are once-in-a-decade events. The chance to rebuild access cleanly, without the risk of re-engineering a live system, arrives with the programme and closes when it ends. Organisations that use it well emerge with a control environment built for the next ten years. Those that copy the past forward will be back to living with their access debt by the first post-go-live audit, and waiting for the next migration to get another chance.

The S/4HANA wave is the rare moment when good governance and project pragmatism point the same way. Rebuilding controls is no longer the slow, expensive path it once was. The smart move is to treat the migration not as something to survive, but as the opportunity it actually is, to leave behind a controls layer that's clean, audit-ready, and built to maintain itself.