SAP ECC to S/4HANA Migration Playbook: Licensing Strategy, Cost Control, and Negotiation

The 2027 Deadline: What It Actually Means

SAP's mainstream maintenance for ECC 6.0 and the broader SAP Business Suite 7 ends on December 31, 2027. SAP has confirmed this date will not be extended. After that date, customers on on-premise ECC will have two options: pay for Extended Maintenance (which carries a premium on top of the standard 22 percent support rate), or continue without SAP support and accept increasing operational and regulatory risk.

The framing of 2027 as a hard cliff is somewhat misleading for commercial planning purposes. Extended Maintenance is available through December 31, 2030 — giving ECC customers who miss the 2027 transition window two to three additional years, at elevated cost. Beyond 2030, SAP ERP Private Edition provides a path to 2033 for complex organisations that need more time (discussed in a separate article). The point is not that all ECC customers will be unsupported in 2028 — it is that the further organisations move from the mainstream deadline, the more expensive their SAP relationship becomes, and the less commercial leverage they retain.

For migration planning purposes, the commercial argument is compelling and the urgency is real: enterprises that begin S/4HANA migration preparation in 2026 and target go-live by late 2027 are operating in a window of maximum negotiation leverage with SAP. Those that delay beyond 2027 lose the fiscal pressure that makes SAP's commercial teams generous.

Choosing Your Migration Path

Three migration paths exist for ECC to S/4HANA transitions. The choice of path has significant implications for project cost, duration, technical risk, and — critically — the licensing baseline that emerges at the end of the migration.

Brownfield Migration (System Conversion)

In a brownfield migration, the existing ECC system is technically converted to S/4HANA in place. The database is migrated to SAP HANA, the application layer is upgraded to S/4HANA, and existing configurations, master data, and customisations are preserved to the extent they are compatible with the new system. Custom code is remediated where necessary using SAP's custom code analysis tools.

Brownfield timelines run from 12 to 24 months for most enterprise implementations, extending to 36 months for highly complex or customised environments. The approach carries lower transformation risk — the system remains closer to what the organisation knows — but it also carries the risk of inheriting technical debt and suboptimal configurations that a greenfield redesign would eliminate.

From a licensing perspective, brownfield migrations often produce a like-for-like conversion of the ECC user base to S/4HANA user types. This is not automatically favourable: the S/4HANA user type model (Advanced, Core, Self-Service, and Occasional) is structured differently from ECC named users, and the mapping between the two can produce surprises. Users who were counted as Limited Users in ECC may need Core or even Advanced licences in S/4HANA depending on the specific transactions they perform in the new system. A licensing baseline review — establishing exactly what the organisation will owe after migration before committing to the migration contract — is essential in every brownfield project.

Greenfield Migration (New Implementation)

In a greenfield migration, the organisation implements S/4HANA from scratch using SAP's standard model and best-practice processes, migrating only clean data from ECC. The ECC system is effectively retired and replaced. Business processes are redesigned around S/4HANA's native capabilities.

Greenfield is the highest-risk and highest-cost migration path in terms of project investment, typically running 18 to 36 months and requiring substantial business change management effort. The return is a cleaner S/4HANA implementation without accumulated technical debt, and the opportunity to rationalise processes and user populations more aggressively than a brownfield conversion allows.

The licensing upside of greenfield is that it creates a clean slate: the organisation is not constrained by its existing ECC user assignments. A greenfield project team that optimises the S/4HANA user model from the outset — using Self-Service and Occasional user types wherever the new processes allow — can achieve a lower per-user licensing cost than a brownfield conversion that reproduces the ECC user assignments in a new system.

Bluefield Migration (Selective Data Transition)

The bluefield approach, also called Selective Data Transition, is a hybrid that combines elements of both brownfield and greenfield. Technical components of the ECC system are converted to S/4HANA, but specific processes, data domains, or organisational structures are redesigned using greenfield methodology. Only relevant, clean data is migrated rather than a bulk data carry-forward.

Bluefield timelines are typically 12 to 20 months — shorter than greenfield and comparable to brownfield for most enterprise sizes. The approach requires more planning and architectural work upfront but produces better outcomes than brownfield for organisations with significant process complexity or data quality challenges. It is increasingly the preferred path for enterprises with complex SAP estates that want to modernise without the full risk and cost of a greenfield programme.

How S/4HANA Migration Changes the Licence Baseline

This is the licensing dimension of ECC to S/4HANA migration that most enterprises fail to model adequately before signing the migration contract. The shift from ECC's named user model to S/4HANA's user type model is not a neutral mapping — it is a commercial event that reshapes what the organisation pays for user licences going forward.

The ECC Named User Model

ECC licensing uses named user types: Professional, Limited Professional, ESS (Employee Self-Service), Developer, and others. The Professional user type grants broad system access; Limited Professional licences cover specific functional areas; ESS is for employees using self-service HR functions. The mapping from job role to user type in ECC is well understood, and most enterprises have years of SAP audit history that has refined their understanding of which roles require which user types.

The S/4HANA User Type Model

S/4HANA on-premise uses a simplified user type model: Advanced User (the broadest access, equivalent to Professional), Core User (more focused access, typically assigned to functional specialists), and Employee/Self-Service users for HR-type interactions. S/4HANA Cloud uses Full User Equivalents (FUE) — a weighted model where Core Users count as 0.2 FUE and Self-Service users count as 0.033 FUE against the Advanced User (1.0 FUE) baseline.

The implications of this model change depend entirely on how the mapping is constructed. An organisation that maps every ECC Professional user to an S/4HANA Advanced user produces a like-for-like conversion with no cost change. An organisation that analyses which former ECC Professional users only need Core-level access in S/4HANA — because the new system's simplified processes require less system breadth than ECC did — can reduce its user licence baseline. Conversely, an organisation that maps ECC Limited Professional users to S/4HANA Advanced users because the new system requires broader access for equivalent functions will see its licence cost increase.

The critical practice is to perform the user type mapping exercise independently, using the actual S/4HANA transaction profiles planned for the new system, before negotiating the migration licence terms with SAP. Allowing SAP to propose the user type mapping and then negotiating from that proposal consistently produces worse outcomes than arriving with your own mapping and defending it.

Hidden Licensing Costs That Emerge Post-Migration

Beyond the user licence baseline change, five categories of licensing cost frequently emerge in S/4HANA implementations that were not present or were not material in ECC.

SAP Digital Access for New Integration Architecture

S/4HANA migrations almost universally involve redesigning the enterprise integration architecture. New integration patterns — often built on SAP BTP, MuleSoft, or other middleware — create new digital access obligations that did not exist in the ECC integration landscape. If the migration introduces a new e-commerce platform integration, a new Salesforce CRM connection, or a new automated order management workflow, each of these creates Digital Access document obligations that must be licensed before go-live.

The most common failure mode is for integration architects to design new S/4HANA integrations without involving the licensing team. The Digital Access exposure from a new integration discovered in post-production audit is significantly more expensive than the same exposure identified and licensed pre-go-live, because post-go-live SAP has far more commercial leverage.

SAP Business Technology Platform Credits

S/4HANA's architecture assumes that certain integration and extension scenarios are built on SAP BTP. Custom Fiori apps deployed through BTP, SAP Integration Suite connections, SAP Build Process Automation workflows, and SAP Analytics Cloud integrations all consume BTP credits. ECC customers transitioning to S/4HANA frequently have no prior BTP consumption baseline — their first BTP credit pool commitment is an estimate, and SAP's standard BTP sizing models consistently underestimate production consumption.

The practical risk is signing a RISE with SAP or S/4HANA contract that includes a BTP credit bundle sized for a pre-production estimate, going live, and then discovering mid-year that the credit pool will be exhausted six months before renewal. At that point, the only option is to purchase additional credits at a higher per-credit rate than was available at contract signature. Right-sizing BTP credits from the bottom up — service by service, extension by extension — before signing is not optional for financially disciplined migrations.

Premium Fiori Application Licensing

Standard SAP Fiori apps for S/4HANA are included in the S/4HANA user licence at no additional charge. Premium Fiori apps — typically those involving analytics, advanced planning, or cross-system functionality — carry separate licensing requirements. Implementations that assume all Fiori apps are included in the base S/4HANA licence and build user experiences around premium apps without a licensing review create unexpected licence costs at or after go-live.

Third-Party Maintenance Transition Costs

Enterprises running ECC on third-party maintenance (Rimini Street, Spinnaker Support) face a specific challenge: third-party maintenance providers do not cover S/4HANA. The migration necessarily returns the organisation to SAP Enterprise Support at 22 percent of net licence value. For organisations that had substantially reduced their SAP support cost through third-party maintenance, this represents a material increase in the annual cost baseline that must be factored into the migration business case.

RISE with SAP vs On-Premise S/4HANA: The Commercial Analysis

For most ECC customers, the migration decision now includes a fundamental deployment architecture choice: migrate to on-premise S/4HANA (BYOL), or move to RISE with SAP (SAP's managed cloud subscription). SAP's commercial motion strongly favours RISE — account teams are incentivised to convert on-premise customers to RISE subscriptions. Evaluating the decision independently of SAP's advocacy is critical.

RISE with SAP: What the Subscription Includes and Costs

RISE with SAP packages S/4HANA Cloud Private Edition software, cloud infrastructure (hosted on a SAP-partnered hyperscaler), technical managed services covering system administration, patching, and upgrades, and a defined quantity of BTP credits. The subscription is per-user, per-month, with a minimum three-year commitment.

The headline RISE per-user rate — typically $60 to $95 per user per month for large enterprise deployments at negotiated rates — appears competitive against the combined cost of on-premise S/4HANA licences plus maintenance (22 percent per year) plus infrastructure. The comparison holds only if the RISE subscription is modelled against the full on-premise TCO including infrastructure, DR, and system management costs — which it usually is not in SAP's proposals.

Over a five-year RISE horizon, the subscription cost exceeds the on-premise licence plus maintenance cost for most large enterprise scenarios. The economic case for RISE is based on eliminating infrastructure capital expenditure and system management labour — costs that may or may not be material to the customer's specific situation. Enterprises with existing SAP HANA infrastructure and established SAP Basis teams typically find on-premise S/4HANA more economical over a five-year horizon. Enterprises without that infrastructure and those skills may find RISE genuinely cost-competitive once the build-versus-buy analysis is done honestly.

Contractual Risks in RISE

RISE introduces contractual dynamics that are materially different from on-premise SAP. SAP does not allow contractual ramp-downs in RISE — the subscription volume is committed for the entire term. If the customer's user count decreases (through restructuring, system consolidation, or business change), the contractual obligation does not decrease proportionally. This rigidity is a significant hidden cost for organisations in dynamic operating environments.

RISE also creates a longer-term commercial dependency on SAP's managed infrastructure and support model that can be difficult and expensive to exit. The migration to and from RISE involves system migration effort, data migration work, and process disruption that creates high switching costs. SAP's pricing power within RISE renewals is consequently higher than in on-premise renewal negotiations where third-party maintenance and infrastructure alternatives create genuine competitive alternatives.

The Migration as a Negotiation Opportunity

Every ECC to S/4HANA migration is a once-in-a-generation opportunity to restructure the entire SAP commercial relationship. The licensing quantities change, the product mix changes, the deployment model may change, and the contract term resets. SAP has strong commercial incentives to execute this transition — they want customers to migrate before the maintenance deadline creates pressure — and those incentives translate directly into negotiation leverage for buyers who understand how to apply it.

Timing: Start 12 to 18 Months Before You Need to Sign

The optimal negotiation timeline for a migration-linked SAP commercial discussion starts 12 to 18 months before the target migration go-live date. At that point, the organisation knows its migration architecture, understands its future user type profile, has modelled its BTP and Digital Access requirements, and is in a position to present SAP with a complete commercial proposal. SAP's account teams are also aware that the customer's migration programme will proceed with or without a signed SAP contract — the customer has options — which creates genuine negotiating urgency.

Customers who come to SAP 60 days before they need to sign a migration contract, because the project programme requires software to be available, are negotiating under time pressure that SAP will exploit. The quality of commercially prepared, time-flexible negotiations versus programme-forced, time-pressured negotiations is one of the most consistent patterns in enterprise SAP negotiation outcomes.

What to Negotiate in a Migration Deal

A comprehensive migration commercial negotiation covers all of the following:

• Migration credits — credit for the licence value in your existing ECC estate applied against the new S/4HANA licence cost. Market benchmarks for migration credits range from 40 to 70 percent of the existing licence net value. SAP's first offer is typically lower; the ceiling is a matter of negotiation.
• Maintenance holiday — suspension of Enterprise Support charges for 6 to 12 months during the active migration period, when the customer is effectively paying for both the old system (ECC support) and the new system (S/4HANA or RISE subscription) simultaneously.
• Dual-use rights — explicit contractual permission to run both ECC and S/4HANA simultaneously during the transition period without paying for both at full rate.
• BTP credit right-sizing and capping — BTP credits that reflect an independently modelled consumption estimate, with provisions for capped overages and rate protection if consumption exceeds the committed pool.
• Digital Access coverage — explicit scope definition in the contract of which integration scenarios are covered by which licences, and at what Digital Access rate for new integrations introduced in the S/4HANA architecture.
• RISE pricing and term flexibility — for RISE customers, ramp provisions that allow limited user count adjustments within the subscription term, and pricing protection for renewal that does not expose the customer to unilateral rate increases at the end of the committed period.

Ten Common Migration Licensing Traps

These are the patterns we see most frequently in migration engagements that result in higher-than-necessary licensing costs:

1. Accepting SAP's user type mapping without independent analysis. SAP maps ECC user types to S/4HANA in a way that preserves or increases SAP's revenue. Independent mapping protects the customer's position.
2. Not modelling Digital Access for the new integration architecture. The new integrations that make S/4HANA more valuable also create new Digital Access obligations that must be licensed.
3. Undercommitting BTP credits and facing overage charges mid-year. Bottom-up BTP consumption modelling is the only reliable basis for credit pool sizing.
4. Signing the migration contract before the S/4HANA go-live date is confirmed. SAP's implementation partners have incentive to begin work; the licensing contract gives SAP control of the migration timeline from SAP's perspective. Sign the contract when the go-live date is confirmed, not when the project starts.
5. Treating the migration as an IT project rather than a commercial negotiation. The migration commercial team and the IT programme team must be aligned, and commercial strategy must inform programme timeline decisions.
6. Missing the maintenance holiday window. The dual-use period when both ECC and S/4HANA are live is one of the highest-cost periods of the migration. Maintenance holiday provisions must be in the contract before the migration starts, not negotiated retrospectively.
7. Accepting RISE without a genuine on-premise TCO comparison. SAP's RISE proposals are not neutral comparisons — they are advocacy documents. An independent five-year TCO model is required for any rational RISE decision.
8. Ignoring premium Fiori licensing in the application design phase. Application architects should confirm the licensing status of every Fiori app in the design before user experience prototyping commits the organisation to apps that require additional licensing.
9. Not negotiating third-party maintenance exit costs into the migration deal. Customers moving from third-party maintenance to RISE or SAP Enterprise Support are increasing their annual support spend. This increase should be offset by improved terms on the S/4HANA licence or subscription.
10. Allowing the 2027 deadline to create negotiation urgency that benefits SAP. SAP's account teams know which customers are facing 2027 deadline pressure. The customer's negotiating position is strongest when they credibly demonstrate they have options — Extended Maintenance, ERP Private Edition, or even a third-party maintenance continuation — and are choosing to migrate because it is commercially optimal, not because they have no alternative.