SAP Licence Migrations: How ECC to S/4HANA Changes Your Licence Baseline

Why SAP ECC to S/4HANA Migration Is a Licence Reset

SAP ECC and SAP S/4HANA operate on fundamentally different licensing models. ECC uses a named-user model with a relatively flat licence type structure: Professional (now known as Full Use), Limited Professional, Employee Self-Service, and a number of specialist types. The S/4HANA on-premise model introduces a four-tier user structure — Professional, Functional (Limited Professional), Productivity (Employee Self-Service), and Developer — with significantly different pricing across tiers.

The migration from ECC to S/4HANA requires every user in your ECC landscape to be reclassified into one of the four S/4HANA user types. This reclassification is not a mechanical one-to-one mapping. It requires analysis of each user's actual system behaviour — the transactions they run, the business processes they support, and the functional scope of their access — to determine which S/4HANA type is commercially appropriate.

SAP's default migration methodology tends to map users to the highest applicable tier. Organisations that accept SAP's default conversion proposal without independent analysis consistently end up with a higher Professional user count than their actual usage warrants, paying for the most expensive tier for users whose actual work would qualify for the more affordable Functional or Productivity tiers.

The Four S/4HANA User Types: What Each Covers

Professional User

The Professional user is the highest and most expensive S/4HANA user type. It covers unrestricted access to all S/4HANA functions and is appropriate for users who perform complex, cross-functional business processes — finance managers running month-end close, procurement directors creating complex contract arrangements, or logistics managers who need to work across the full supply chain module scope. Professional users typically represent 20 to 40% of the ECC user base when correctly classified, not the 60 to 80% that SAP's default conversion often produces.

Functional User (Limited Professional)

The Functional user covers access to specific, defined S/4HANA functional areas. It is appropriate for users who work within a defined business process scope — accounts payable clerks who process invoices, warehouse operatives who confirm goods receipts, or customer service agents who manage service orders. The Functional user licence is significantly less expensive than the Professional user licence and is the correct classification for a large proportion of ECC users who were historically licensed as Professional or Limited Professional by default.

Productivity User (Self-Service)

The Productivity user is designed for incidental or self-service SAP access — employees who submit time sheets, access payslips, raise travel expense claims, or perform basic procurement self-service. This is the equivalent of the ECC Employee Self-Service licence and is the most affordable user type. It covers the large population of employees in an organisation who interact with SAP occasionally for transactional self-service purposes rather than as regular business process participants.

Developer User

The Developer user licence covers technical users who build, configure, test, and maintain S/4HANA systems. It is appropriate for ABAP developers, Basis administrators, system configurators, and functional consultants who work on system development and configuration rather than business process execution. The Developer licence covers both productive development access and test system access, which is an important distinction from the ECC development licence model.

Migration Credits: What SAP Offers and What You Should Negotiate

SAP's migration credit programme provides credits against the S/4HANA conversion cost for existing perpetual ECC licence investments. The principle is that customers who have already paid for ECC licences should receive commercial recognition for that investment when converting to S/4HANA. In practice, the migration credit calculation is highly variable and depends on the age of the existing licences, the current maintenance level, the conversion volume, and the commercial relationship history with SAP.

SAP's standard migration credit offer is rarely the best achievable outcome. The migration credit negotiation is a commercial event where SAP has strong incentive to convert customers from perpetual licences (which generate ongoing support revenue of approximately 22% of net licence value) to subscription models (which generate higher per-user annual fees in most cases). The credit offered is calibrated to make the conversion attractive while maximising SAP's long-term revenue from the account.

Independent analysis of the migration credit value — comparing the SAP offer against the actual economic value of the perpetual licence assets being surrendered — is essential before agreeing to a conversion. Customers who negotiate with independent advisory support consistently achieve significantly better credit terms than those who accept SAP's first offer. The negotiating leverage is highest before the migration commitment is made, not after.

Digital Access (DDLC) Exposure During Migration

One of the most significant and most frequently overlooked licence risks in an S/4HANA migration is the indirect access (DDLC) exposure created during the parallel running period. When both ECC and S/4HANA systems are operational simultaneously, third-party integrations that were connected to ECC may need to be reconnected to S/4HANA, connected to both systems temporarily, or redirected as part of the technical migration sequence.

During this parallel period, document creation events triggered by third-party systems in either ECC or S/4HANA are potentially chargeable under the DDLC model. If the ECC landscape already has undisclosed indirect access exposure — integrations creating documents without a corresponding DDLC licence — the S/4HANA migration amplifies that exposure because the new S/4HANA environment will be subject to a fresh DDLC review at go-live.

SAP's migration advisory team will conduct a landscape review as part of the migration engagement. This review will identify third-party integrations and assess their DDLC implications. Customers who have not independently assessed and documented their indirect access position before SAP conducts this review are negotiating from a position of ignorance — SAP knows their DDLC exposure before they do.

The correct approach is to conduct an independent indirect access assessment before engaging SAP on the S/4HANA migration. This establishes your own DDLC baseline, identifies existing undisclosed exposure, and allows you to develop a migration plan that addresses the indirect access position as part of the commercial negotiation rather than discovering it as a surprise cost after the migration contract is signed.

The Two Migration Paths: Product Conversion vs Contract Conversion

Product Conversion

Product conversion is the technical migration path where an existing SAP ECC system is converted in-place to S/4HANA. From a licensing perspective, product conversion involves transitioning the existing perpetual licences from the ECC product line to the S/4HANA product line, with migration credits applied to offset the conversion cost. Product conversion preserves the perpetual licence model — the customer continues to own the software licences and pay annual support fees of approximately 22% of net licence value.

Product conversion is typically preferable for organisations with large, well-optimised perpetual licence portfolios where the long-term economics of ownership are more favourable than RISE with SAP subscription pricing. The critical constraint is that product conversion requires the customer to manage their own infrastructure (whether on-premise or BYOL on hyperscaler), which requires technical capability that not all organisations possess.

Contract Conversion (to RISE with SAP)

Contract conversion migrates an ECC customer to RISE with SAP — SAP's managed cloud subscription model. In a contract conversion, the customer surrenders their perpetual licences in exchange for a RISE with SAP subscription that bundles S/4HANA Cloud Private Edition, managed infrastructure, and certain BTP credits. The annual subscription fee replaces both the support fee and the infrastructure cost.

RISE with SAP simplifies the commercial relationship and removes infrastructure management responsibility, but introduces subscription price escalation risk, scope limitations compared to the original perpetual licence portfolio, and a lock-in to SAP's pricing model for the subscription term. The 5-year TCO comparison between product conversion (perpetual BYOL) and contract conversion (RISE) must be conducted independently before committing to either path. SAP's own TCO models are constructed to favour the RISE outcome.

S/4HANA Migration and the 2027 Deadline: Commercial Leverage

SAP has set December 31, 2027 as the end of mainstream maintenance for SAP ERP 6.0 enhancement packages 1 through 5, with extended maintenance available through 2030 for an additional fee. This deadline creates time pressure that SAP's account teams actively use to accelerate migration commitments. Customers who are approaching this deadline without a committed migration plan are in SAP's strongest commercial position for driving RISE with SAP conversions.

The commercial reality is that this deadline also gives customers leverage, not just SAP. SAP needs the ECC customer base to migrate to S/4HANA or RISE — it is fundamental to SAP's cloud transition strategy and its fiscal year-end revenue targets (SAP's fiscal year ends December 31). Customers who have not yet committed to a migration path are valuable prospects that SAP will negotiate with. Organisations that engage advisory support and negotiate migration terms from a position of commercial knowledge consistently achieve significantly better terms than those who respond to the deadline pressure without preparation.

Optimising the Migration: Seven Key Actions

1. Conduct Independent User Reclassification Before Engaging SAP

Run an independent analysis of your ECC user base that maps each user's actual transaction usage to S/4HANA user types. This analysis will typically demonstrate that 30 to 50% of users who SAP's default conversion would classify as Professional qualify for Functional or Productivity classification. The savings from correct classification at the point of migration are significantly greater than the savings achievable after the migration contract is signed.

2. Assess Your Full DDLC Exposure Before the Migration Dialogue Begins

Commission an independent indirect access assessment before SAP's migration team conducts their landscape review. Document every third-party integration, the document types and volumes each integration generates, and your contractual DDLC entitlement. Enter the migration negotiation knowing your DDLC position — do not allow SAP to be the first party to define it.

3. Negotiate Dual-Use Rights with a Defined Buffer Period

Contractual dual-use rights allow parallel operation of ECC and S/4HANA during the migration period without incurring double licence costs. Negotiate a minimum 12-month dual-use period with a 6-month extension option. Migration projects consistently experience delays, and contractual protection for extended parallel operation is essential.

4. Optimise Your Perpetual Licence Portfolio Before the Conversion Valuation

The migration credit calculation is based in part on the current state of your perpetual licence portfolio. Eliminating shelfware, cleaning up inactive user accounts, and removing unused module entitlements before the conversion valuation date reduces the base value against which credits are calculated — which may seem counterintuitive but reflects the reality that you will pay annual support on the post-migration licence scope, and paying support on unused licences you have surrendered for credit is not commercially efficient.

5. Independently Model RISE vs BYOL over a 5-Year Horizon

Commission an independent 5-year TCO model that compares RISE with SAP subscription costs (including inflation clauses and scope escalation) against BYOL on hyperscaler with optimised perpetual licences. This model must use real hyperscaler pricing for your target environment, not SAP's indicative infrastructure cost figures. The outcome will be sensitive to your specific licence mix, infrastructure requirements, and negotiated terms, and the result is frequently different from SAP's own TCO presentation.

6. Secure Audit Protection in the Migration Contract

The migration contract should include audit protection provisions that limit the look-back period for compliance claims, establish the agreed measurement methodology for the new S/4HANA landscape, and define how indirect access will be measured and reported going forward. These provisions are negotiable at the time of contract execution and provide long-term commercial protection that is not available retrospectively.

7. Engage Independent Advisory Support Before the First SAP Meeting

The migration conversation with SAP's account team and migration advisory team begins with a commercial agenda that SAP's team has prepared. Independent advisory support that has worked through 500+ SAP engagements, understands SAP's migration methodology, and has negotiated migration credits and conversion terms across many comparable customer situations is the most effective investment before that conversation begins.

Common Migration Licence Mistakes and How to Avoid Them

The most common and most costly mistake in SAP licence migrations is accepting SAP's default user classification mapping without independent review. SAP's conversion tool maps ECC user types to S/4HANA user types using a conservative algorithm that errs toward the higher (more expensive) classification. For a customer with 5,000 ECC users, this default mapping may result in 3,500 Professional users when independent analysis would support 1,500 Professional, 2,000 Functional, and 500 Productivity users. The annual cost difference between these two classifications can be measured in the millions of euros, compounding annually over the support term.

The second common mistake is signing the RISE with SAP contract before independently validating the module scope. RISE includes S/4HANA Cloud Private Edition and managed infrastructure, but the specific SAP modules covered by the subscription scope vary by contract and must be explicitly enumerated. Modules that are not in the agreed scope require separate licensing and separate pricing. Discovering this gap after go-live, when the contractual remediation options are limited, is a consistently painful and expensive outcome that independent pre-signing review prevents.

The third mistake is neglecting to use the migration event as an opportunity to clean up legacy licence obligations. Every SAP ECC landscape contains historical licence purchases — software acquired for projects that did not proceed, modules deployed for business units that no longer exist, and engine licences sized for business volumes that have changed materially. The migration is the natural commercial event at which these legacy obligations can be reconciled and the new licence baseline established cleanly. Organisations that migrate the legacy complexity into their S/4HANA contract without review carry unnecessarily high support costs forward indefinitely.