Migrating from SAP ECC 6.0 to SAP S/4HANA
Timeline Pressure – ECC End of Support in 2027
SAP has set a firm deadline for the end of mainstream maintenance for SAP ECC 6.0 (Business Suite 7) on December 31, 2027. Optional extended maintenance is available until 2030 at an additional cost.
Notably, only customers on ECC 6.0 enhancement packs 6, 7, or 8 are eligible for support through 2027; those on older releases (EHP 0–5) will see mainstream support end in 2025, with no extension offered. In other words, the ‘2027 deadline’ assumes you’ve kept ECC relatively up to date – if not, the clock may run out even sooner.
SAP’s extended maintenance (through 2030) isn’t free – it carries a premium of about 2% on top of standard support costs. Furthermore, SAP has indicated this extended support is intended primarily for customers who commit to an S/4HANA migration; in fact, SAP only offers the 2028–2030 extension to those who plan to purchase S/4HANA, effectively using it as a carrot to encourage migration.
It’s widely believed that SAP will not delay these end-of-support dates again, after pushing the 2025 deadline out to 2027 once. Prolonging ECC usage beyond 2027 without a migration plan could result in either paying steep fees or seeking alternative support outside of SAP.
This timeline creates significant urgency. Surveys as of 2024 show a majority of SAP customers have not yet moved to S/4HANA – roughly 63% of ECC customers still hadn’t even licensed S/4HANA by mid-2024.
Given that a full ECC to S/4HANA migration can take 18 to 36 months (or longer) for large enterprises, time is perilously short. Waiting until 2026 to start is a recipe for schedule pressure. Indeed, industry analysts warn that rushing a last-minute project in 2026 or 2027 will drive up costs and deplete resources.
As the deadline nears, demand for experienced S/4HANA consultants is expected to far outstrip supply. Consulting rates could spike by 10–20% in the final year, and some estimates suggest that demand for S/4 talent may be three times the available supply by 2027. In short, delaying increases the risk of paying a premium for scarce expertise or missing the deadline altogether.
Adding to the pressure, migration complexity is non-trivial. A recent study found that over 60% of companies experience budget overruns, timeline delays, or quality issues during their S/4HANA projects.
On average, S/4 migrations are taking 30% longer than planned, with only 8% of companies achieving their original go-live date. Nearly two-thirds also reported serious post-migration quality problems, caused by factors such as scope creep and weaknesses in project management. This underscores that moving to S/4HANA is a major transformation that demands careful planning, sufficient time, and skilled execution. Companies cannot bank on a quick or easy upgrade at the last minute.
Recommendations for CIOs:
1) Treat the 2027 deadline as immovable and plan backward – if you need 24 months or more for migration, initiate your project no later than 2024.
2) If you’re on an older ECC release, factor in that your support deadline might be 2025; consider an interim enhancement pack upgrade or third-party support if needed to bridge the gap.
3) Engage stakeholders now to secure the budget and resources early, avoiding inflation in consulting rates and talent shortages projected as 2027 approaches.
4) Open a dialogue with SAP early – customers who show a clear S/4 roadmap may get more flexibility (for example, access to extended maintenance through 2030 or special incentives discussed later).
5) Build contingency time into your plan, knowing that many migrations take longer than expected; a realistic timeline with a buffer will reduce pressure if complexities arise.
Migration Strategies – Greenfield vs. Brownfield vs. Hybrid
One of the first strategic decisions is how to technically approach the move from ECC to S/4HANA. The classic options are often termed “Greenfield” or “Brownfield” implementations, with a newer “Hybrid/Bluefield” approach emerging as a middle ground.
- Greenfield Implementation – This is a brand-new implementation of S/4HANA from scratch, essentially starting with a clean slate. The system is built from scratch (either in a new environment or alongside the old one), and the data is migrated over. This approach resembles a full re-engineering: you redesign business processes to fit S/4HANA best practices, configure a new system, and then load legacy data and train users on the new platform. Pros: It offers maximum freedom to leverage S/4HANA’s new capabilities and standardize or simplify processes, without being constrained by past customizations. It’s ideal if the current system is heavily customized or outdated – you can shed “technical debt” and avoid carrying forward inefficiencies. Over the decades, ECC systems have accumulated bolt-ons and workarounds; Greenfield lets you rethink processes for a modern ERP. Cons: Greenfield is disruptive, time-consuming, and costly, as it involves a full redesign of processes and the reimplementation of functionality. Data migration can be complex, as it involves deciding which historical data to transfer. You may also lose direct access to some legacy data in the new system. Change management is significant – users face an entirely new system and workflows. Greenfield projects often have longer durations and higher risk due to the “from scratch” scope.
- Brownfield Implementation – This refers to converting an in-place system or performing a technical upgrade of an existing ECC system to S/4HANA. Essentially, you keep your current processes and customizations and upgrade the software underneath to S/4HANA. Some describe it as a guided migration: you migrate the ECC database to HANA and install S/4HANA, transferring your configurations and data with minimal changes. Pros: Brownfield is typically faster and less disruptive than greenfield. It preserves investments in current configurations, custom code, and integrations, which are beneficial if those are working well for the business. There’s less retraining required since many processes remain familiar. Cons: It can be an “upgrade in place,” potentially carrying forward inefficient or outdated processes. There’s less opportunity to re-engineer or simplify, so that you might bring along the baggage of years of modifications. Some innovations in S/4HANA may not be fully realized if you don’t adjust your processes. Also, a Brownfield conversion still involves significant technical effort (data and custom code remediation to ensure compatibility with S/4). It’s not entirely risk-free – thorough testing is needed to ensure the converted system works as expected.
- Hybrid/“Bluefield” Approach – Many enterprises find themselves drawn to a middle path, often referred to as “Bluefield” (a term popularized by certain SAP partners) or Selective Data Transition in SAP terminology. This approach combines elements of both strategies. Practically, it might involve setting up a new S/4HANA instance, such as a greenfield instance, but selectively migrating configurations and data from the old system, rather than starting from scratch. For example, using specialized tools, you can transfer specific company codes, modules, or data sets from ECC to S/4, while leaving behind obsolete data or processes. Pros: Bluefield allows for a phased migration – you can migrate in chunks (by business unit or module), which reduces risk and downtime. It also lets you preserve what works well (from ECC) and reengineer what doesn’t, giving you flexibility. It can minimize business disruption compared to a full Big Bang cutover. Cons: The hybrid approach can be complex to plan and execute, often requiring specialized data migration tools and expertise. It still requires careful data reconciliation and can incur costs somewhere between those of a pure brownfield and a greenfield project. Additionally, not all scenarios fit neatly into selective migration – some data or customizations may not transfer cleanly and may need to be reimplemented anyway.
There is no one-size-fits-all answer – each approach has merits depending on the organization’s situation. For example, a company with relatively vanilla ECC usage and a tight timeline may prefer Brownfield to get to S/4 quickly and then improve incrementally. Conversely, a company with an ECC that is heavily customized or outdated might prefer a Greenfield approach to truly transform and align with best practices, despite the higher upfront effort.
Many large enterprises pursue hybrid strategies, perhaps converting core finance processes using Brownfield methods but implementing new S/4 modules (such as TM and EWM) from scratch, or greenfield methods, and phasing them in over time. It’s also common to perform a brownfield technical conversion and then embark on continuous improvement projects post-migration to refactor processes – effectively a “Brownfield then optimize” approach.
Recommendations for CIOs:
1) Perform a thorough assessment of your current ECC: How customized is it? Which processes are pain points vs. competitive differentiators? This assessment will guide which approach fits. 2) Consider the business appetite for change – if the organization is ready for process transformation, Greenfield (or a hybrid with significant redesign) can deliver more long-term value.
If the business is resistant to change or resources for reengineering are scarce, a Brownfield (technical conversion) with limited scope change may be more pragmatic. 3) Don’t ignore the data migration aspect.
In any approach, plan how you will migrate historical data and determine the actual volume needed in the new system. Greenfield might mean migrating only open items and a few years of history, whereas Brownfield brings all data but might still need archiving. 4) Evaluate downtime tolerance and project risk: Brownfield tools (such as SAP’s conversion tools) can often perform migrations with minimal downtime windows, while Greenfield cutovers may be more extensive.
Balance this against the testing effort – Brownfield will require exhaustive testing of converted custom code; Greenfield requires testing new configurations and data loads. 5) Lastly, engage experienced partners who have done similar migrations.
If considering a Bluefield approach, ensure your implementation partner has proven tools or methodologies (such as SNP or other selective migration frameworks) to avoid ending up in a no-man ‘s-land of partial migration problems.
Weigh the pros and cons in the context of your business goals – e.g., speed vs. process improvement – and choose an approach, or combination of approaches, that aligns with those priorities.
Deployment Options: On-Premises, Cloud, and RISE with SAP
As you plan the move to S/4HANA, you also need to decide on the target deployment model. S/4HANA can be deployed in various ways, primarily: On-Premises (traditional), public or private cloud, or via RISE with SAP (a subscription bundle).
Each option has implications for infrastructure, licensing, and operational responsibility.
- S/4HANA On-Premises (Customer-Managed): This option most closely mirrors the traditional ECC deployment model. You own the S/4HANA software licenses (perpetual) and you decide where to run the system – whether on your data center hardware or in an infrastructure-as-a-service (IaaS) cloud (e.g., AWS, Azure, GCP) that you manage. The key point is, in an on-premises model, you control the environment and upkeep: you handle system installations, upgrades/patches, and choose when to apply enhancements. Licensing is upfront (capital expense for licenses, plus annual maintenance). On-prem S/4HANA offers maximum control and the ability to tailor the system extensively. You can also stick with your preferred infrastructure vendor. Some enterprises choose to run S/4HANA on hyperscaler cloud servers. However, under a traditional license, SAP still considers that “on-premise” from a licensing standpoint because you are using your perpetual licenses on your chosen infrastructure. Considerations: On-prem requires retaining (or developing) the BASIS and infrastructure skills to manage HANA and the S/4 application. You also bear responsibility for ensuring high availability and setting up disaster recovery. However, you schedule upgrades on your timeline (within SAP’s support policy). Cost-wise, you pay a big upfront license fee and yearly maintenance, which some companies prefer as it gives perpetual usage rights beyond any subscription term.
- S/4HANA Cloud (Public or Private Cloud SaaS): SAP also offers S/4HANA in cloud subscription models. S/4HANA Cloud Public Edition is a software-as-a-service (SaaS) multi-tenant offering – very standardized, with SAP hosting and managing the system, and clients consuming it with minimal IT overhead. S/4HANA Cloud Private Edition (often tied to RISE, but also available standalone) is a single-tenant, hosted version that allows for more customization, still delivered as a subscription service on cloud infrastructure managed by SAP or a partner. In both cases, licensing is subscription (annual recurring), not perpetual, and typically measured by usage metrics (often by “Full User Equivalents” or other metrics, discussed later). Pros: Cloud deployments shift the infrastructure burden to SAP or the provider, including hardware, backups, and technical upgrades. This can accelerate implementation (no need to procure hardware or handle low-level setup) and convert ERP to an OPEX model (pay-as-you-go). SAP touts potential TCO savings of up to 20% with a well-optimized cloud deployment compared to on-premises, though actual savings vary. Cloud editions are also the first to receive innovations – SAP often releases new features to S/4HANA Cloud quarterly, whereas on-prem customers wait for yearly updates. Cons: Less flexibility in the timing of upgrades – cloud users are on SAP’s schedule (often referred to as a forced upgrade cadence). Public cloud edition especially has limited customization (you must adapt to SAP’s standard processes as code modification is restricted). There is also a vendor lock-in concern: once in SAP’s cloud, moving out (or switching to another provider) later can be challenging. Additionally, over a long horizon, subscription costs can exceed the cost of perpetual licenses and maintenance. One analysis notes, “The cloud isn’t cheaper than on-premise if you run a well-negotiated environment yourself,” emphasizing that savings hinge on how efficiently the cloud service is used.
- RISE with SAP (Business Transformation as a Service): RISE with SAP is a 2021 offering that bundles SAP’s cloud ERP (S/4HANA) with a range of accompanying services under a single contract. RISE is not a different product; it’s a packaging and contract model. A RISE deal typically includes: S/4HANA Cloud (usually the private edition for large enterprises) licenses, the underlying infrastructure (SAP partners with hyperscalers to host your system), SAP Basis operational services, and additional components like Business Technology Platform (BTP) credits, SAP Business Network starter packs, and tools for migration (custom code analyzer, readiness check, etc.). Essentially, RISE is a one-stop subscription where SAP (and its partners) take on much of the responsibility – you get “one contract, one bill” for software, infrastructure, and basic technical services. Pros: RISE simplifies customer dealings – SAP becomes the single point of contact for SLAs, support, and billing. It converts everything to an OPEX model and can reduce upfront costs (since you’re not buying licenses or hardware outright). It also offers flexibility in deployment – you can choose your preferred hyperscaler (e.g., Azure, AWS) and SAP will provision your S/4 system there, so you leverage global cloud infrastructure without contracting directly with the cloud provider. SAP also often provides aggressive incentives and discounts for RISE to encourage cloud adoption. Cons: RISE contracts can be complex and are generally less flexible once signed – you’re locked into a subscription term, and there’s little room to downscale or cancel if needs change. Customizations are still possible (especially in the private edition), but you relinquish some control over the environment, as SAP manages it. Critically, adopting RISE usually means converting your existing licenses to the new model, which forgoes your perpetual license assets in favor of subscription. Companies with large sunk costs in ECC licenses may lose the ability to leverage those investments, as there are no “shelf” licenses to redeploy – everything becomes a subscription. Also, over a decade, RISE might turn out to be more expensive due to cumulative subscription fees, and SAP can raise prices at renewal. There is a risk of financial lock-in, where future price increases are difficult to avoid. It’s important to compare the 5-10 year TCO of RISE vs. keeping an on-premises model with cloud hosting, as the intuitive “cloud is cheaper” assumption may not hold in all cases.
In summary, on-premises solutions offer maximum control and leverage existing investments, but require more self-management. Cloud (non-RISE) can refer to SAP S/4HANA public SaaS for rapid adoption with standard processes, or an S/4HANA private cloud subscription for greater flexibility. Both options shift to a recurring cost model and utilize SAP-managed infrastructure.
RISE with SAP is a comprehensive offering that bundles private cloud S/4HANA and surrounding services, easing the technical path but binding you tightly to SAP’s cloud ecosystem.
Recommendations for CIOs:
1) Align the deployment model with your company’s IT strategic direction. If your company is aiming for a cloud-first strategy and prefers to outsource infrastructure management, then a S/4HANA Cloud or RISE deployment aligns with that vision. If you have concerns about data control, regulatory requirements, or the cost of the cloud, an on-premises or hybrid approach might be better.
2) Examine TCO and ROI over a realistic period (e.g., 5-10 years). Consider factors such as hardware refresh cycles for on-premises solutions and the costs of internal support staff compared to multi-year subscription fees for the cloud.
Make sure to account for intangibles: the agility of the cloud (faster scaling, quicker updates) vs. the control of on-premises solutions (e.g., you can skip an upgrade if it’s not convenient, which you can’t in SaaS).
3) If you choose RISE with SAP, enter it with a clear understanding. Negotiate safeguards for future pricing, if possible (e.g., caps on annual price escalation after the initial term), and understand that moving off RISE later may require the repurchase of licenses. Leverage SAP’s eagerness to sell RISE to get favorable terms (discounts, included services) up front.
4) For large enterprises with existing SAP investments, consider a phased approach – running some workloads on RISE or S/4 Cloud and others on-premises temporarily – but be aware of the complexity of managing hybrid licensing. SAP’s stance is increasingly cloud-focused, and they may not encourage partial measures.
Nonetheless, you can, for example, move a division onto S/4HANA Cloud while others remain on ECC for a while, as part of a controlled rollout. Just ensure you negotiate contract terms that allow for a phased transition without double payment.
5) Involve your enterprise architecture and security teams early – issues such as integration with other systems, data residency, and compliance can influence the deployment choice.
For instance, if latency between S/4 and on-premises manufacturing systems is a concern, a local on-premises or private cloud might be necessary.
Overall, choose the model that balances IT capabilities, cost, and business needs. Remember that what you decide will shape your relationship with SAP for years to come, considering the options between perpetual ownership and subscription dependence.
Licensing Transition Options – Converting ECC Licenses to S/4HANA
Migrating to S/4HANA isn’t just a technical endeavor – it also requires migrating your SAP licensing. SAP S/4HANA is considered a new product line with new licensing; an ECC license does not automatically cover S/4HANA usage.
Enterprises running ECC have often spent millions on perpetual licenses and pay annual maintenance fees for them. Naturally, you’ll want to carry forward the value of those investments as you move to S/4HANA, rather than buying an entirely new license estate from scratch.
SAP offers a few programs to transition licenses, but it’s crucial to understand the options and plan the license conversion carefully.
SAP’s License Conversion Programs:
There have historically been two main approaches to convert ECC licenses to S/4HANA licenses: Product Conversion and Contract Conversion, plus the option of switching to a cloud subscription.
- Product Conversion: This option (now largely retired) allowed existing ECC customers to “swap” their ECC ERP package license for an S/4HANA Enterprise Management license on a like-for-like basis. In essence, you can convert your existing ERP User licenses into equivalent S/4HANA on-premises licenses, keeping your current contract and pricing terms intact. It was a way to protect your investment – you continue to pay maintenance on the converted licenses, and you get S/4HANA usage rights without needing to repurchase them. However, SAP only offered this to customers who had previously purchased a specific S/4HANA intermediate license (“S/4HANA Enterprise Management for ERP customers”). As of mid-2023, SAP has discontinued this route for new conversions. In short, product conversion was a limited-time bridge that is no longer generally available to those who didn’t already secure it. Most customers today will be looking at contract conversion or cloud options.
- Contract Conversion (License Exchange & Credit): In a contract conversion, you effectively terminate your old ECC license contract and sign a new S/4HANA contract, but with financial credit for the remaining value of your ECC licenses. You purchase S/4HANA licenses anew (sized to your needs), and SAP gives a credit or discount against that purchase based on the “undepreciated” value of your existing licenses. Early in the S/4 program, SAP allowed up to 90% of the new S/4 license fees to be offset by this credit (meaning you only paid 10% new cash if your ECC investment covered the rest), but that generous ratio has been scaled back to around 70% now. And importantly, the available offset declines each year – the later you convert, the smaller the credit SAP is willing to grant. This is deliberate to encourage timely moves: the sooner you perform contract conversion, the more trade-in value your ECC licenses hold. With contract conversion, all your old ECC contracts, along with any special discounts or terms, are replaced by new S/4HANA agreements. It’s a chance to “clean house” – eliminate unused licenses (shelfware), simplify contract metrics, but also requires careful negotiation to not lose any advantageous terms you previously had.
- Transition to Cloud (Subscription Conversion): A third path is to abandon perpetual licensing altogether and migrate to a cloud subscription model – either S/4HANA Cloud or RISE with SAP. In this case, instead of converting your license, you would end your on-premises perpetual license agreement and subscribe to S/4HANA as a service. SAP is strongly incentivizing this route. From a licensing perspective, this is akin to contract conversion (you terminate ECC licenses); instead of buying new perpetual licenses, you sign a subscription contract. SAP still recognizes your past investment by offering credits or incentives in the subscription deal (for example, “conversion credits” or discounted subscription rates for a period). However, the mechanics differ: you’re now paying annual subscriptions and are likely to adopt the new Full Usage Equivalent (FUE) user metric (more on that below) instead of classic named-user counts. SAP’s sales teams often pitch the cloud move as the most future-proof and have the flexibility to provide attractive offers, such as extended dual-use periods and service bundling. The key consideration is that this is a one-way door – once you switch to subscription, you cannot revert to your old ECC licenses. SAP’s cloud contracts also give them the ability to re-negotiate terms at renewal, so you want to start with as favorable a deal as possible.
During any license conversion, one crucial aspect is ensuring continuity of use. A migration isn’t an overnight switch; you will likely run ECC and S/4HANA in parallel for some time, during development, testing, and possibly even a phased go-live. It’s vital to negotiate dual-use rights – i.e., permission for users to continue using the ECC system during the transition period even after the S/4 licenses are in place, without incurring extra license costs.
SAP typically allows a window of 12-24 months for overlapping usage when converting a contract, but this must be specified. Additionally, consider growth: if your business might expand or require extra ECC usage before cutover, account for that in the conversion plan (perhaps by slightly oversizing the S/4 licenses or explicitly allowing some headroom for ECC during migration).
Another consideration is what to do with “shelfware” – the licenses you own but don’t use. A big benefit of a contract conversion is the opportunity to drop licenses you no longer need. Many SAP customers only utilize around 70-75% of their existing license entitlements on ECC, meaning 25-30% are unused but still incur maintenance costs.
In negotiations, SAP has been willing to let customers terminate that shelfware as part of the conversion, which lowers the ongoing maintenance base. This is a key cost optimization: there’s no sense converting and paying maintenance on 1,000 licenses if you only need 700 in S/4HANA. Use the migration as a chance to right-size.
We’ll discuss negotiation tips in a later section, but suffice it to say that you should do a thorough license inventory and usage analysis before conversion. Identify what you use (by user and by SAP module or package) so you only convert what’s necessary and receive credit for the rest.
Recommendations for CIOs: 1) Inventory and Analyze Current Usage: Start with a solid baseline of your ECC licenses – how many users of each type, which engines/modules are in use, and how that might translate to S/4HANA equivalents.
This not only informs you of what you need to convert, but also reveals shelfware that can be dropped. Use SAP’s License Administration Workbench (LAW) or similar tools to assess actual license consumption and rationalize any mis-assigned users (e.g., some users could be downgraded from Professional to a less costly license type) before you convert.
Optimizing license allocations now strengthens your position going into conversion. 2) Choose the Right Conversion Path: If you’re still in the early stages of decision-making, check if any product conversion possibilities exist (some customers who have already purchased S/4HANA licenses may expand their usage). But for most, it will be Contract Conversion vs. RISE/Subscription. Decide which aligns with your IT and financial strategy.
Contract conversion keeps you on perpetual licenses (with a new contract) – good if you want to retain on-prem flexibility. Considering RISE or an S/4 Cloud subscription might make sense if you’ve decided to go cloud-first or if SAP’s subscription incentives are financially compelling. 3) Time the Conversion Strategically: The conversion credit percentage declines as 2027 approaches. If budget allows and your S/4 project is firm, converting sooner locks in a higher credit (lower net cost).
Some companies even “convert early” – buying S/4HANA licenses ahead of the actual go-live date – to maximize credits and then hold both ECC and S/4 licenses during the transition. This can be financially wise if you plan well, but it means paying maintenance on two sets of software for a short time.
Weigh the cost of overlapping maintenance against the benefit of higher conversion credit. 4) Negotiate Dual Usage and Flexibility: Ensure your agreement explicitly covers continued ECC use until the S/4 cutover is complete, for all necessary users, without additional fees.
Also, clarify terms such as whether you can adjust the mix of license types during the project or if any unused S/4 licenses can be returned for credit if the scope changes. 5) Leverage SAP’s Cloud Extension Policy if Applicable: SAP has a “cloud extension” policy that allows customers to terminate on-premises licenses and convert their value to cloud subscriptions (essentially part of contract conversion). Make sure if you adopt any cloud products, you’re not double-paying.
For instance, if you start using some S/4HANA Cloud modules, you should be able to reduce the equivalent on-premises licenses to avoid paying maintenance and subscription fees for the same functionality. In summary, treat license transition as a subproject of the migration with its own workstream. It can yield significant cost savings if done correctly and prevent compliance headaches down the road.
Key Differences in Licensing Models (ECC vs S/4HANA)
As you transition to S/4HANA, you’ll encounter a different licensing model than the one in ECC. Understanding these differences is crucial for ensuring compliance and controlling costs.
Key areas to focus on are named user license types (and the introduction of Functionality Units in S/4), changes in how indirect access is licensed, and new metrics for specific SAP modules.
Classic ECC Licensing:
In ECC 6.0, licenses were primarily based on Named Users and additional engine or package licenses. Named users were categorized by type – e.g., Professional, Limited Professional, Employee, Developer, etc., each allowing certain usage scope. For example, a Professional User is a full-power user (the most expensive), whereas an Employee Self-Service user might be a low-cost option for limited self-service tasks.
Customers had to assign each individual to the appropriate user type and ensure they had enough of each license type. Additionally, ECC included package licenses (sometimes called engines) for specific functionalities, such as SAP Payroll or SAP Warehouse Management, often measured by metrics like the number of employees or warehouse picks. This led to a complex mix of metrics to track.
S/4HANA On-Premises Licensing:
If you migrate to S/4HANA and stay with on-premise (perpetual) licensing, you will still have Named User licenses and package licenses, but there are some differences. S/4HANA has user categories (e.g., SAP S/4HANA Professional user, Functional user, Self-Service user), which roughly map to the old ones but not exactly.
SAP also introduced the concept of licensing the digital core (S/4HANA Enterprise Management), which is the base package, and then add-ons for extended modules. Generally, when converting a contract, SAP will map your old licenses to equivalent S/4HANA licenses. It’s important to verify those mappings so that your users have the right entitlements in S/4. For instance, an ECC Professional User might become an S/4HANA Professional User one-to-one.
But ECC Limited Professional Users might convert to a different S/4 license type or a fractional value in the new model. User Type Rationalization: A positive change is that SAP simplified some user definitions in the S/4 era, but you need to ensure all roles in your company are covered by the new definitions.
Pay attention to whether any new S/4 functionality requires licensing that you didn’t need in ECC (for example, if you start using embedded analytics, is that covered by the base license? Typically yes, but always check the latest price list).
Full Usage Equivalents (FUE) – New User Licensing Metric:
The biggest shift occurs if you opt for S/4HANA Cloud, especially via RISE. In the cloud subscription model, SAP has moved away from multiple named user types to a unified metric called Full Usage Equivalents (FUE). FUE is essentially a weighting system: 1 FUE is defined as a baseline full user (roughly analogous to a traditional Professional user). Other lighter users count as a fraction of an FUE. For example, an employee self-service user might be 0.1 FUE, a casual data inquiry user might be 0.2 FUE, and so on.
A heavy “Advanced” user is 1 FUE. SAP provides a mapping of old named user types to FUE ratios – for instance, what used to be a “Limited Professional” could count as 0.5 FUE, a Warehouse Clerk might be 0.2 FUE, and so on (these exact ratios are defined in SAP’s documentation and have been illustrated in conversion charts).
The idea is that instead of purchasing 100 Professional, 200 Limited Professional, and 100 Employee Self-Service licenses separately, you might purchase a total of 150 FUEs, which could cover that mix of users. You then allocate those FUEs across user roles as needed. Benefits of the FUE model: It simplifies license management because you’re dealing with one metric.
It also provides some flexibility – if your user community’s roles change, you can reallocate FUEs accordingly. (SAP explicitly notes that customers can reallocate their FUE-based user allocations to avoid shelfware as needs evolve.) Essentially, you have a pool of usage capacity rather than rigid counts per category.
Considerations: The FUE model requires careful mapping to ensure you buy enough FUEs. During your assessment, SAP or a partner can run a tool to simulate how many FUEs your current users would equal. Note that one Developer user counts as more than 1 FUE (often 2 FUEs, since developers have high-level access).
The conversion is not always one-to-one; for example, 30 employees with self-service might collectively count as only a few FUEs (if each self-service user is 1/30th of an FUE, for instance). Bottom line: FUE is a new paradigm – ensure your team understands it and model various scenarios (peak usage, growth) to purchase the right amount. Also, remember that FUE applies to digital core S/4HANA access; some cloud modules, such as SuccessFactors and Ariba, still have their own user or transaction metrics separate from FUE.
Indirect/Digital Access:
A notorious aspect of SAP licensing in the ECC era has been indirect access – scenarios where third-party systems connect to SAP and propagate data without a named SAP user directly logging in, such as when an e-commerce site creates an order in SAP or a Salesforce system queries SAP data. In ECC, SAP’s stance was that if a third-party system was used, that usage still needed to be covered by an appropriate named user license (often a technical user or the individuals on the other system needed licenses).
This was murky and led to high-profile disputes. To address this, SAP introduced the Digital Access model in 2018, which licenses indirect usage based on the number of documents created (such as sales orders and invoices) rather than users. Under Digital Access, you purchase a quantity of documents (e.g., you estimate X number of order documents per year), and that covers any non-human or indirect creation of those documents in S/4HANA.
SAP launched a Digital Access Adoption Program (DAAP) to incentivize customers to move to this model, offering discounts such as a 90% discount on document licenses if purchased by a certain time, or a growth-based model. For S/4HANA, SAP will strongly encourage the digital access approach for indirect usage rather than the old named-user workaround.
It’s important as part of your migration to assess indirect use cases – do you have systems interfacing with SAP that aren’t licensed? If so, consider taking SAP’s digital access license now under the incentive program or negotiating it into your S/4 deal. You can also choose to stick with named-user-based indirect usage (SAP allows that).
Still, you must then ensure any external usage is covered via existing license types – a potentially risky proposition if usage grows. Many companies are opting to settle this as part of S/4 migration to avoid a future audit surprise. The good news is SAP’s incentives for digital access have been fairly generous (90% discount offers, etc.), and you can likely negotiate a reasonable package.
Engine/Package Licenses:
Most classic SAP engines, such as SAP ERP Financials and Materials Management, are included in the S/4HANA Enterprise Management core license. However, some specialized functions may still require separate licenses (for example, Treasury and Risk Management, or extended Warehouse Management, which might be separate in S/4, depending on the edition).
In RISE or S/4 Cloud contracts, these may appear as separate line items, but they are still included in the subscription price. Ensure you understand which previously licensed products remain separate vs. which are now included in the base S/4HANA license. SAP has consolidated some functionality in S/4 but also introduced new ones (e.g., if you decide to use the SAP Analytics Cloud integration or SAP Conversational AI, these may require additional licenses).
In summary, S/4HANA licensing aims to simplify user categorization (especially with FUE in the cloud model) but introduces new metrics (documents for digital access). It’s critical to carefully translate your ECC license grants to S/4HANA equivalents.
Work with SAP’s conversion guides or tools that provide a translation of classic named user licenses into FUEs or new named user categories for on-premises use. Make sure nothing falls through the cracks. For example, if you have licensed SAP ERP for professional users and also have some casual users, ensure there is a corresponding S/4 license type or FUE allocation for them.
Recommendations for CIOs:
1) Educate your team on FUE: If you are migrating to RISE or S/4 Cloud, ensure that your license administrators and IT finance team understand how FUE works. During negotiations, ask SAP for a detailed mapping of your current users to FUE consumption – this is often provided in a spreadsheet or report. Get agreement on the assumed ratios so that you have flexibility later.
Also, clarify how FUE reallocation works in practice. Typically, you can change the mix of user roles annually or as needed, as long as the total FUE remains within your subscription.
2) Plan for Indirect Access now: Do an audit of all third-party integrations to SAP. If they aren’t properly licensed under ECC, use the migration as an opportunity to resolve it.
The Digital Access license (document-based) is usually the best path forward. See if you qualify for any DAAP discounts and bundle them into your S/4 deal. Suppose your indirect usage is minimal or unchanged. In that case, you might negotiate a clause that any indirect usage compliant under ECC remains compliant under S/4 without additional cost.
However, SAP’s preferred method is the document model, so be prepared to adopt it.
3) Confirm entitled functionality: Don’t assume everything in ECC maps one-to-one. For example, some ECC customers had industry solutions or complementary products. When moving to S/4, confirm if those require a new license (e.g., if you used SAP APO, the equivalent in S/4 is embedded PP/DS but might need an add-on license unless you choose the edition that includes it).
Work with SAP to obtain a license mapping document that lists all your ECC-licensed software and its S/4HANA counterpart licenses. This helps avoid functionality loss or unexpected fees later.
4) Track Engine Metrics: If you have any license metrics (such as users, orders, revenue, etc.) that determine fees in ECC, verify how they are applied in S/4.
Some engines might be discontinued or rolled into the core. For those who remain, ensure your current usage is within the licensed bounds and will stay that way after migration. S/4 might generate higher transaction volumes (due to increased performance, etc.), which could affect metric-based licenses.
If so, negotiate a buffer or convert to unlimited if possible to prevent unplanned true-ups.
5) Leverage the flexibility of FUE (if applicable): One advantage of the FUE model is avoiding shelfware – since you can reassign user types, you won’t end up stuck with, say, 50 unused HR user licenses; they just free up FUE that you can allocate elsewhere.
However, that only holds if you actively manage it. Institute a process to periodically review license assignments against your FUE entitlement to maximize usage. In on-premises, similarly, periodically recalculate to ensure users are on the appropriate license type.
6) Keep an eye on audit terms: After migration, SAP will have the right to audit your S/4 system usage. Ensure you understand how they will measure FUE consumption or document counts. This clarity will help you stay compliant and avoid unexpected costs.
Contract Negotiation and Fair Value Conversion Tips
Migrating to S/4HANA is a major event, both technically and commercially. It often involves signing new contracts or amendments with SAP. This is a prime opportunity for CIOs (and procurement teams) to negotiate favorable terms, as SAP is eager to secure your long-term commitment to S/4.
Here are key negotiation considerations:
License Conversion Credits:
As discussed, SAP offers credits for existing licenses when you convert to S/4HANA. Typically, up to 70% of the new license value can be offset by the oldone. When negotiating, ensure you understand how SAP calculates the credit, often referred to as “Net License Value” or “contract value conversion.” Push for maximum credit for any unused licenses (shelfware) you will surrender.
SAP reps have some discretion here: if you can demonstrate that certain licenses were never deployed, you might argue for credit on them as well (so you’re not paying maintenance all these years for nothing).
As an advisor notes, SAP has been willing in strategic deals to let customers terminate shelfware, reducing the license count and maintenance before conversion. Leverage that – list out which ECC components or users you will drop, and get confirmation of the maintenance cost reduction and credit applied for those. Also, try to lock in the credit percentage early by committing to a timeline. If you fear it will drop below 70%, ask SAP to honor the current rate if you sign by a certain date.
Maintenance Fees and Support Terms:
One nuance of contract conversion is what happens to your maintenance base. If you convert to new licenses, the maintenance fee will typically carry over as a percentage of the new license’s net value. Ensure that any reduction in licenses translates to a lower maintenance bill. Also, negotiate maintenance protections: SAP’s standard terms allow annual maintenance cost increases (usually inflationary, ~3% or more).
You can attempt to cap these increases or get a few years of fee freeze as part of the deal. Given SAP’s extended support timeline, you might also negotiate something like: if you need to stay on ECC past 2027, the extended maintenance fees are waived or discounted because you’ve already committed to S/4 (SAP has hinted at such concessions for customers who sign S/4 contracts early) – for example, committing to S/4 could qualify you for the extended maintenance without the 2% premium(this might not be publicly formalized, but it’s a discussion point with SAP).
At the very least, ensure clarity on maintenance for ECC during the transition and for S/4 after go-live (they may overlap in the transition year(s)). You don’t want to pay double full maintenance on both; often, SAP can provide a bridging arrangement.
Services and Implementation Assistance:
The move to S/4HANA usually involves significant services, whether from SAP Consulting or third parties. While SAP license negotiations primarily cover software, SAP may bundle or discount some services or training credits as part of an overall migration package.
For example, you could request several hours of SAP Consulting or a Customer Success manager dedication at no charge, or access to SAP Learning Hub subscriptions for your team. These can add value. Also, consider SAP MaxAttention or ActiveAttention support. If you are a large customer, SAP may include a few months of enhanced support during go-live or offer a reduced rate for these premium services as an incentive.
Contractual Safeguards – Flexibility:
When entering a new S/4 contract, you’re locking in a relationship for possibly decades. Negotiate for flexibility where possible. This might include: the right to make certain volume adjustments, the ability to swap certain licenses for others of equal value if your needs change (for instance, if you license a certain S/4 component and later realize another component would suit better, some contracts allow a one-time swap within a year of purchase).
If you are unsure about going fully cloud, you could negotiate a “step-in/step-out” clause. For example, you start with on-premises licenses but have the option to transition them to an equivalent cloud subscription later with minimal penalty (or vice versa).
SAP’s standard approach is not to allow cancellation or reduction of licenses. (Perpetual licenses you own can be shelved, but maintenance is still due unless terminated.) In RISE subscriptions, as noted, cancellation or reduction is generally not allowed during the term. Still, you might negotiate the ability to true-down at renewal or a shorter initial term to test the waters.
Protect Against Indirect Access Surprises:
Indirect access was a grey area that SAP has clarified with Digital Access. In your new contract, include language that settles any past indirect use and defines future handling. If you buy digital access licenses now, have SAP agree that it covers all indirect scenarios, and they won’t pursue named-user-based claims in the future.
If you choose not to go with digital access, then get a written assurance of what data or interface usage is permitted under your user licenses (some customers have gotten clauses that certain interfaces, like Salesforce or a B2B portal, are considered covered). This is a negotiation – SAP may push you to just take the digital access program instead (which often is fine if heavily discounted). The key is not to leave it ambiguous.
Preserve Prior Discounts:
If you have a history of a master agreement with special discounts (for example, you always got 50% off the list price in your old contract), note that contract conversion technically creates a new contract. You should negotiate a “contract value protection” such that the pricing you get for S/4 is consistent or better than your prior deal.
Often, SAP will restructure S/4 pricing but ensure that the conversion credit accounts for your prior discount. Still, make sure the effective discount is clear. If additional licenses are needed in the future, what discount will apply? It may be wise to negotiate an attractive price protection for future purchases now, while you have leverage.
For instance, you might get SAP to agree that any additional S/4HANA user licenses you buy in the next 2 years will be at the same % discount as this deal, or that your FUE subscription rate will not increase by more than X% if you add more users.
Contingency for Project Delays:
Many companies sign S/4 contracts, and then the project timeline slips. Try to incorporate some buffer or contingency in the contract. For example, you might arrange for the S/4 licenses’ maintenance (or subscription billing) not to start until the production go-live, or get a deferral on maintenance fees for the first year while in implementation.
In a RISE scenario, you might negotiate that the subscription term (say, a 3-year term) doesn’t commence until the system is provisioned and ready for use, so you’re not burning subscription time while still implementing. SAP might not always agree, but even a few months of relief can help.
Competitive Leverage:
While realistically, most ECC customers will likely migrate to S/4 (as there is no truly equivalent alternative without re-platforming to a different vendor entirely), don’t underestimate the power of showing SAP that you have options. Some organizations evaluate other ERP solutions, such as Oracle or Microsoft, or consider third-party support, like Rimini Street, to avoid SAP’s fees.
If it fits your strategy, let SAP know that you are weighing those options – it often motivates them to present a more compelling offer. NPI advisors suggest positioning at least the notion of a competitive alternative to gain leverage in negotiations. Even if switching ERP is unlikely, having a backup plan for support (e.g., third-party maintenance after 2027 instead of paying SAP’s extension) can be a negotiating chip.
For instance, “If we can’t come to a reasonable agreement, we may choose to stay on ECC with third-party support for a while.” SAP sales teams, not wanting to lose the account, may improve their proposal (like offering a bigger discount or extended payment terms).
Document Everything:
When you finalize the contract, ensure all promises are in writing. This includes any migration credits, timelines, dual-use periods, and other relevant details. If it’s not in the contract or an addendum, it will be difficult to enforce later. Also, consider engaging your legal team to review liability clauses if you use cloud services – ensure that data protection, uptime SLAs, and exit assistance clauses are addressed in your RISE contracts.
Recommendations for CIOs:
1) Start negotiation prep early – at least 6-12 months before you intend to sign. Inventory your entitlements, determine your future needs, and set your priorities (cost reduction? flexibility? new functionality?). 2) Involve the right stakeholders: include IT, procurement, finance, and even executives if the deal is large.
A migration to S/4 can be leveraged to achieve not only IT goals but also financial ones, such as flattening support cost increases for a period. 3) Use expert help if needed: Consider consulting firms or licensed advisors, such as Redress Compliance, or independent SAP licensing experts who are familiar with SAP’s guidelines.
They can provide benchmarks on discounts and terms. If you have a large SAP spend, this can pay off by uncovering savings or avoiding pitfalls. 4) Aim for a win-win: While being a tough negotiator is fine, remember you’ll be in a long-term partnership with SAP for S/4. Achieve a fair deal that gives your company value, but also makes SAP feel like they secured your loyalty.
This mindset can help you get goodwill gestures, such as migration support or extra training, thrown in. 5) After the negotiation, continue to manage the relationship. Set up regular executive check-ins with SAP to ensure you’re getting the value promised, especially if you’re on RISE. Keep them accountable, and they’ll be more inclined to help if any issues arise during your transformation.
How RISE with SAP Changes Licensing and Contracting
Adopting RISE with SAP is more than just a technical migration – it fundamentally changes your licensing model and contractual relationship. As noted earlier, RISE converts your model to a subscription, measured in FUEs, and bundles software and infrastructure.
Here we recap the implications specifically related to licensing and enterprise agreements:
- Conversion of Perpetual to Subscription: With RISE, you no longer own SAP software licenses; instead, you subscribe to S/4HANA as a service. This means that any perpetual ECC licenses you had are typically no longer in use. You can’t partially keep some perpetual licenses for S/4 and do RISE for others – a RISE contract is a new, standalone agreement. For many customers, this means writing off the book value of their existing licenses, although that value may have been amortized long ago. SAP usually provides a financial incentive for this switch, effectively crediting your prior investment into the RISE subscription pricing (often through discounted subscription rates or initial credits). However, once you’re on RISE, you can’t “reverse” back to perpetual without buying licenses again. This is a one-way transition to a SaaS-like consumption model. Your enterprise agreement with SAP will change from a license agreement to a cloud subscription agreement, which has different terms (for example, different liability, warranty, and performance clauses – review these carefully with your legal team).
- All-in-One Contract: RISE contracts bundle what would traditionally be separate agreements (license, support, cloud hosting, and support services). You’ll have one set of terms governing all. This can simplify vendor management, but note that some flexibility is lost. For instance, under a perpetual model, you could decide to drop SAP maintenance and switch to third-party support (though with consequences). Under RISE, you don’t have this option – support is included in the subscription. Similarly, you cannot choose a different hosting provider or negotiate those infrastructure costs independently; it’s all embedded. If you have an existing Enterprise Agreement with a hyperscaler, you can’t leverage the committed cloud discounts for the S/4 workload – SAP is the one contracting the cloud and passing the cost to you, along with a margin. Indeed, SAP’s margin on cloud infrastructure is one reason RISE might be more expensive; SAP may not discount the infrastructure component as heavily as they do the software. Analysts have observed that SAP tends to give higher discounts on the S/4 software portion than on the infrastructure portion of RISE deals. So be aware that, unlike a pure license deal where you could negotiate software and shop for the best cloud hosting deal separately, RISE is a package – you’ll want to negotiate the overall price. Still, you won’t have line-item visibility of each component’s cost.
- Lock-in and Renewal: As highlighted before, a RISE subscription locks you in for the term (often 3 or 5 years). There is no ability to reduce usage or cost until the renewal. And at renewal, you are negotiating from a position of dependency – moving off RISE would be a significant project; you’d need to set up your environment and potentially relicense the software. This gives SAP leverage to increase prices. Ensure your contract has a cap on renewal price increases or, at the very least, language stating that any increase must be negotiated in good faith. If possible, negotiate a longer-term price protection (e.g., fix the price for 5 years with an option to renew for another 2 years at the same rate, or a cap like “no more than a CPI increase”). Also, ensure you understand the basis of the charge – usually the FUE count – and have rightsizing clauses if your user count drops (though SAP typically treats it as “use it or lose it, you pay the subscription regardless”). If your business is cyclical or might divest units, consider how that affects a fixed subscription.
- No Additional Perpetual Licenses: After moving to RISE, SAP’s policy is that you should not buy new on-premise licenses for S/4. They may include a contract clause that says, as long as you’re on RISE, you cannot deploy S/4 outside of it. Any expansion of S/4 usage means increasing the subscription or buying additional cloud services. Suppose you still need some on-premises SAP software that is not included in RISE (such as a legacy component or a niche product). In that case, you may need to maintain a separate license, but SAP’s goal is to transition everything to a cloud subscription. This also means if you, for example, acquire a company that runs SAP, integrating them might require adjusting your RISE contract rather than just applying existing licenses. Enterprise agreement complexity: If you have an enterprise license agreement that allows group-wide usage, moving to RISE might change it to a named tenant model, where the subscription covers specific systems. You might need to count users more diligently. Multi-affiliate access needs to be explicitly allowed in the cloud contract, ensuring that parent/subsidiary rights are clear.
- RISE Includes Support and Upgrades: In the old model, you paid 22% maintenance for support. In RISE, standard support for the cloud is included in the subscription fee. You also receive upgrades as part of the service (for S/4HANA Cloud, SAP handles the technical upgrades). This is good in that you’re always up to date, but you’ll need to adapt to SAP’s upgrade schedule. Typically, SAP will give you a window or allow you to delay a certain number of cycles, but not skip entirely. Ensure the contract has provisions around upgrade timings that suit your business calendar (e.g., avoid critical business quarter freezes). Also, clarify what happens if an upgrade introduces an issue – SAP’s responsibilities to remedy or provide support.
- Bundled SAP BTP and Other Services: A RISE deal often includes credits for SAP Business Technology Platform (BTP) and possibly other SAP cloud services. For example, SAP might bundle – or offer at a discount – certain amounts of BTP consumption, allowing you to build extensions and integrations on BTP. Contractually, check if those are one-time credits (e.g., a one-year free credit) or ongoing entitlements. BTP usage beyond the credit limit would cost extra, so be mindful of that. Additionally, RISE may include access to SAP Ariba Discovery or SAP Signavio (process intelligence) for a limited time. These “bundled” perks are great, but confirm the duration and whether they auto-renew into paid services if not cancelled.
- Customization and Add-ons: While not a license metric per se, note that under RISE, if you need to install additional components (say you want to add an SAP BW/4HANA or another SAP product that isn’t part of the core S/4 subscription), you’ll need to do so under SAP’s cloud terms. Some products might not yet be available under RISE and could require separate cloud agreements. Coordinate with SAP to include all necessary components in the RISE scope.
In short, RISE changes your status from a license-owner to a service-subscriber. Many CIOs welcome the shift to OPEX and having SAP run the system, but it comes with the loss of autonomy and potential long-term cost implications.
Recommendations for CIOs:
1) Double-check the numbers: When SAP presents RISE as a cost saver (e.g., “TCO 20% lower”), model it out yourself. Include all elements, such as the subscription fee and any migration surcharges, and compare them to the alternative of perpetual licensing, external hosting, and internal support. Also consider intangible benefits (faster innovation) versus risks, such as price lock-in. If the math isn’t clearly in favor, push SAP on price or additional value.
2) Negotiate RISE like a long-term partnership, because it is one. Ensure transparency – request breakdowns of FUE pricing and infrastructure assumptions (e.g., the number of environments, server sizes, etc.), so you know what you’re paying for. This also helps later if you need to scale up and want to know the costs.
3) Include Exit Provisions: No one enters a deal expecting to leave, but just in case, negotiate what happens if, at the end of the term, you choose not to renew RISE. Will SAP help migrate your data to an on-premises system? How long will your systems continue to run after the contract ends to facilitate the transition? These should be in the contract to avoid being held hostage.
4) Stay engaged in governance: RISE doesn’t mean you can be hands-off. Establish strong governance with SAP for your cloud service. For example, quarterly service reviews are used to track usage of FUEs, system performance, and to forecast whether adjustments to the subscription are needed (such as increasing FUEs or adding users). SAP can sometimes allow a mid-term increase in subscription (you pay more, of course), but might not allow a decrease. Knowing usage trends helps avoid last-minute overages.
5) Leverage SAP’s incentives: SAP is highly motivated to make RISE successful. This means you can often get better discounts and freebies with a RISE deal than with a straight license deal. Don’t shy away from asking for that extra 10% off, or inclusion of a module at no cost, or extra BTP credits, citing that moving to RISE is a big commitment on your part. SAP often has internal targets to meet (cloud revenue, etc.), which can work to your advantage.
6) Keep an eye on the future: If you go RISE, start managing it day 1. The renewal in X years will come faster than you think. Document any issues or shortfalls to address at renewal, track your satisfaction, and be ready to negotiate the renewal well before it lapses – that will be your next chance to adjust the terms.
Migration Incentives and Programs to Leverage
SAP understands that moving its vast ECC customer base to S/4HANA is a monumental challenge, and it has rolled out incentive programs to sweeten the deal. As a CIO, you should be aware of these and take full advantage where applicable:
- Extended Maintenance Incentives: One implicit incentive (or avoidance of a penalty) we have already discussed: commit to S/4 and you get access to support for 2028–2030. SAP has indicated that customers who show commitment by signing S/4 contracts could avoid the hefty extended maintenance fees. In practice, this could mean that SAP waives the +2% fee for those years or even provides support through 2030 free of charge if a firm migration project is in place. While not an official public program, SAP account executives have the latitude to make such concessions for important customers. It’s worth explicitly asking: “If we move forward with S/4HANA licensing now, can SAP guarantee support on ECC until our go-live without extra charge?” The worst, they say, is no, but often they find a way (perhaps through an amendment to a global agreement).
- RISE with SAP – Migration and Modernization Program (2024): In 2024, SAP announced a new program to reduce the cost barrier for on-premises customers moving to S/4HANA Cloud (RISE or a similar GROW with SAP for midsize companies). Through the end of 2024, SAP is offering credits that can offset maintenance and subscription costs for migrating. Concretely, SAP stated customers moving ECC to S/4HANA Cloud via RISE could get credits equal to 45% of their current annual contract value, and those moving an existing on-prem S/4HANA to cloud could get 60%, with some smaller customers even 100% for one year. In other words, almost half of your first-year subscription cost could be covered by these credits. These incentives can be used not only for S/4 but also to purchase related cloud line-of-business (LoB) solutions or Business Technology Platform (BTP) services as part of the transformation. SAP promoted that this could cut migration costs by up to 50% when all factors are taken into account. As CIO, ensure your team inquires about the “RISE Migration Credits” (or whatever name SAP marketing gives it) and get the details in writing. If your project timeline doesn’t align with 2024, keep an eye out – SAP may extend or introduce similar incentives in 2025, especially as the end-of-maintenance date approaches.
- Discounts on Licensing: SAP traditionally has given volume or strategic discounts on licenses. For S/4HANA, if you’re a net-new license sale (e.g., not just converting what you have but buying additional modules or expanding user counts), you should negotiate strong discounts. We’ve seen indications that SAP is assigning higher-than-normal discounts to S/4 software to encourage adoption. It’s not unusual to see 50% or more off list in a competitive situation. During some promotion periods, SAP has even offered deals like “pay maintenance now, get the S/4 licenses for free” or deep discount packages. These can be fleeting, but ask your SAP rep about any ongoing promotions or customer-specific offers. Sometimes, industries or geographies have special programs as well.
- Bundled Services or Tools: SAP might include free or discounted migration tools or assessments. For example, SAP’s Readiness Check is free of charge. Still, SAP might offer a free trial or use of SAP Cloud ALM (Application Lifecycle Management) or Solution Manager upgrades to help manage the project. Another example: as part of RISE, SAP provides Process Discovery/Signavio analyses to help identify process improvements – these are valuable and often included. Leverage these to build the business case (SAP’s tools can highlight inefficiencies in ECC that S/4 can solve, helping justify the project cost). SAP’s BTP trial credits is another: as mentioned, you often get some BTP credits to build extensions – use them to prototype and show value.
- Third-Party Incentives: In addition to SAP’s incentives, many hyperscalers (such as AWS, Azure, and GCP) and systems integrators offer funding programs to co-sponsor migrations. For instance, a hyperscaler might offer cloud credits or funding for professional services if you choose to run S/4HANA on their platform (outside of RISE). While this isn’t directly from SAP, it’s part of the overall financial picture. Some large SIs (such as Accenture and Deloitte) may also reduce rates or offer fixed-fee packages for migrations as we approach 2027 to capture market share. As a CIO, you can orchestrate these: e.g., get cloud credits from an IaaS provider, get SAP license discounts, and SI fixed fees – all to reduce the risk of cost overrun.
- Extended Payment Terms or Financing: SAP (and its financing partners) sometimes offer payment deferrals or financing arrangements. For example, if budget is a constraint this year, SAP might allow you to sign the S/4 license deal now (to lock in credits or discounts) but not start making payments until next year, or to spread a large license fee over a couple of years. Especially with subscriptions, you can negotiate to ramp up the payment schedule (e.g., smaller payments in year 1 during implementation, then full payments when live). Explore if SAP Capital or third-party financing can be used – interest rates may apply, but if it enables an earlier start, it could be worth it.
- Bundling Additional Products: If you anticipate needing other SAP solutions (e.g., Ariba, SuccessFactors, Concur, analytics), consider negotiating a bundle deal. SAP is often willing to offer a smaller product at a steep discount if you’re making a big S/4HANA commitment. For instance, they might include some SAP Analytics Cloud licenses, SAP Work Zone, or others at no cost for a year. Also, SAP’s Business Technology Platform (BTP) is strategically important for them – they may bundle a certain amount of BTP into a RISE deal. Getting BTP entitlements can help your developers modernize integrations and build extensions for S/4.
- Extended Support or Legacy System Archiving: Some customers worry about retaining access to ECC data after migrating to S/4, for compliance and reporting purposes. SAP offers services like SAP S/4HANA Cloud Safekeeper, which, for RISE customers, will maintain an older release for an additional two years . This was primarily designed for customers on older S/4 versions, but conceptually, for ECC, there may be options to keep a read-only version. SAP might also allow, contractually, continued use of ECC in a limited fashion (for historical access) without support fees for a period, as part of the migration deal. Try to negotiate such arrangements if needed.
Key point: SAP’s incentives often have a timeline (e.g., “offer good if you sign by Q4 2024”). Use that to your advantage, but don’t rush imprudently; instead, align your project decision with when the best incentives are available. If an offer is expiring, ask if it will be extended or if something else might replace it. SAP’s end goal is to move you to S/4, so even if one program ends, another may begin.
Recommendations for CIOs:
1) Stay informed about SAP’s latest programs – maintain regular contact with your SAP account executive and ask about any migration offers or new announcements. SAP frequently shares these at events or via user groups like ASUG.
2) Engage with user groups or peers: Many incentives first surface in SAP user group meetings or online forums. Networking with other SAP customers can alert you to deals SAP provided them – you can then ask SAP for something similar.
3) Do the math on incentives: A 45% credit for one year is great, but look at the 5-year cost. Use the first-year savings to fund the project, but also plan for when that credit ends (make sure you can absorb the full costs later).
4) Combine incentives – there’s no rule that you can’t use multiple. For instance, you could receive the SAP migration credit and have a hyperscaler provide you with additional cloud credits. Stack all available offers to lower the overall cost.
5) When negotiating, explicitly reference these programs: it shows SAP that you’re aware of market offers. If, say, reports a 60% credit for RISE, bring that up and ask if you qualify. Sometimes, just showing that knowledge makes the vendor more transparent and generous.
6) Finally, ensure any incentives are captured in the contract or an addendum (e.g., a credit memo). If SAP promises a certain credit or free service, get it documented to avoid misunderstandings later.
Cost Control and Avoiding Shelfware During the Transition
Cost management is a critical part of this migration. SAP investments are significant, and without oversight, you could end up with “shelfware” (unused licenses) or paying for redundant systems longer than necessary. Here’s how to keep costs in check:
Optimize Licensing Before and During Migration:
Before migration, as mentioned, rationalize your ECC licenses. If you identify users with an overly high license level, adjust it now (e.g., Professional to Limited Pro). This not only saves current maintenance costs but also sets a lower baseline for converting to S/4. During the migration project, regularly review if all purchased S/4 licenses or subscriptions are needed.
For example, if you bought 1,000 FUEs but, after detailed design, you realize only 900 FUEs worth of users are needed, see if you can trim down before going live. (It’s harder after contract signature, but sometimes initial contracts allow adjustments after sizing.) Similarly, avoid over-licensing new functionality “just in case.” It’s better to start a bit conservatively and add licenses later (SAP will always be happy to sell more) than to overbuy and have shelfware.
Monitor Dual Maintenance Costs:
A period of running ECC and S/4 in parallel is inevitable, but try to minimize its duration. Every extra month you maintain two systems, you’re effectively paying double (maintenance on ECC, plus either maintenance or subscription on S/4). Plan the project to minimize overlap – for instance, retire ECC as soon as the historical data is migrated or available elsewhere.
If you need to keep ECC read-only for reporting, try to drop it from maintenance (perhaps by moving it to third-party support, or determining that read-only doesn’t require support). Some companies choose to archive data or migrate it to a cheaper platform (such as exporting ECC data to a data lake or archive system) so they can shut down the ECC instance and stop paying for it.
Consider strategies like Central Finance (if you move finance first and need ECC to run for logistics longer, Central Finance can consolidate data, allowing ECC to be closed sooner in the finance area). Each month of avoided dual operations saves money and internal resources.
Avoid “Scope Creep” in Licensing:
A common trap is that, as you migrate, business units say, “Since we’re doing this, can we also implement X new module?” – for example, adding on SAP CRM or a new analytics tool. While S/4HANA brings many new capabilities, try to phase in enhancements so that you don’t buy many extra components in the initial migration, unless necessary for go-live.
Stick to a minimal viable scope for migration (to control project complexity and license cost) and plan add-ons in later phases when the value is clearer. If you do decide to include new modules, ensure they are used; if not, you might be paying license and maintenance for something sitting idle (classic shelfware).
License Management and Auditing:
Continue to use tools to track license usage during and after the migration. S/4HANA comes with measurement tools too. If you’re on subscription (RISE), watch the FUE consumption. If on-prem, run SAP’s License Audit (LAW) regularly. An advantage of FUE is easier oversight of total usage, but you should still ensure the user-role mappings in S/4 are accurate so that you’re not “burning” more FUEs than necessary.
For on-premises, a big risk is overutilization leading to compliance liability – for instance, if extra contractor users were given access without licenses during migration. Keep discipline in user provisioning even amidst project pressures.
Ideally, assign someone the role of License Coordinator during the project who checks that test users or temporary users have appropriate licenses or are removed after use. SAP audits can and do occur during these big transitions, and SAP will want to ensure that all ECC use was licensed up until decommission and all S/4 use after is licensed. Having a clean record will avoid surprise bills.
Shelfware Avoidance Tactics:
If you end up in a situation where you have more licenses than needed (perhaps the project’s scope was reduced or some divisions didn’t migrate), what can you do? If perpetual, you can drop them from maintenance (shelf them) to save on ongoing costs, though you have already paid for them initially. In a conversation, hopefully, you avoided buying them in the first place. If you have a subscription, you’re stuck until the renewal, but you can plan to reduce it at that point.
Communicate early if you see that some users won’t materialize; sometimes SAP may allow a concession (not typical in the mid-term, but definitely at renewal).
The best tactic is proactive: negotiate a degree of elasticity – perhaps a clause that says if, after one year, you find you purchased more than 10% more FUE than needed, you can reduce the subscription by that excess. SAP normally resists reductions, but if you negotiate it upfront as a risk share, they might agree to a one-time adjustment.
Utilize SAP’s Cloud Flexibility (if in the cloud):
In RISE, if one part of your business under-uses licenses, you might deploy them elsewhere (e.g., if one affiliate isn’t ready to go live, maybe another affiliate can use those users). In effect, maximize the value of what you’re paying for – use all your FUEs, use all your BTP credits, etc., since you’re paying for them. Unused entitlements in a subscription are wasted dollars. Make it a KPI in your program to have, for example, a high “FUE utilization rate”.
Consider Third-Party Maintenance as a Backstop:
This is a more strategic financial lever. Some companies that are not ready to migrate by 2027 will consider switching their support to third-party providers like Rimini Street. This sacrifices new updates, but provides support at typically 50% of SAP’s maintenance cost and can buy time without paying SAP’s extended maintenance.
Even if you plan to migrate, the threat of moving to third-party support can be a negotiating lever. SAP would prefer to keep you as a maintenance customer (or get you on an S/4 subscription) than see you go to a third-party provider.
Use this option carefully – it’s a nuclear option in terms of the relationship with SAP. But from a pure cost view, if budgets are cut and you absolutely can’t migrate by 2027, third-party support could keep ECC running until you’re ready, at a lower cost.
Just remember, if you go that route, SAP will not support your eventual migration unless you reinstate support (with likely back-maintenance fees), which could be costly. It’s more of a last resort or pressure tactic than a preferred plan for most, but as CIO, you should know it’s out there.
ROI Tracking:
During the project, track the benefits being realized to justify the costs. For instance, if you retire a legacy system because S/4 has that functionality, note the cost saving of that retirement. If you reduced cycle time in a process, quantify the gain.
This doesn’t directly reduce SAP costs, but it helps demonstrate the business value of the investment, which keeps management support strong and avoids situations where cost-cutting executives might pause the project, which could paradoxically increase costs later. A well-run project that meets its business case is less likely to face budget cuts, which can create inefficiencies such as half-deployed modules (a ‘shelfware’ scenario).
Post-migration Optimization:
After go-live, conduct a post-mortem on licenses: did we end up buying any S/4 components we’re not using? If yes, can we start using it (maybe a module that was deployed but not utilized)? Or if not, can we negotiate something with SAP (maybe swap it for another module we do need).
SAP wants S/4 projects to be success stories, so sometimes they may allow a swap or provide consulting to help you utilize an unused component. Don’t let those licenses sit idle without pushing for value.
Recommendations for CIOs:
1) Install strong financial governance in the project – have the project management office (PMO) report on license usage and costs against budget at major milestones. Treat licenses as an asset to be optimized, not an afterthought.
2) Empower a License/SAM (Software Asset Management) specialist to join the migration team. This person or team should forecast license needs for each project phase and monitor actual usage.
3) Tightly manage system access: During testing, give the project team temporary IDs that you can remove later; don’t just open the floodgates and accidentally let hundreds of users access both systems without proper licensing.
4) Plan the decommission of ECC carefully – have a target date to shut off ECC production, and stick to it. Every delay likely means another month of maintenance fees. If read-only access is needed, find alternative ways, such as exporting data to a low-cost database or using SAP’s Information Lifecycle Management tools.
5) Use the flexibility of FUE or named user reclassification – if one department reduces its headcount, you can reallocate those licenses to another, avoiding the need to buy more. Make license rebalancing a periodic task, at least once a year.
6) Keep communication open with SAP if you find yourself with excess licenses – sometimes they’ll propose a solution, such as converting some to a different type of license or using them for an affiliate.
7) Finally, benchmark and audit your costs: compare your SAP run costs (licenses, maintenance/subscription, and infrastructure) before and after migration. Ideally, moving to S/4HANA should also bring some operational cost efficiencies, such as reduced hardware costs, etc.
If not, you may need to optimize elsewhere to fulfill the promise that this migration wasn’t just an expense but an opportunity to run IT more efficiently.
