Mapping Legacy SAP ERP Licenses to S/4HANA Roles.

The migration from legacy SAP named user licenses to the S/4HANA Full Use Equivalent model is a remap, not a copy, and a default copy almost always over counts the buyer.

Why does S/4HANA require a license remap?

S/4HANA requires a remap because it retires the legacy named user catalog and prices on the Full Use Equivalent model instead. The old professional, limited professional, and employee user types from SAP S/4HANA do not carry forward unchanged.

SAP describes the contractual model in its software licensing materials. The migration is the moment your user base gets re priced, which makes it the moment to get the classification right.

What changes in the catalog

• Named user types retire: the legacy catalog is replaced, not extended.
• FUE becomes the denomination: all users convert to a single unit.
• Conversion ratios apply: lighter roles convert at a fraction of an FUE.

Why a copy is the wrong default

Copying the legacy assignment forward assumes the historical license type matched real usage. It rarely did. Licenses get assigned conservatively and never reviewed, so a copy bakes years of over assignment into the new model.

How does the SAP Full Use Equivalent model work?

The FUE model converts every user into a fraction or multiple of one Full Use Equivalent, based on the role they perform. A heavy professional role counts as a full FUE, while self service roles count as a small fraction.

Because the whole estate collapses into one denomination, the conversion ratios are the entire game. A small ratio change applied across thousands of users moves the bill materially.

The role categories that matter

• Advanced use: full professional roles, counted as a full FUE.
• Core use: functional roles, counted at a defined fraction.
• Self service: light roles, counted at the smallest fraction.

What is the over count trap in S/4HANA remapping?

The over count trap is mapping every legacy professional user to a full FUE without testing real activity. It is the path of least resistance and it systematically inflates the count.

SAP measurement tooling reports assignment and consumption. The SAP measurement and licensing documentation describes how usage is recorded, and the SAP agreement terms set the rules. That record is the evidence that defeats the default over count.

Where the over count hides

• Dormant professionals: assigned a heavy license, no recent activity.
• Read only users: consuming reports, not transacting.
• Shared and service accounts: counted as users when they are integrations.

Where the common advice on S/4HANA license mapping is wrong

The standard system integrator approach is to lift the existing named user assignment and convert it one to one into the FUE model. We disagree. In roughly 20 to 30 S/4HANA remaps we ran across 2024 and 2025, the one to one copy over counted the buyer in nearly every case, by 15 to 25 percent. The historical license type was assigned conservatively years earlier and never reconciled against what people actually do. The buyer side move is to classify users by observed activity from the system record, then map to FUE from that evidence, and only then negotiate the conversion ratios. A remap built on evidence is both cheaper and far easier to defend in an audit than one built on a copied assumption.

In an S/4HANA remap, the legacy license type is a guess from years ago. The system activity is the fact. Negotiate from the fact.

How do you build an evidence based S/4HANA user mapping?

An evidence based mapping starts from observed activity, not from the license catalog. You pull transaction and consumption data per user, classify by what each person actually does, then convert to FUE from that classification.

This sequence also protects you. If SAP challenges the mapping, you answer with system evidence rather than opinion, which shifts the audit conversation onto your ground.

The steps in order

• Extract activity: per user transaction and consumption over a representative period.
• Classify by behavior: advanced, core, or self service from what they did.
• Convert and negotiate: apply FUE ratios, then negotiate the ratios themselves.

Why timing the remap matters

The remap lands during the S/4HANA commercial conversation, so the classification work has to be done before, not during, the negotiation. A buyer who arrives with evidence sets the count. A buyer who arrives without it accepts the vendor count.

What should a buyer do next?

1. Extract per user transaction and consumption data from the current SAP system over a representative period.
2. Classify every user by observed behavior into advanced, core, or self service, ignoring the legacy license type.
3. Flag dormant professional users, read only users, and service accounts that should not map to a full FUE.
4. Apply the FUE conversion ratios to the evidence based classification, not to the copied assignment.
5. Negotiate the conversion ratios themselves, since a small ratio change across the estate moves the bill.
6. Retain the activity extract as audit defense in case SAP challenges the remap.
7. Complete the classification before the S/4HANA commercial negotiation opens, so you set the count.

White Paper · SAP

SAP named user licenses. The user classification audit

Read it free.

Read the white paper

Frequently asked questions

Why do SAP ERP licenses need remapping for S/4HANA?

Because S/4HANA retires the legacy named user catalog and prices on the Full Use Equivalent model. The old professional and limited professional types do not carry forward, so each user must be reclassified and converted, which is a remap rather than a copy.

What is the SAP Full Use Equivalent model?

The Full Use Equivalent, or FUE, model converts every user into a fraction or multiple of one standard unit based on the role they perform. Heavy professional roles count as a full FUE, while self service roles count as a small fraction, so conversion ratios drive the cost.

Why does a one to one license copy over count?

Because the historical license assignment was usually set conservatively years earlier and never reconciled against real usage. Copying it forward bakes that over assignment into the new model, which is why default copies over count by 15 to 25 percent in our experience.

How do you avoid over counting in an S/4HANA remap?

Classify users by observed system activity rather than by their legacy license type, then convert that evidence to FUE. Dormant professionals, read only users, and service accounts almost always map to a lighter unit than the old assignment implied.

What evidence supports an S/4HANA user mapping?

Per user transaction and consumption data from the SAP system over a representative period. That record shows what each person actually does, which is the correct basis for FUE classification and the strongest defense if SAP challenges the count.

When should the remap be done?

Before the S/4HANA commercial negotiation opens. The remap lands during the pricing conversation, so the classification work must be complete beforehand. A buyer with evidence in hand sets the count rather than accepting the vendor count.

Do conversion ratios get negotiated?

Yes. Because the whole estate collapses into the FUE denomination, the conversion ratios are negotiable and they decide the bill. A small ratio change applied across thousands of users moves cost materially, so the ratios are a key lever.

Can service accounts be excluded from FUE counts?

Service and integration accounts should not be mapped as if they were professional users. Treating them correctly, often under digital access rather than named user terms, removes a common source of over counting in the remap.