What actually changes
Fiori
Access now covers tiles, catalogs, spaces and pages as well as authorizations.
OData services
Apps need their services started, and that has to be in the role.
Business partner
Vendors and customers move to BP, so FK01-style checks change.
Simplification
Some transactions are replaced or gone, and old roles still point at them.
Three routes
| Route | Fits when | Watch out for |
|---|---|---|
| Migrate | The concept is clean and people can explain it | Replaced transactions, Fiori access |
| Clean up, then migrate | The structure is sound but the roles are too broad | Clean-up slipping behind the project |
| Redesign | Nobody can explain the roles, or you're doing a greenfield move | Time, and enough business input |
Why it can't wait until the end
Authorizations are often planned last, so testing runs with broad access. Then everything works, until the real roles arrive in the final weeks. The usual emergency fix is to make them broader, and you've taken your old problems to the new system.
- Include roles in the process design
- Test with real roles, not with broad test users
- Check SoD on the design, before go-live
- Name the role owners during the project
Questions about S/4HANA roles
Can we migrate our ECC roles to S/4HANA?
Technically yes, in a brownfield conversion the roles come along. But custom code, replaced transactions and Fiori all change what those roles need, so they have to be checked and usually adjusted.
How do Fiori roles differ from classic SAP roles?
Fiori roles still live in PFCG, but they also control what appears in the launchpad through catalogs, spaces and pages, and they need authorizations to start the OData services behind each app.
When should we start on the authorization concept?
Early, ideally alongside the process design. If roles are left until the end, testing suffers, and go-live often ends with roles that are far too broad.
