RISE with SAP Methodology: What It Is Today (Part 1/3)

RISE with SAP no longer describes a single product you buy. It describes a path, a set of governance tools, and a support structure that SAP and its partners use to move existing customers into the cloud. This is the first of three articles on the topic: this piece covers what RISE with SAP is today, how it evolved, and how it connects to clean core at a strategic level. The second piece goes deeper into one of clean core’s five principles, extensibility — the four extensibility levels, what counts as a “clean” extension versus a BAdI or user exit, and the practical mechanics of staying upgrade-stable. The third covers the other four principles: business processes, data, integration, and operations.

Analysis | ~16 min read | By J. Torre

In brief

RISE with SAP originally referred to a specific commercial bundle centered on SAP Cloud ERP Private Edition. SAP has since repositioned it as the methodology and commercial framework for the entire journey toward SAP Business Suite in the cloud, not just a hosting decision for one product.
The RISE with SAP Methodology rests on three components: a standardized framework built on SAP Activate, an integrated tool chain (SAP Signavio, SAP LeanIX, SAP Cloud ALM, among others), and expert guidance from SAP and certified partners.
Customers reach SAP Business Suite through one of three pathways: a greenfield deployment of SAP S/4HANA Cloud Public Edition, a brownfield system conversion to SAP Cloud ERP Private, or a two-tier hybrid combining both.
Clean core is not a side recommendation inside this methodology — it is the architectural discipline the whole framework is built to enforce, through governance bodies like the Solution Standardization Board and recurring quality gates.
Independent surveys from DSAG and ASUG show a more mixed picture on the ground than SAP’s own materials suggest: licensing costs, data protection, and integration remain the top-cited obstacles, and a meaningful share of DSAG members report seeing little added value so far.

What RISE with SAP actually is today

SAP created RISE with SAP in 2021 as a way to sell an S/4HANA Cloud Private Edition transformation as a single subscription: the software, the hyperscaler infrastructure, migration tools, and a defined set of services, bundled under one contract. For several years, that is essentially what the term meant in practice — a specific commercial package built around one product edition.

That is no longer an accurate description. As SAP’s own RISE with SAP Methodology materials put it, “traditionally, RISE with SAP was a specific sales package, including SAP Cloud ERP Private,” but the company has since evolved the model “to provide focused, continuous support” across a wider portfolio — public and private cloud ERP, and line-of-business solutions delivered under the SAP Business Suite umbrella. The RISE with SAP name increasingly refers to the transformation methodology and commercial framework that gets an existing customer from a legacy, on-premises SAP landscape to SAP Business Suite in the cloud, whichever specific products that journey ends up including.

This distinction matters for how a CIO should read a RISE with SAP proposal in 2026. It is not a fixed shopping list. It is a project methodology, a governance model, and a toolchain, wrapped around whichever mix of SAP Cloud ERP Private, SAP S/4HANA Cloud Public Edition, and line-of-business products (SAP Ariba, SAP Concur, SAP SuccessFactors) actually fits the customer’s landscape.

The three components of the RISE with SAP Methodology

SAP describes the RISE with SAP Methodology as combining three elements.

The first is a standardized framework. It extends SAP Activate — SAP’s established implementation methodology — with clean-core-specific activities and quality checkpoints layered on top of the usual phases: Discover, Prepare, Explore, Realize, Deploy, and Run. The framework provides project roadmaps, milestones, and a defined set of tasks and accelerators rather than leaving each implementation partner to improvise governance from scratch.

The second is an integrated tool chain. Three tools do most of the work: SAP Signavio for process analysis (process mining, process documentation, and process governance in BPMN notation), SAP LeanIX for enterprise architecture and application portfolio management, and SAP Cloud ALM, which functions as the connective layer — it hosts the project’s task list, tracks quality gates, and later becomes the dashboard used to monitor clean core adherence during operations. SAP has stated that SAP Cloud ALM tracks more than 150 recommended clean core tasks mapped across the SAP Activate phases as part of the Clean Core Success Plan set up during onboarding.

The third is expert guidance: onboarding advisors, enterprise architects, and qualified partners who work alongside the customer’s own team, rather than a purely self-service toolset.

Three pathways into SAP Business Suite

Because customers arrive with very different starting points, the methodology defines three primary transformation pathways rather than a single prescribed route.

A greenfield, or net-new, adoption means deploying SAP S/4HANA Cloud Public Edition from a clean starting point, adopting SAP’s standard processes and industry best practices without carrying forward legacy customization. This path suits organizations that want the fastest deployment and the least inherited technical debt, at the cost of giving up bespoke processes that may have taken years to build.

A system conversion, sometimes called a brownfield migration, converts an existing SAP ECC system into SAP Cloud ERP Private Edition. This preserves historical data, existing integrations, and business logic that the organization has already invested in, while still requiring a clean core assessment of what gets carried forward versus rebuilt using released APIs.

A two-tier, or hybrid, strategy combines both: a multinational might run SAP Cloud ERP Private at headquarters to retain complex, industry-specific functionality, while subsidiaries or newly acquired divisions run SAP S/4HANA Cloud Public Edition on standard processes. SAP Business Technology Platform then acts as the integration layer connecting both tiers.

None of these pathways is intrinsically “more RISE with SAP” than another — the methodology, the tool chain, and the governance model apply across all three.

Discover and Prepare: what actually happens before a project starts

Two structured engagements sit at the front of a RISE with SAP journey, and they matter because they are where clean core commitments get made — or don’t.

During the Discover phase, sales and pre-sales teams use the Digital Discovery Assessment (DDA), a structured questionnaire and workshop format that captures the customer’s IT architecture requirements, planned scope, and licensing needs. Complementing it, SAP Signavio Process Insights gives early, out-of-the-box visibility into how the customer’s business processes actually run today, and SAP LeanIX inventories the existing application landscape. SAP Readiness Check adds a technical assessment of the current system’s readiness for conversion. Together, these produce the artifacts — including an initial clean core baseline and a business capability map — that get handed off from the sales team to the implementation team as the project moves into Prepare.

The Transformation Preparation Service (TPS), aimed specifically at SAP Cloud ERP Private customers, picks up where the DDA leaves off. It is a short, intensive engagement — typically an alignment session followed by a three-day workshop with SAP specialists — structured around three themes: reviewing the target IT architecture and establishing a clean core baseline on day one, identifying Business AI and Joule use cases on day two, and formalizing the governance model, including the creation of a Solution Standardization Board, on day three. The workshop closes with governance playbooks, a tool-chain activation plan (connecting Signavio, LeanIX, and Cloud ALM), and a detailed transition roadmap.

The purpose of TPS is explicit in SAP’s own description: to close the gap between what pre-sales promised and what the implementation project actually delivers, by translating strategic intent into a concrete architecture and governance model before the technical work begins.

Governance: the Solution Standardization Board

The Solution Standardization Board (SSB), formalized during TPS, functions as an architecture review committee for the life of the project and, typically, beyond it. Its job is to evaluate every proposed deviation from SAP standard before it gets built.

In practice, the SSB does four things. It performs gap management: before approving any custom development, it checks whether the requirement can already be met by standard SAP functionality or configuration. It requires strategic justification: a deviation only gets approved if it addresses a genuine regulatory requirement or a capability that meaningfully differentiates the business — not general preference for how a process used to work. It reviews Key Design Decisions to keep the target architecture aligned with clean core principles as the project evolves. And it governs how any approved extension gets built — specifically checking that it sits outside the ERP core, typically side-by-side on SAP Business Technology Platform, and consumes only released APIs rather than modifying source code directly.

This is the governance mechanism that gives clean core teeth. Without a body empowered to say no to a customization request — and to make that decision before code gets written rather than during a failed upgrade two years later — clean core remains an aspiration rather than a constraint that actually holds.

Why clean core sits at the center, not on the side

It would be easy to read clean core as one item on a checklist alongside migration, licensing, and training. SAP’s own materials treat it differently: as the architectural foundation the rest of the methodology is built to protect.

Clean core rests on five guiding principles, each with its own goal. Business processes should stay close to SAP standard, adopting a “fit-to-standard” mindset that starts from the question of how the organization can adapt to industry-proven best practices, rather than how to force the system to replicate historical processes — reserving custom deviation for cases with real, measurable business value. Extensibility should decouple custom code from the standard system, built either side-by-side on SAP Business Technology Platform or on-stack through ABAP Cloud, using only released APIs. Data should be governed to current standards across data strategy, governance, quality, and volume management, since reliable automation and AI features cannot run on inconsistent data. Integration should rely on released APIs and event-driven patterns rather than fragile point-to-point custom connections built inside the ERP. And operations should move from reactive, manual troubleshooting toward standardized, automated system management.

The methodology treats these five principles as interdependent rather than a checklist to complete independently: a business process that deviates from standard tends to require custom extensions to support it, which in turn creates data and integration dependencies that complicate operations. Clean core governance exists to catch that chain reaction before it starts, not to clean it up after the fact.

What clean core is meant to deliver, by stakeholder

SAP frames the payoff differently depending on who is asking, and the framing is useful because it explains why three different functions inside a customer organization would all sign off on the same transformation.

For IT, a clean core simplifies system updates because there is less custom code to retest with every SAP release, reduces the maintenance burden of unused or duplicated functionality, and lowers operational and cybersecurity risk by minimizing the number of undocumented modifications an attacker — or an auditor — might find. For end users, it means working from a single, consistent version of business data instead of reconciling numbers across disconnected systems, and it removes the departmental silos that build up when every team maintains its own workaround. For the organization as a whole, it translates into greater agility — the ability to adopt a new SAP capability, including generative AI features built on Joule, without a multi-month compatibility project first — and, over time, a lower total cost of ownership as fewer resources go toward keeping legacy customizations alive through each upgrade cycle.

None of these benefits is automatic. They depend on the governance actually being enforced — which is precisely the gap the next section covers.

Where agentic AI fits into the toolchain

The most recent evolution of the RISE with SAP Methodology, introduced alongside SAP’s 2026 Autonomous Enterprise messaging, adds what SAP calls an agent-led toolchain to the standardized framework and expert guidance described above. In practice, this means migration and modernization assistants — built on the same SAP Business AI Platform that underpins Joule — are woven into the transformation itself, rather than being a separate workstream bolted on afterward.

The stated goal is to fold migration and modernization activities into a single, more automated approach: assistants that help accelerate the technical migration work, so that the reduction in complexity and cost translates into faster, more measurable progress toward a clean core rather than a slower, purely manual project. This matters for how the methodology connects to the rest of SAP’s current roadmap, because SAP has been explicit that a clean, governed core is a prerequisite for reliable agentic AI — an agent can only act safely on business data and processes it can trust, which is exactly what the five clean core principles are meant to guarantee. In that sense, RISE with SAP’s agent-led toolchain is less a new feature than a demonstration of why the methodology insisted on clean core in the first place: the transformation approach and the destination reinforce each other.

This is also where the practical stakes of the methodology rise. A migration assistant recommending how to remediate a piece of custom code is only trustworthy if the underlying classification of that code — released API, classic API, internal object, or explicitly discouraged pattern — is accurate and current. That classification is exactly what the clean core level concept exists to provide, and it is the subject of the second part of this series.

What the SAP ecosystem is actually saying

SAP’s own materials describe a fairly linear path from bundle to methodology to clean core discipline to measurable business value. Independent sources paint a more uneven picture, and a precision-first read of RISE with SAP should include both.

Surveys run by the German-speaking SAP user group DSAG and the North American ASUG group show a real gap in perceived value: only around 12% of DSAG members and 24% of ASUG members currently rate SAP’s transformation offering as high or very high value, while roughly 39% of DSAG members and 11% of ASUG members report seeing little to no added value from it at this point. Across both groups, the most commonly cited obstacle is not technical — it is licensing and cost models (cited by 72% of DSAG members and 41% of ASUG members), followed by data protection and information security concerns, and then integration complexity. Hybrid landscapes, not full public cloud adoption, remain the norm for most respondents.

On the extensibility side specifically, SAP Community discussion has been more openly critical than SAP’s own white papers. One widely discussed post argues that the blanket “keep the core clean” framing understates a real, practical problem: developers accustomed to reaching for a user exit, a classic BAdI, or an implicit enhancement whenever they need to embed custom logic have, over two decades, created a web of dependencies on SAP-delivered code that a purely upgrade-oriented framing doesn’t fully capture — because moving away from those patterns requires rebuilding institutional knowledge, not just swapping one API for another. That tension between what a governance framework recommends and what an experienced ABAP team has spent years building is a recurring theme in ecosystem commentary, and it is one reason SAP introduced the more graduated four-level clean core model (covered in the second part of this piece) instead of a strict binary between “clean” and “not clean.”

Read together, none of this contradicts SAP’s description of what the methodology and clean core are designed to do. It does suggest that the gap between the documented framework and its consistent application in a live, multi-year transformation project is where most of the real difficulty sits — a theme that shows up again, in much more technical form, once we get into how clean core extensibility actually works in practice.

What’s next

This piece covered RISE with SAP as a methodology: what changed since 2021, the three components that make it up, the pathways into SAP Business Suite, and how governance is meant to enforce clean core discipline from the first workshop onward. The second part of this series goes under the hood of one of clean core’s five principles, extensibility — the four-level model (from fully released APIs down to explicitly discouraged techniques), what actually separates a released API from a BAdI or a user exit in practice, the on-stack versus side-by-side decision for a given extension, and the KPIs SAP recommends for measuring whether that piece of a clean core strategy is actually working rather than just documented. The third part covers the remaining four principles — business processes, data, integration, and operations — and the measurement framework SAP uses to score all five together.