What is Rise with SAP
- Rise with SAP is a subscription-based cloud service for businesses using SAP.
- Includes SAP S/4HANA Cloud, cloud infrastructure, and business transformation tools.
- Offers flexibility with private or public cloud hosting options.
- Reduces IT complexity by bundling software, hosting, and support.
- Ideal for companies moving from on-premise to cloud ERP.
What is Rise with SAP?
SAP’s ERP Central Component (SAP ECC) has been the digital backbone for many large enterprises for decades.
However, a major shift is underway: SAP is ending mainstream support for ECC by 2027, prompting customers to move toward its next-generation ERP, SAP S/4HANA.
In parallel, SAP has introduced RISE with SAP, a new cloud-centric subscription model that changes how enterprises license and run SAP software.
For CIOs and IT decision-makers, these changes bring both urgency and opportunity.
This article examines the significance of ECC’s end, the differences between S/4HANA and RISE with SAP, and the status quo, and provides strategic recommendations for navigating the transition.
We’ll explore ECC’s legacy role and sunset, its impact on operations and strategy, an overview of S/4HANA’s innovations, and an in-depth look at RISE with SAP (its benefits, drawbacks, and licensing implications).
Five strategic recommendations covering licensing strategy, financial planning, contract negotiations, migration approach, and risk mitigation to help enterprises chart a successful path forward.
Read CIO Playbook: Migrating from SAP ECC 6.0 to SAP S/4HANA.
💡 Make Smarter Licensing, Contract, and Cloud Decisions with Confidence
- Avoid overpaying for user licenses and cloud capacity by learning to right-size your SAP RISE subscription.
- Understand the true financial trade-offs: subscription fees vs. perpetual license value, infrastructure bundling, and support scope.
- Gain visibility into hidden costs often overlooked, from indirect access to BTP overages and contract renewal uplifts.
- Discover how mid-size companies have negotiated better deals, secured future flexibility, and maintained control post-transition.
- Free up IT and procurement capacity by simplifying contract management — without locking your organization into restrictive long-term terms.
Download CIO & Procurement Playbook: Transitioning to SAP RISE with S/4HANA
SAP ECC: The Legacy Core of Enterprise IT and Why It’s Ending
SAP ECC (ERP Central Component) is the core of SAP’s traditional ERP suite, managing everything from finance and HR to supply chain and manufacturing in a modular, integrated fashion.
Its flexibility and richness made it a standard for large enterprises worldwide.
ECC’s modular design allows for extensive customization, but it also means that changes in one area can impact others, requiring careful governance of upgrades and modifications.
For years, ECC 6.0 (part of SAP Business Suite) has been the “stable workhorse” of enterprise IT, so why is SAP planning to end mainstream support?
The key reason is SAP’s strategic shift to SAP S/4HANA, a modern in-memory-based ERP introduced in 2015. SAP aims to focus innovation on the new platform and encourage customers to adopt it, rather than maintaining two parallel ERP product lines.
ECC is built on an older technology stack (it can run on third-party databases and the classic SAP GUI interface) and was not originally designed for the real-time analytics and cloud capabilities that businesses now demand.
As SAP puts it, the decision to sunset ECC by 2027 reflects “the fast-shifting nature of the digital age,” prompting businesses to move to a platform that leverages advanced analytics, in-memory computing, and a modern user experience.
In short, SAP is retiring ECC to pave the way for the future S/4HANA and to ensure customers are on an “intelligent enterprise” platform that can continuously evolve.
Importantly, SAP has already extended the ECC support deadline once.
Initially, mainstream support was set to end in 2025, but in 2020, SAP extended it to 2027, providing customers with more time to prepare.
For those who cannot migrate by 2027, extended maintenance until 2030 is available at an additional cost.
After 2027, ECC will enter customer-specific maintenance (with no new fixes or legal updates without a special contract) or third-party support, effectively becoming a legacy system.
SAP has signaled that 2027 is a firm deadline this time.
Mainstream innovation is already focused on S/4HANA, and enhancements to ECC beyond critical fixes have been halted.
CIOs must interpret this as a clear message: continuing to run ECC past this date means using an out-of-date system.
To put the scale of impact in perspective, SAP ECC is deeply entrenched in large enterprises.
It’s estimated that roughly 70% of Fortune 500 companies run SAP in some form.
Yet many have been slow to move: as of 2021, only about 33% of SAP customers in the Americas had completed a migration to S/4HANA.
Even by mid-2024, industry data showed that over 60% of SAP ECC customers had still not purchased S/4HANA licenses – i.e., the majority had yet to make the transition.
Read 15 Things CIOs Need to Know About SAP ECC End of Life and RISE with SAP.
The Impact of ECC’s End-of-Life on Large Enterprises
The impacts are broad when a core system like SAP ECC faces end-of-life.
For large enterprises, the operational risks and strategic challenges of ECC’s support ending are significant:
- Loss of Support and Security Risks: After support ends, ECC will no longer receive regular security patches, updates, or fixes. This leaves organizations vulnerable. No patches mean increased exposure to cyberattacks, as new vulnerabilities won’t be addressed. In today’s environment of sophisticated attacks, running an unpatched ERP system is a huge risk. CIOs also worry about regulatory compliance – SAP regularly updates ECC to comply with changing tax laws, trade regulations, and other relevant updates. Without these, companies could quickly fall out of compliance post-2027. (Extended support from SAP, if opted, comes at a high premium and even then does not deliver new features, only basic support.) In short, staying on ECC beyond its life means increasing security and compliance risks with each passing month.
- Operational Disruption and Cost: Running a legacy ERP without vendor support can become an expensive headache. Companies may face higher costs to maintain ECC internally or via third-party support, and any new issues may require custom fixes. SAP has stated that continuing ECC maintenance after 2027 will incur an additional premium, reportedly around 2% per year, on annual support fees beyond 2027. If nothing is done, ECC systems will transition to “customer-specific maintenance,” where legal changes or interoperability updates are not provided. Internal IT teams must find workarounds for new requirements, raising IT overhead. Some organizations consider third-party support providers to avoid SAP’s fees, which typically yield only support for existing functionality and no innovation. Moreover, as time passes, the ecosystem of skills and integrations around ECC will decline, making it harder to find expertise or compatible add-ons. This translates to a higher long-term total cost of ownership (TCO) if one tries to cling to ECC.
- Strategic Stagnation: Perhaps the biggest impact is strategic. Not migrating off ECC means forgoing the innovations SAP has built into S/4HANA and related platforms. SAP S/4HANA comes with over 600 new functional improvements and modern capabilities that ECC lacks – from real-time analytics and machine learning to streamlined processes, which we will explore in the next section. An organization that stays on ECC will miss these benefits, essentially freezing its digital evolution on an aging platform. This can directly hurt competitiveness. For example, companies on S/4 can perform real-time financial closes and embedded analytics, whereas an ECC shop might still be running overnight batch jobs and using Excel extractions. Over time, the gap widens: business processes on ECC may become slower and less efficient compared to those of peers who have modernized their systems. A legacy ERP could hinder a company’s ability to innovate and respond to market changes driven by AI, IoT, and rapid data-driven decision-making. As one SAP partner noted, refusing to migrate “impedes the digital transformation” of the company, limiting the adoption of cutting-edge technologies and embedded intelligence that S/4HANA offers.
- Competitive Pressure: By 2027, many competitors and industry peers are expected to have transitioned to S/4HANA. Those who haven’t will feel increasing competitive pressure. Companies that have successfully migrated report gains in productivity and efficiency, reduced manual labor, and improved decision-making. These translate to cost savings and agility that can improve market position. Enterprises stuck on ECC face higher operating costs (due to inefficiencies and workaround processes) and risk appearing as technology laggards in the eyes of investors and partners. It’s telling that SAP’s deadline itself is driving industry momentum – ‘2027 is the date that will drive us and our industry for the next few years,” as one SAP community commentator put it. No CIO wants to be the one running a “corporate relic” ERP while competitors forge ahead.
- Resource and Skills Crunch: A more tactical yet important impact is the upcoming talent crunch for S/4HANA migration skills. As the deadline nears, the demand for consultants, SAP experts, and internal project teams to execute migrations is skyrocketing. There may be insufficient expert resources if too many companies wait until 2026-2027 to start projects. This could inflate the cost of projects and lengthen timelines for those who lag. CIOs must consider this scheduling risk: starting early means better access to skilled resources while waiting could leave your project understaffed or result in higher costs. The ‘2027 wave” is a real phenomenon – models predict a potential skills crisis if many organizations jump at the last minute. In practical terms, this means higher consulting rates and longer wait times for SAP’s attention as the deadline approaches.
In summary, ECC’s end-of-life forces a choice: either incur growing risks and costs by maintaining an unsupported system or undertake the challenge of migrating to S/4HANA (or an alternative platform).
The prudent approach for large enterprises is to view this as an opportunity for transformation rather than merely an IT issue.
Read RISE with SAP vs Traditional On-Premise SAP Licensing.
SAP S/4HANA: The Next-Generation ERP and How It Differs from ECC
SAP S/4HANA is SAP’s flagship next-gen ERP suite, released in 2015 as the successor to ECC. It represents a major technological and functional leap.
Unlike ECC, which could run on various databases, S/4HANA runs exclusively on the SAP HANA in-memory database, leveraging HANA’s speed for real-time processing.
SAP rebuilt the software using in-memory computing, simplified data models, and modern user interface principles.
For CIOs evaluating the move, it’s crucial to understand how S/4HANA differs from ECC in IT architecture, business process design, and user experience.
S/4HANA includes 80-90% of ECC’s core functionality at a high level but modernizes or reimagines many aspects.
Here are some key differences and changes enterprises should expect when transitioning to S/4HANA:
- Database and Performance: ECC can run on third-party databases, including Oracle, IBM Db2, and SQL Server. In contrast, S/4HANA runs only on SAP’s HANA database, which is in memory. Data is largely stored in RAM, enabling faster transaction processing and real-time analytics. For example, long-running batch jobs in ECC, such as MRP or financial reconciliation, can often be run live in S/4 due to HANA’s performance. The trade-off is that moving to S/4HANA requires a database migration (if you’re not already on HANA) and an investment in HANA-skilled database administrators (DBAs). However, the payoff is significant improvements in reporting speed and the ability to analyze big data in real-time – a cornerstone of the “real-time enterprise” promise of S/4.
- User Experience (UI): SAP S/4HANA introduces SAP Fiori as its primary user interface, replacing or complementing the traditional SAP GUI. Fiori is a modern, role-based, web-friendly interface that provides a more intuitive and consistent user experience across devices. Users get interactive tiles, drill-down analytical apps, and a friendlier look and feel, which can reduce training time and improve productivity. In ECC, most users use the older GUI with transaction codes, which is an effective approach but often not user-friendly. CIOs can expect a significant improvement in user experience (UX) with S/4HANA, which could lead to better user adoption and satisfaction. (This also means change management is needed – users will need training to adjust to Fiori apps after years of SAP GUI.)
- Data Model Simplification: S/4HANA’s data model has undergone significant simplification. Many aggregate and index tables in ECC have been removed, allowing HANA to compute totals on the fly. A prime example is the universal journal (table ACDOCA), which merges the once-separate Finance (FI) and Controlling (CO) data into a single, unified source of truth. FI and CO required reconciliation in ECC because the data was stored in different tables. In S/4, FI and CO are unified, eliminating the need for reconciliation steps. This simplification extends to material management, where the MATDOC table in S/4HANA replaces multiple inventory tables in ECC. Additionally, many legacy tables, over 25 in logistics, were eliminated or replaced in S/4. For IT, a simpler data model means fewer inconsistencies and faster analytics, but it also means that custom ABAP programs that read old tables may need to be adjusted. Expect a thorough custom code review as part of the migration – e.g., any ECC code referencing removed tables (such asBKPF, BSEG for finance totals, or LIS tables for logistics) must be updated to use the new structures.
- Functional Innovations and Module Changes: S/4HANA isn’t just a technical upgrade; SAP took the opportunity to revamp certain business processes:
- In Logistics and Supply Chain, S/4HANA embeds capabilities that were separate add-ons in ECC. For instance, Extended Warehouse Management (EWM) and Advanced Available-to-Promise (aATP) are built into S/4 (replacing ECC’s WM module and basic ATP) to provide more advanced warehousing and order promise functionality out of the box. The old SAP APO (Advanced Planning and Optimization) functions for forecasting and MRP have their core components embedded as PP/DS and live MRP in S/4, allowing for real-time MRP runs instead of batch processing.
- Sales and Customer Management: The separate customer and vendor master data in ECC are unified in S/4HANA under the Business Partner concept. This is a significant data model change: companies must migrate their customer and vendor records into the new Business Partner format. Still, it yields a single common master data for all partner roles, simplifying data maintenance and enabling richer relationships (e.g., a single entity can be both a customer and a supplier).
- Finance: Aside from the universal journal, New Asset Accounting is mandatory in S/4 (where ECC allowed classic asset accounting), and Revenue Accounting and Recognition (RAR) is introduced to handle new accounting standards (IFRS 15) – replacing ECC’s SD Revenue Recognition module. The credit management functionality in ECC (FI-AR and SD Credit Control) is replaced by Financial Supply Chain Management (FSCM) Credit Management in S/4, which is more integrated and requires setting up the new FSCM component.
- Simplified Processes: SAP has often highlighted that S/4HANA removes historical artifacts. For example, customer rebates in ECC (handled through SD rebate agreements) are replaced by Condition Contract Settlement in S/4, part of the Settlement Management framework – a more flexible approach for rebate and incentive programs. Many such changes mean that certain ECC transactions or configs are obsolete in S/4 and must be re-implemented using new approaches.
- Embedded Analytics and AI: S/4HANA comes with built-in analytics via SAP Fiori analytical apps and SAP Analytics Cloud integration, allowing real-time insights from transactional data. This was only possible with separate business intelligence (BI) systems in the ECC era. It also includes options for predictive analytics, machine learning scenarios (e.g., SAP Cash Application for automated matching, embedded in S/4), and conversational interfaces. While ECC could integrate with these technologies, S/4 has them more natively integrated – SAP brands S/4 as an enabler of the “Intelligent Enterprise,” ready to plug into IoT, AI, RPA, etc., more seamlessly.
- Deployment Options (On-Premise vs. Cloud): ECC was traditionally on-premise (or hosted on IaaS) with a perpetual license model. S/4HANA is offered in multiple editions, including on-premise (traditional licensing) and cloud editions (S/4HANA Cloud, which comes in public multi-tenant or private cloud flavors). Functionally, the on-prem and private cloud editions are similar (both can have the full scope of modules, just with different licensing). In contrast, the public cloud edition is a more streamlined SaaS with quarterly updates and some customization limitations. This is important: enterprises can treat S/4HANA as a regular on-prem upgrade or a move to SaaS. We will discuss “RISE with SAP” next, a key program related to cloud deployment. However, even without RISE, S/4HANA enables CIOs to reassess their infrastructure strategy – to continue managing their ERP in-house or to let SAP or the cloud handle it.
Read RISE with SAP to Cloud ERP Licensing.
RISE with SAP: What It Is, Benefits & Drawbacks, and Licensing Implications
In January 2021, SAP introduced RISE with SAP, branding it as a “business transformation as a service” offering.
RISE with SAP is not a new ERP product per se but rather a bundled subscription offering that packages SAP S/4HANA (in a cloud edition) with a collection of additional services and cloud infrastructure under a single contract.
SAP’s goal with RISE is to simplify the transition to S/4HANA and the cloud by providing an all-in-one solution, a single contract, and a single vendor (SAP) responsible for software, hosting, and support.
So, what exactly does RISE with SAP include?
In SAP’s description, RISE with SAP bundles five core elements: SAP S/4HANA Cloud (the digital core ERP itself, which can be a private or public edition).
SAP Business Process Intelligence (tools to analyze and optimize processes, acquired via Signavio), SAP Business Technology Platform (BTP) credits (for integration and extension development),
SAP Business Network access (e.g., limited access to networks like Ariba for suppliers, Asset Intelligence Network, etc.), and some embedded tools and services (like readiness checks, technical migration tools, and SAP support services).
Benefits of RISE with SAP:
- Single Contract & Simplified Engagement: One of the biggest selling points of RISE is the simplicity of a single contract for what would traditionally be multiple agreements. Typically, a customer purchasing S/4 would require a software license agreement, a support agreement, a hosting contract with a cloud provider (or a hardware purchase for on-premises use), and possibly a systems integrator contract, among other documents. With RISE, SAP consolidates many of these into one: you pay SAP a subscription, and SAP takes care of the software, the infrastructure (provisioned in SAP’s cloud or a hyperscaler of your choice), and basic technical management. This “one hand to shake” approach can reduce the complexity of procurement and vendor management. CIOs appreciate having a single point of contact if things go wrong – SAP is accountable for SLAs rather than finger-pointing between the software vendor and hosting provider. For organizations that find SAP licensing and deployment too complex, RISE offers a more as-a-service approach: one bill, one point of contact.
- Faster Cloud Adoption with Flexibility: RISE is fundamentally about moving to cloud ERP on your terms. SAP allows RISE customers to choose the hyperscaler (Azure, AWS, GCP) for hosting their S/4 system, giving some flexibility to align with existing cloud preferences (e.g., if you already have a strategic partnership with Azure, you can host your RISE S/4 there – SAP will just manage it for you). You can also choose between a Public and Private cloud edition for S/4HANA. The Private Edition under RISE is essentially your instance of S/4HANA, with full functionality and the ability to carry over customizations hosted in a private cloud. The Public Edition is a more standardized, multi-tenant SaaS. This flexibility allows RISE to cater to those who require more customization (via the private option) or those who are satisfied with standardized processes (public option).Additionally, RISE includes tools to accelerate the migration process. Forexample, SAP provides assessments and some automated conversion tools as part of the package, aiming to remove guesswork and reduce project time. SAPclaims RISE can “reduce TCO by up to 20%” compared to a traditional on-site ERP deployment. (This figure should be taken with a grain of salt, as actual savings vary, but it’s an assertion that bundling and cloud infrastructure can be more cost-effective in the long run.)
- Built-in Transformation Resources, including Business Process Intelligence (BPI) and other tools in RISE, are a notable benefit. SAP acquired Signavio and integrated its process mining and analysis tools to help customers analyze their current processes (in ECC) and identify ways to improve or map them to S/4 best practices. This means a RISE customer can more easily identify process simplification or optimization opportunities during the migration. Additionally, the SAP Business Network starter pack provides access to connect with suppliers or partners (such as the Ariba Network), which can help jump-start the benefits of collaboration. Essentially, SAP bundles the core ERP and some surrounding components to help achieve the promised business outcomes. For a CIO, you get a more comprehensive toolkit to drive business transformation, not just a technical migration. As one analysis put it, RISE is “more than just the migration to S/4HANA” – it’s packaged as a holistic transformation offering, including process redesign and intelligent technologies.
- Licensing and Financial Incentives: RISE, a subscription-based service, can be financially attractive in certain ways. It converts your spending to OPEX (operational expense) instead of CAPEX, which some CFOs prefer for flexibility. It also protects existing investments by allowing conversion of your current SAP licenses/maintenance into the RISE subscription value – SAP has offered programs where the unused portion of your existing ECC maintenance can be credited toward the RISE subscription fee (so you’re not “double paying” during overlap). Additionally, SAP has been known to give discounts or incentives to early RISE adopters. For example, if you’re a strategic customer, SAP might include extra services, more BTP credits, or training as part of the deal. The Full User Equivalent (FUE) licensing model used in RISE, which pools user licenses into a flexible usage metric, can also be a boon – it simplifies user licensing by allowing you to have a mix of user types without needing to purchase each type separately. For instance, instead of buying 100 professional user licenses and 200 limited licenses, you might contract for a specific number of FUEs, which you can allocate as needed (e.g., 1 FUE can cover 5 “Core” users or 30 self-service users). This model offers greater flexibility in adjusting user roles over time, eliminating the need for license renegotiations.
- Reduced Infrastructure Burden: With RISE, SAP (and its hyperscale partners) take over the management of infrastructure and basic system operations. Companies no longer need to maintain their data center hardware for SAP if they fully embrace RISE. This can free IT teams from low-level tasks, allowing them to focus on higher-value activities or even reduce headcount and costs related to basic administration. RISE offers a rapid pathway for firms with aging hardware or those seeking to exit the data center business. It’s essentially SAP outsourcing plus software in one. Additionally, SAP guarantees specific service levels (SLAs) in RISE – by default, approximately 99.7% uptime for production, which may exceed the uptime achieved by some companies on-premises. (Higher SLAs like 99.9% can be negotiated, though it may cost more.)
Have you heard about the SAP ERP Private Edition Transition Option?.
Despite these benefits, RISE with SAP is not a one-size-fits-all solution and may not be suitable for everyone.
There are important drawbacks and considerations to weigh:
- “Lock-In” to SAP’s Cloud: When you go with RISE, you essentially commit your core ERP to SAP’s managed cloud for the foreseeable future. You give up some control. For example, you cannot run RISE solutions on your infrastructure – it’s cloud-only. If your strategy later shifts to bring systems back in-house or switch to another cloud provider directly, exiting a RISE contract may be complicated and costly. Analysts have noted that the motive behind RISE is to move customers to SAP’s cloud model and “lock you in” via subscription. All major vendors seek lock-in, of course, but with ERP, it’s especially sticky. CIOs should go in with eyes open: after transitioning to RISE, moving off (either back to on-premises or a different SaaS) would be a brand-new migration project. Ensure that the comfort of one contract is worth the loss of flexibility in the future.
- Less Negotiation Leverage on Infrastructure: Under RISE, SAP handles the contract with the hyperscaler (Azure, AWS, or GCP) on your behalf. While convenient, this means you don’t directly negotiate cloud infrastructure pricing or terms – it’s baked into the RISE subscription. Some enterprises with significant cloud spending may be able to secure better discounts or terms by negotiating directly with cloud providers. Those benefits are somewhat hidden inside RISE. Indeed, it has been observed that hyperscaler cost transparency is lacking in rising deals – customers can’t tell how much of their fee is for infrastructure versus software. This could lead to uncertainty or suspicion that you’re not getting the best deal. If you already have large contracts with AWS, you might prefer to leverage those for an S/4 deployment rather than pay SAP to act as an intermediary. RISE essentially isolates your IaaS strategy for SAP workloads from the rest of your cloud strategy. Some companies find this “island” approach unappealing if they’ve standardized cloud management and want direct control.
- Complex (and Potentially Costly) Contracts: Ironically, while RISE is designed to simplify, the contract negotiation process for RISE can be complex in its own right. The bundle contains many components; not everything may be included by default, so you must carefully review what is in scope. For example, services such as disaster recovery, additional non-production systems, or higher availability tiers may incur extracosts. Without a comprehensive negotiation, customers may assume something is covered when it’s not, leading to unexpected costs later. Additionally, some commercial terms that customers may have been accustomed to in their previous contracts, such as specific price protections, flexibility in swapping licenses, or volume discounts, are not automatically carried over into RISE agreements. You need to negotiate those anew. Renewal terms also need attention – if you sign a 5-year RISE subscription, what happens when it renews? You could be facing a significant uptick if not capped. In short, navigating a RISE contract requires just as much savvy as a traditional SAP contract to ensure you aren’t giving up important rights or vastly overpaying in the long run. Due to these nuances, many advisors suggest getting expert help to negotiate RISE deals.
- Functional Parity and Limitations: While S/4HANA, especially in a private cloud, can offer the full functionality of on-premises systems under RISE, certain aspects of the system change in a cloud model. You might be restricted from certain modifications – SAP encourages “clean core” (no or low customization) in the cloud. If your ECC is heavily customized, moving to RISE (particularly the public cloud edition) may require dropping or reengineering customizations to align with the standard. Also, integrating third-party solutions may be more challenging if they cannot be deployed in the RISE environment. One risk cited is that customers cannot directly install third-party add-ons in the RISE environment, unlike on-premises environments. These must be managed via SAP. This can limit flexibility or require you to involve SAP for tasks that you previously handled yourself. Moreover, legacy software or modules that aren’t supported in S/4HANA Cloud become an issue – for instance, if you use an industry solution or a highly customized module, you need to confirm it’s supported in the RISE context. RISE best suits customers who are willing to embrace standardization or primarily use mainstream SAP. Those with very unique or bespoke extensions might feel constrained.
- Cost Considerations: There is an ongoing debate about whether RISE saves costs. SAP claims that the reduction in TCO comes from eliminating hardware capital costs and streamlining operations. However, some customers find that when they price it out, RISE’s subscription can be equal to or higher than their current annual spend when including all extras. The shift from a capital license plus yearly maintenance (around 22% of the license cost) to a pure subscription could be more expensive over the long term, depending on how SAP prices the deal. Current SAP customers often have high sunk costs in licenses; if those are converted to a subscription, it is essential to ensure they receive credit. SAP’s recent move to retire some conversion credits, which forces contract conversions, means that many customers will have to undergo a full-value conversion anyway. Also, with RISE all-in-one, you might pay for bundled components you don’t fully use. For example, if you don’t heavily use the Business Network or BTP credits, that value might not be realized, yet it’s in your price. In short, RISE may not be the most cost-effective option for everyone – its value lies in simplification and cloud acceleration; however, each enterprise should conduct its own financial comparison. One analysis pointed out that companies averse to moving from CAPEX to OPEX might resist RISE purely because of accounting preferences or uncertainties about long-term costs.
- Impact on Existing Relationships and Skills: If you have a long-standing outsourcing partner or an internal BASIS team managing your SAP, switching to RISE could disrupt these arrangements. For instance, you may be getting a good deal on infrastructure or have a third party managing SAP operations. RISE would replace some of those roles with SAP-provided services. This can strain relationships with other vendors or lead to internal team redundancies. It’s not necessarily a negative (maybe an efficiency). Still, CIOs should be prepared to reallocate or reduce the internal SAP technical staff or find new roles, focusing on value-added activities like innovation on BTP rather than basic administration. Additionally, RISE’s operational model is based on SAP’s standard approach – some customers have reported that it may be less flexible or responsive than having your team or a familiar managed service provider (MSP). You’re betting on SAP (or their chosen hosting partner) to provide excellent service.
To summarize, RISE with SAP is an attractive option for migrating to S/4HANA in the cloud, offering simplicity and a faster route to transformation.
However, it comes with trade-offs in control, flexibility, and potentially higher costs.
CIOs considering RISE should weigh the convenience of a one-stop shop against the loss of direct control and ensure they negotiate the contract carefully.
For some large enterprises, a hybrid approach may be suitable (e.g., migrating some systems via RISE, others via a more traditional path, or utilizing RISE for a period and then reevaluating).
Five Strategic Recommendations for Navigating the Transition
Transitioning from SAP ECC to SAP S/4HANA (and potentially adopting RISE with SAP) is a complex journey that spans technology, finance, contracts, and risk management.
Based on industry insights, here are five strategic recommendations for CIOs and IT leaders at large enterprises to navigate this change proactively and smoothly:
Reevaluate and Optimize Your SAP Licensing Strategy
Take a thorough review of your current SAP license landscape and future requirements.
The move to S/4HANA often coincides with a shift from perpetual to subscription licensing models. Start by assessing what you own: your existing ECC user licenses, engine licenses, and contractual agreements.
Engage with SAP early to understand your options for conversion.
SAP has offered conversion programs, historically offering two paths: “product conversion” (swapping licenses line by line) and “contract conversion” (a wholesale exchange of your ECC contract for an S/4 contract).
Recently, SAP retired the product conversion option for S/4HANA, meaning that most customers must now perform a full contract conversion or opt for RISE.
In practice, you will terminate your old ECC license contract and sign a new S/4HANA agreement (either as a perpetual license or a subscription).
Treat this negotiation as a critical project in its own right.
Read SAP Rise Negotiation and Contractual Challenges.
Consider whether RISE with SAP’s subscription model or a traditional on-prem license is better for your strategy.
If you prefer to manage your own CapEx and environment (or use a preferred cloud partner), you can stick with perpetual licensing and standard S/4HANA contracts.
Ensure SAP provides you with a quote for S/4HANA perpetual licensing.
As noted, they may push RISE, but you are entitled to a comparison. If the one-stop subscription appeals to you, carefully evaluate the RISE model.
Note that under RISE, you cannot purchase additional perpetual licenses; growth will be achieved through subscription expansion.
Additionally, existing ECC licenses don’t simply carry over; typically, SAP will credit a portion of your existing maintenance payments toward the RISE subscription, often referred to as a migration credit or conversion discount.
Scrutinize the offer. What percentage of your current maintenance spend will be recognized?
And ensure you retire licenses you don’t need. Many enterprises have shelfware (unused licenses) from their ECC systems.
Build a Multi-Year Financial Plan for the Transition
Migrating to S/4HANA is not just an IT project; it’s a business investment.
CIOs should partner with CFOs to create a clear financial plan that covers the entire journey, from ECC today to S/4HANA (and possibly RISE) in the future.
Key elements to consider:
- Migration Project Costs: Estimate the cost of the technical migration or implementation. This includes software costs (e.g., new license or subscription fees), systems integrator or consultant fees, internal labor, data migration, testing, training, and change management. Depending on the size of your enterprise, a S/4HANA migration can cost anywhere from a few million to hundreds of millions of dollars for a global company – it’s substantial. Use SAP’s tools or external advisors to perform an assessment. Break the project into phases and attach costs to each (e.g., sandbox and POC, development and remediation, testing cycles, deployment). Don’t underestimate data cleansing and migration efforts – many companies find that considerable effort is required to extract, transform, and load data into the new S/4 structures and validate it.
- Infrastructure and Cloud Costs: If you plan to stay on-premises, factor in any hardware refreshes or expansions for HANA. (HANA appliances or certified hardware can be expensive.) If moving to the cloud (whether via RISE or self-managed on IaaS), forecast the cloud subscription costs. RISE will give you a single price – ensure you understand how it scales over the years (does it have annual increases?). If you’re self-managing on IaaS, model your cloud consumption (VMs, storage, and network) and include it in your budget. Remember that HANA can be memory-intensive so that infrastructure costs may be higher per system than in your current ECC environment.
- Parallel Operations and Sunset Costs: During the migration, you may need to run ECC and S/4 in parallel for a time (for testing or phased go-lives by region or business unit). This can temporarily increase costs, such as doubling the cost of infrastructure or support. Plan for a period where you may simultaneously pay SAP maintenance for ECC and a subscription for S/4HANA, unless you negotiate relief. Additionally, it includes costs associated with retiring the old system, such as data archiving, shutting down hardware, and any contract termination penalties for legacy systems or support vendors.
- Licensing and Maintenance Trajectory: Map out how your annual SAP costs are expected to change. For instance, if you pay $X in maintenance today and after moving to RISE, you’ll pay $Y in subscription; plot those out. Often, maintenance on ECC may increase, as noted. If you need extended support, SAP may levy an additional percentage fee. Conversely, once you switch to S/4, maintenance on ECC drops off. If you are doing a phased migration, you may be able to reduce maintenance in proportion to the number of users. Work with SAP on a maintenance conversion plan – sometimes SAP allows a maintenance holiday or reduction when ramping up S/4. Ensure the CFO’s team knows the one-time migration costs versus the ongoing run costs after migration. The business case for S/4HANA can be strengthened by quantifying potential savings. For example, if S/4HANA and process improvements reduce inventory or enhance efficiency, these are dollar savings that should be factored into the calculation. Some companies justify the project by linking it to efficiency gains (e.g., a faster closing process saves the finance department overtime, and better ATP reduces lost sales, etc.). Use SAP’s value engineering or your benchmarks to estimate these benefits.
- Contingency and Risk Buffer: It’s wise to add a contingency to the budget (e.g., 10-15%) for unforeseen issues. Migrations can encounter snags that require additional funding, such as extra testing cycles, extended parallel runs, or more training. Also, consider a buffer if the project timeline slips; if a 2-year project becomes a 3-year project, that’s an extra year of costs.
One important recommendation is to start securing the budget early and consider adopting a multi-year budgeting approach.
Given the 2027 deadline, many companies have spread their S/4 program budget over two to three fiscal years to manage the impact.
Communicate with the board and executives about the scale of this initiative, framing it as an unavoidable tech refresh and an opportunity for business improvement.
It often helps to compare the cost of migration with the cost of not migrating.
For example, potential fines for non-compliance, the potential revenue impact of a security breach on ECC, or the cost of extended SAP support (which could be 1.2 times or more than your normal maintenance).
Negotiate Contracts with a Long-Term Mindset
Contract negotiation with SAP (and partners) will define much of your cost and flexibility in the S/4HANA era, so approach it strategically.
Here’s what to focus on:
- Leverage the Timing and Competitive Options: Currently, SAP aims to encourage as many customers as possible to migrate to S/4HANA, preferably through RISE. This gives you leverage. Utilize your options: consider moving to S/4, staying on ECC with third-party support, or exploring alternative ERPs (although that’s a significant switch; the mere possibility can be leveraged). Start negotiations well before 2027 – don’t wait until your ECC support is nearly over when you have no choice. If you negotiate in 2024 or 2025, SAP knows you have time to consider other avenues, and you may secure better terms. Additionally, if you’re comparing RISE vs. on-prem, pit the proposals against each other: let SAP know you want to compare a RISE offer with a traditional one. If the RISE deal isn’t compelling enough, be ready to walk away to a perpetual license approach (or vice versa). Keep the ball in your court by not showing your hand too early about which way you’ll go.
- Include Future-Proofing Terms: If you sign up for RISE, ensure the contract covers features such as renewal rate caps (e.g., the subscription price cannot increase by more than a certain percentage at renewal unless tied to clear metrics, such as user count). Also, clarify what happens if you need more capacity or users. SAP typically sells additional FUEs or higher tiers, but consider negotiating the price for those expansions now if possible. On the other hand, flexibility should also be negotiated to reduce usage in case of divestiture or downsizing. Cloud subscriptions often don’t allow reductions until renewal, but you might be able to negotiate the ability to swap or drop certain components. Additionally, ensure that any unique discounts you receive now apply to renewals, not just a first-term teaser.
- Retain Important Protections: Many SAP customers have historically negotiated protections in their ECC contracts, such as price protection on user licenses, the ability to swap licenses for different types, and audit protections, among others. Don’t assume those carry over when moving to a new contract (S/4 or RISE). Specifically, ask for: Audit protection or resolution clauses (so that if during migration an audit finds something, you won’t be unduly penalized – SAP has used audits as a tactic to push RISE, so negotiate how audits will be handled fairly), transfer of licenses (if you acquire or divest businesses, can you transfer the contract?), and liability terms (cloud contracts often have different liability limits – ensure they are acceptable for your risk). If you are a global enterprise, ensure the contract covers all your affiliates or allow flexible deployment in different regions.
- Clarify the Scope of Services in RISE: For RISE deals, clearly define what is included and what is not. As mentioned, standard RISE might not include disaster recovery or only a certain number of sandboxes. If you need a robust disaster recovery (DR) environment or additional systems for training, include them in the package or at least price them now. SLA considerations: Is the default SLA (99.7%) sufficient? If you have a critical 24/7 operation that requires 99.9% uptime, negotiate that and understand the associated costs.Additionally, the support level: RISE includes SAP’s support (likely equivalent to Enterprise Support), but if you require SAP MaxAttention or a dedicated support team, this may incur an additional cost. Everything should be explicitly listed. A common mistake is assuming something like “SAP will do backups and retention for X days” – verify and document it.
- System Integrator and Partner Contracts: Alongside SAP, you’ll likely engage a systems integrator (SI) or consulting partner for the migration. Negotiate those contracts wisely, too. Given the fixed deadline, seeking fixed-price or outcome-based elements in the SI contract can be beneficial to avoid open-ended time-and-materials costs. For instance, tie a portion of the fees to a successful go-live by a specific date or quality metrics. Ensure the SI contract aligns with the SAP contract (e.g., if SAP delays provisioning something in RISE, the SI isn’t penalized, and you aren’t double-charged). Also, consider bringing in independent advisory (third-party consultants specializing in SAP contract negotiation) – their cost can often be more than offset by improvements in the deal you sign.
- Use Competitive Bids and Benchmarks: If possible, get multiple quotes – SAP isn’t the only option for implementation. You may not have an alternative to SAP for the software contract, but you do (unless you’re using RISE) for cloud infrastructure. A benchmark from AWS or Azure for running S/4 can help you evaluate SAP’s bundling. There are also providers offering hosting and management of S/4 (hyperscaler or private cloud) outside of RISE. If you decide RISE isn’t for you, you could negotiate licenses with SAP and then separately negotiate cloud hosting with, say, Microsoft or Amazon – sometimes those providers offer incentives to run SAP on their cloud (Microsoft, for example, has been known to contribute funding for SAP migrations to Azure). The key is not to accept the first offer – use all available leverage and market options to negotiate a deal structure that suits your enterprise.
Overall, the SAP contract should be approached as a long-term partnership.
Choose the Right Migration Approach and Timeline
How you execute the migration can be the difference between success and failure.
There are several approaches to migrating from ECC to S/4HANA, commonly labeled as “brownfield” vs. “greenfield” (with hybrid options in between, such as selective migration).
Deciding which approach (or combination) suits your organization is a strategic decision with implications on project duration, cost, and business disruption:
- Brownfield (System Conversion): This is essentially an in-place technical conversion of an existing ECC system to S/4HANA. It preserves all your business processes, custom code, and historical data, upgrading the system and data model to S/4. The benefit of Brownfield is that business disruption is minimized – users continue with familiar processes, and you don’t have to redesign everything. It can also be faster than a full reimplementation. However, to succeed, your current system needs to be in relatively good shape: you should be on ECC 6.0 EHP 6 or above ideally (older versions require interim upgrades), your data quality should be decent, and your custom code needs remediation for S/4 (which can be significant effort if you have a lot of Z code). If you have built huge amounts of custom development and are on an older release, some choices might be off the table – a pure brownfield might be too difficult. Tools like SAP’s Readiness Check will inform you of what needs fixing, such as identifying obsolete transactions and custom code that may break. Brownfield is often chosen by companies that want to perform a technical migration first (to migrate to S/4) and then gradually optimize processes within S/4, sometimes referred to as “transform at your own pace.” It’s worth noting that a brownfield conversion to S/4HANA can be achieved with minimal downtime techniques (SAP offers’ near-zero downtime’ tools) to minimize business impact. Therefore, for systems that cannot afford long outages, this approach can be tailored to be primarily an IT backend change.
- Greenfield (New Implementation): This means implementing a fresh S/4HANA system from scratch and migrating your data (master and open items/balances) to it, effectively treating it as a new ERP deployment. This approach enables you to redesign business processes from a blank slate, adopting S/4HANA best practices and eliminating outdated customizations and historical baggage. It’s an opportunity for business transformation – questioning why you did things a certain way in ECC and possibly simplifying or standardizing on the latest industry templates. The downside is change management: everything can change (transactions, reports, possibly organizational structures), so the business will face a steeper learning curve. It also means data migration is more complex (you must extract and load data, versus in a brownfield, the data is converted in place). Greenfield projects can take longer and often resemble a full ERP implementation, lasting 12 to 24 months or more, depending on the project scope. Many large enterprises go greenfield if their ECC is highly customized or fragmented, such as having multiple ECC instances that need consolidation. They also do so if the business sees a benefit in starting fresh. Sometimes, companies rationalize that their processes need an overhaul after 20 years on ECC. A greenfield approach can deliver a “clean core” S/4 system with no unnecessary custom code, which is better for future agility. Still, it requires strong alignment with business stakeholders to redefine processes.
- Selective or Hybrid Approach: Some approaches (often using specialized tools or services) fall somewhere in between, such as a selective data transition. This is where you bring in selective historical data or merge multiple ECC systems into one S/4 while selectively redesigning specific processes. It’s more complex, but it can be useful for consolidating regional ERPs into a single global S/4 or carving out a portion of the business onto S/4 first. These require expert help (firms like SNP or others have tools for BLUEFIELD®, etc.).
Deciding on an approach involves assessing your ECC system’s current state and aligning it with your business goals.
Perform a system assessment:
How customized is ECC? How much data do you have (in TBs)? This may influence the approach due to potential downtime.
Are your business processes harmonized or highly varied across units? A brownfield is feasible if your ECC is relatively clean, has few modifications, and is close to standard.
A greenfield might yield better long-term results if your ECC is a mess of workarounds and outdated processes.
Additionally, consider your timeline for 2027. If you’re starting late and under time pressure, a brownfield might help you reach S/4HANA faster (and then you can improve later).
A greenfield could be risky if it’s still not live by the end of 2027, you might have to extend ECC support because the new system isn’t ready.
Some companies choose a phased approach: for example, they quickly complete a technical brownfield conversion to meet the deadline, then progressively introduce new processes or reimplement certain modules on S/4 once they are on the platform (a two-step move).
Phasing and rollout strategy are other considerations.
A big bang (all at once) cutover versus phased go-lives by business unit or region. Large enterprises often do phased rollouts, for instance, migrating one division at a time to limit risk.
S/4HANA’s new features can sometimes allow coexistence (for example, Central Finance is a scenario where you can run the S/4 Finance component to consolidate financials while still using ECC for logistics in the interim).
Evaluate if interim hybrid scenarios are needed.
Moreover, decide whether to convert your development and sandbox systems early to practice. Many CIOs set up a sandbox S/4HANA conversion of ECC data early in the project.
This helps uncover issues and allows the team to familiarize themselves with S/4 before going live in the production system. It’s best practice to run multiple test migrations.
Importantly, don’t underestimate the need for data and custom code remediation.
Start identifying your custom Z programs and determine if they are still needed. Many ECC systems have accumulated technical debt over the decades.
Mitigate Risks with Strong Governance and Change Management
Any large ERP transition carries risks, including technological, operational, and organizational ones.
Having a robust risk mitigation plan is essential.
Key areas to focus on:
- Project Governance and Expertise: Establish a strong project governance structure. This should include executive sponsors (to give it priority and unblock issues), a steering committee that regularly reviews progress, and experienced project leadership. If you haven’t implemented SAP in a long time (since ECC was installed), ensure you bring in or develop the right expertise. Hire or train S/4HANA skilled resources early – whether they are architects, developers (ABAP for HANA, Fiori, etc.), or functional consultants who know S/4 differences. The market for these skills is getting tighter, so consider knowledge transfer programs with your implementation partner or formal training for staff. Investing in an SAP Center of Excellence (COE) internally can pay dividends during and after the migration.
- Change Management and Training: One of the biggest risks is user adoption. If users are not prepared, a go-live can disrupt business. Begin change management efforts well in advance. Communicate the reason for the change (end of ECC, benefits of S/4) to get buy-in. Identify change champions in business units. Provide training in the new SAP Fiori interface and processes before their live implementation. Consider using simulations or sandbox systems to give users hands-on practice. The transition from ECC to S/4 is significant for end-users in certain roles, particularly finance, where the close process may change, as well as procurement, among others. Therefore, robust training and support during cutover will help mitigate productivity dips. Additionally, update any integrations or downstream systems and ensure that the relevant teams are ready (e.g., the BI team if reports originate from a different schema).
- Technical Risk Mitigation: As mentioned, do trial runs. Use the “dress rehearsal” concept – perform at least one full-volume mock migration in a QA system to measure how long it takes and any data issues. This helps tune the migration approach and gives confidence. For Brownfield, leverage SAP’s “Migration Cockpit” and other tools to identify inconsistencies beforehand. Clean up your ECC system as much as possible before migration (archiving old data you don’t need to carry over, resolving any open ledger discrepancies, etc.). If you’re working on a greenfield project, invest in data cleansing – for example, purging or consolidating duplicate master data- so you load a clean dataset into S/4.
- Downtime and Cutover Planning: Plan the cutover meticulously. If you can afford a weekend or a few days of outage, schedule accordingly; if not, consider near-zero downtime techniques. Consider phasing cutover – e.g., do finance at the end of the period and production mid-period, etc. – though that adds complexity. Have a rollback plan: What if something goes wrong during the go-live process? Keep the ECC system on standby for a brownfield until S/4 is confirmed to be good, then decommission it. For Greenfield, you may run ECC in read-only mode for historical reporting until you migrate the history or users become comfortable with S/4 for accessing old data.
- Parallel Run or Safety Net: In some critical processes, such as financial reporting, some companies perform a parallel run for one cycle – for example, running one month’s close in both ECC and S/4 (or at least comparing the results) to ensure the outputs match. This builds confidence that the new system is working correctly. It’s extra effort, but it can catch discrepancies.
- Risk of Scope Creep: Be wary of overambition. It’s tempting to turn the S/4 migration into a giant transformation program that also includes implementing a dozen new things, such as SuccessFactors and Ariba. While alignment is good, overloading the program can increase risk. It may be wise to phase auxiliary projects, focusing on the S/4 core first and then tackling other projects once the core is stable and operational. The 2027 deadline provides a clear focus: S/4 first, then optional enhancements (unless they are quick wins that facilitate migration).
- Vendor and Contract Risks: If you opt for RISE, ensure you have considered the continuity implications. For example, what if the SAP service doesn’t meet expectations? Your contract should have escalation paths. If you have critical integrations with non-SAP systems, ensure the RISE environment supports them (including line connectivity, VPNs, and identity management) – these can pose risks if not properly planned.
- Testing and Validation: Insist on extensive testing, such as unit, integration, user acceptance, and performance testing. For performance, validate that your processes (especially custom reports or interfaces) perform well on S/4HANA. Many find that things speed up, but occasionally, a custom program may behave differently on HANA and require optimization. Also, test all integration points, especially if you have an ecosystem of satellite systems, such as CRM, SCM, and data warehouses. Nothing should be “hope for the best” on day one – have it tested.
- Post-Go-Live Support: Plan for hypercare, a period of increased support after go-live. Line up support team members (both IT and key business users) to be on call to resolve issues quickly. Communicate to users how to get support and expect some issues to arise, maybe minor data or user access problems. Having a war room to resolve these issues in the first weeks helps maintain business confidence. If you have global operations, ensure that you provide follow-the-sun support for the new system during the initial stages.
- Monitor and Adapt: As you execute the project, use risk registers and regularly review and update them. For example, if early test migrations reveal a problem, escalate and solve it immediately. Keep leadership informed of risks and mitigation plans – transparent communication helps avoid panic if an unexpected issue arises. It also helps to engage your SAP account team. If you encounter a critical bug or need help, having SAP’s development or support on standby (especially if you have MaxAttention or a similar plan) can expedite the solution. Many CIOs also connect with user groups, such as ASUG and DSAG, or peers to learn from their experiences and pitfalls in S/4 projects. This networking can reveal common issues to be aware of.
The ECC to S/4 migration should be treated as a major enterprise change program, not just an IT upgrade.
Further Reading
- SAP AI and Data Licensing Strategies
- Compare RISE with traditional SAP licensing
- Understand the FUE licensing model
- Negotiating RISE contracts
- 2027 ECC deadline and transition options
- Our Rise with SAP Advisory Case Studies.
- Rise with SAP Negotiation FAQs.
- SAP Rise
- Complete Licensing Guide for SAP ERP Private Cloud (RISE with SAP)
Read about our SAP Advisory services for Rise.
