How do you handle SAP authorizations and roles in an S/4HANA migration?
Roles are the migration workstream nobody scopes early, and the one that most often surfaces at user acceptance testing.
The short answer
Treat authorizations as a redesign, not a copy. Most of your ECC roles will still technically work after conversion, but S/4HANA changes what users need: the Fiori launchpad replaces transaction menus, new apps carry their own authorization defaults, and simplification items such as Business Partner and FSCM introduce new authorization objects. The reliable approach is to derive the new role set from usage data rather than from the old role tree: find the transactions and apps people actually run, map them to Fiori catalogs and groups, regenerate authorization proposals through SU24 and SU25, and retire roles that grant access to processes you are no longer running. Segregation-of-duties testing then confirms the result before cutover.
Why do ECC roles not simply carry over?
A system conversion keeps your PFCG roles in place, so on day one many users can still log on and run transactions. The problem is what changed underneath. Some transactions are replaced by Fiori apps, some are removed outright as simplification items, and some processes now run through different objects. A role that looked complete in ECC can quietly under-authorize, or over-authorize, a user in S/4HANA.
The second issue is scale. Estates that have run for fifteen years typically carry thousands of roles, many copied from one another, many granting access to processes the business stopped using long ago. Converting all of that unexamined imports the risk along with the access.
What actually changes in S/4HANA authorizations?
Three shifts matter most. First, the Fiori launchpad becomes the primary entry point, so users need business catalogs and groups in addition to back-end authorizations; each Fiori app also needs its OData services and back-end objects permitted. Second, simplification items introduce new objects and checks, with Business Partner replacing customer and vendor master authorization as a common example. Third, the SU24 proposal values, which drive what PFCG suggests, are updated by SAP for new apps and transactions and should be re-synchronized after conversion.
- Fiori catalogs, groups and spaces now define what users see and can launch.
- Back-end authorization objects behind each app must still be maintained in the role.
- SU25 steps reconcile your customer proposal values with SAP's updated defaults after conversion.
- Custom code you retire also retires its custom authorization checks, so the role clean-up and code clean-up should be sequenced together.
How do you rebuild the role set without starting from zero?
Start from evidence. Pull usage statistics for transactions and apps over a full business cycle, including quarter-end and year-end, so infrequent but critical activity such as period close is not missed. Group users by what they actually do, map those activities to standard Fiori business roles as a starting template, and only then layer on your customer-specific restrictions.
This is the same principle as fit-to-standard for processes: adopt the standard role model where it fits, and document each deviation with a reason. A role you can explain in one sentence is one an auditor can review in one sitting.
Where does segregation of duties fit?
Redesigning roles is the cheapest moment to fix segregation-of-duties conflicts, because you are already touching every role. Run your SoD ruleset against the proposed roles before build, not after. Conflicts found on paper cost an hour to resolve; conflicts found after go-live cost an audit finding.
Plan role testing as its own stream: test users per persona, negative tests confirming access is denied, and a mock cutover of user-to-role assignments. Roles are also a natural place for automation, since usage analysis and conflict checking are repeatable, evidence-heavy work. Any automated proposal should still land as a draft that your security team reviews and your change board approves.
Frequently asked
Should we redesign roles before or after technical conversion?
Start the analysis before conversion, because usage data and the target Fiori design do not depend on the converted system. Build and test the new roles in a converted sandbox or development system, then move them through your normal transport path. Leaving all of it until after conversion compresses it into user acceptance testing, which is where most role problems are found too late.
Do we have to move all users to Fiori at go-live?
No. SAP GUI transactions that remain supported can continue to run, and many programs phase the Fiori rollout by persona. What matters is that each user has a role set that authorizes exactly what they are meant to do on day one, whichever entry point they use.
How many roles should we expect to end up with?
It depends entirely on your estate, and any single figure would be a guess. The direction is consistent, though: fewer, more explainable roles built from actual usage, with each one mapped to a business persona. Your own usage data, not a benchmark, should set the target.
See your own Clean Core Score.
Run the free S/4 readiness scan in under a minute — no system access required.
Keep reading