The single biggest financial decision in an S/4HANA conversion is not the software — it is how your existing named users are mapped to the new license categories. Under ECC, you bought discrete named-user types: Professional, Limited Professional, Employee, Employee Self-Service, and a long tail of special and engine-based licences. Under S/4HANA, SAP collapses most of these into a smaller set of usage-based categories measured in Full Use Equivalents (FUE). The mapping exercise decides whether you carry forward an accurate, optimised user base or whether you re-license the accumulated drift of a decade-old ECC estate at S/4HANA prices. Before you sign anything, it is worth understanding how this conversion interacts with your wider options, including the third-party support route that some organisations take instead of converting at all.
Two licensing worlds: ECC named users vs S/4HANA FUE
ECC licensing was built around the named-user type. Each human with a logon needed a license, and the type you assigned determined what they were permitted to do and what you paid. A Professional user could perform operational, administrative, and management tasks across modules. A Limited Professional was restricted to a narrower operational role. Employee and Employee Self-Service users covered occasional, low-transaction activity such as submitting a timesheet or a leave request. Layered on top were dozens of niche categories tied to specific applications and the separate world of engine and package metrics.
S/4HANA reorganises this around the Full Use Equivalent. The FUE is a converged unit of measure: different user categories consume different fractions of an FUE, and your contract is sized in total FUEs rather than in counts of discrete user types. SAP's current digital-access-era user model groups most human access into a small number of categories — broadly an advanced (developer and power-user) tier, a core (operational) tier, and a self-service tier — each weighted differently against the FUE. The headline simplification is real, but it changes the optimisation problem completely: you are no longer counting how many Professional licences you own, you are deciding which weighted category each real person belongs in.
Why the mapping is where money is won or lost
SAP and its partners will often propose a like-for-like conversion: every Professional becomes the highest category, every Limited Professional becomes the middle category, and so on. This is fast, it is defensible from SAP's side, and it almost always over-licenses the customer. The reason is that ECC user types were assigned years ago, frequently in bulk, and rarely revisited. Most estates carry a meaningful share of Professional licences held by people whose actual usage looks like a self-service or core user — they log in monthly, run a report, approve a request. A mechanical mapping preserves every one of those mis-assignments and converts them into the most expensive S/4HANA category.
The disciplined alternative is a usage-based re-mapping. Instead of mapping license type to license type, you map observed behaviour to the correct new category. This is the same principle that underpins a clean ECC-to-S/4HANA migration: the conversion is the one moment when the vendor expects you to restate your user base, so it is the cheapest possible time to correct years of accumulated drift.
The conversion is a one-way door priced on your inputs. SAP sizes the new contract on the user classification you bring to the table. If you arrive with an unexamined ECC user list, you will pay for its errors for the life of the agreement. If you arrive with a cleaned, evidence-backed classification, the same estate can convert into materially fewer FUEs — with no loss of access for any real user.
A buyer-side mapping method
1. Measure actual usage before you classify anyone
Pull real activity data — transaction frequency, modules touched, read-versus-write behaviour, last-login recency — for every active account over a representative period, ideally twelve months to capture quarter-end and year-end peaks. SAP's own measurement tooling produces part of this picture, but the authoritative view comes from your security and usage logs. The output you want is a behavioural profile per user, not a list of currently-assigned license types.
2. Define target categories from behaviour, not history
Translate each behavioural profile into the lightest S/4HANA category that still covers what the person genuinely does. A user who only ever creates and approves their own requests belongs in self-service. A user running operational transactions in one or two modules belongs in core. Reserve the advanced tier for genuine power users, developers, and cross-functional administrators. The mapping table below shows the typical direction of travel — note that it is indicative, and every contract defines its categories slightly differently.
| Legacy ECC type | Common assumption | Evidence-based target |
|---|---|---|
| Professional | Advanced / highest category | Often Core; Advanced only for true power users, developers, admins |
| Limited Professional | Core category | Core, or Self-Service where usage is occasional and request-based |
| Employee Self-Service | Self-Service category | Self-Service, or no user license where access is system-to-system |
| Dormant / duplicate accounts | Carried forward | Removed before measurement; never converted |
3. Eliminate before you convert
Dormant accounts, duplicate identities for the same person, generic system accounts, and accounts belonging to departed staff should be removed or reclassified before any mapping is finalised. Converting a duplicate or a leaver is paying twice for nobody. This cleanup step routinely reduces the chargeable population before category weighting even begins.
4. Separate human access from indirect and system access
The FUE model covers human, named access. Access generated by other systems, interfaces, and bots falls under digital access and is licensed by document, not by user — a distinction that has tightened considerably in recent years. Make sure that machine-to-machine traffic is not accidentally swept into your named-user count, and that genuine indirect use is accounted for correctly under the right metric. For the detail on where that line now sits, see our analysis of SAP's API and indirect-access restrictions and the underlying SAP user types.
Contract conversion versus product conversion
SAP offers more than one commercial path onto S/4HANA, and the path changes how your legacy entitlements are valued. A contract conversion re-papers your existing agreement into the new model, typically applying conversion credit for the licences you already own. A product conversion exchanges specific legacy products for their S/4HANA equivalents. The right choice depends on how much unused entitlement you hold and how aggressively you intend to re-map. Customers with large shelfware positions sometimes find that credit for unused licences materially offsets the new contract — but only if that entitlement is recognised before the negotiation, not discovered after signature.
Whichever path you take, the negotiating leverage comes from the same source: a defensible, evidence-backed user classification that you can stand behind line by line. When you can show exactly why a given population belongs in a lighter category, the conversation shifts from SAP's default mapping to your substantiated one.
Common pitfalls
The first pitfall is letting the conversion timeline dictate the analysis. Re-mapping under deadline pressure pushes teams toward the fast, mechanical like-for-like conversion — the most expensive outcome. The second is treating the FUE number as fixed. It is an output of your classification choices, and those choices are negotiable. The third is ignoring future growth: a contract sized tightly around today's optimised base can become a constraint if headcount or transaction volume rises, so model a realistic growth band rather than a single point estimate. The fourth is forgetting that conversion is not the only option — a stable ECC estate can sometimes be better served by third-party support while the S/4HANA business case matures.
The bottom line
Mapping legacy SAP licences to S/4HANA roles is a measurement and classification exercise dressed up as a technical migration. The vendor's default is a like-for-like conversion that preserves a decade of over-licensing; the buyer's advantage is a usage-based re-mapping that converts only what each real user actually needs. The work — measuring behaviour, eliminating dead accounts, separating human from system access, and choosing the lightest defensible category — is where the savings live. For a structured engagement on a specific conversion, see our SAP licensing experts.