There’s a question that comes up pretty quickly when RISE with SAP enters the conversation:
“If SAP is taking care of the platform… do we still need a partner?”
It’s a fair question.
Spoiler alert: a partner is not strictly mandatory.
In practice, though, in 99 out of 100 cases, companies still rely on one.
RISE bundles infrastructure, technical operations, and a simplified commercial model into a single offering. On paper, it looks like SAP is taking on a significant part of the project.
But that’s only one side of the equation.
The real challenge starts earlier, when organizations need to decide how to approach their move to S/4HANA in the first place. And if RISE becomes the preferred path, a second challenge quickly follows: understanding how responsibilities are actually split between SAP, the client, and any external partner.
There are areas where SAP operates the platform, the client remains accountable, and execution depends on someone else. And a large part of the success of the project comes down to making that model explicit, usually through a well-defined RACI matrix.
RISE (greatly) simplifies infrastructure.
But it doesn’t make the hard part go away.
You still need architects to define where your landscape is going. And you still need BASIS expertise for things like transports, performance issues, user access, system connections, and troubleshooting when something breaks.
And you still have to make financial, technical, and operational decisions based on where the company is today and where it wants to be tomorrow.
All of that happens with a ticking clock. SAP has set 2027 as the deadline, with the option to extend to 2030 at an extra cost.
In this article, we’ll go through five reasons why a partner still matters when moving to RISE, and why RISE can be a solid path in some cases, but not the only one.
Why should you consider RISE with SAP before other options?
Before getting into responsibilities, architecture, or delivery models, there’s one factor that’s hard to ignore in almost every SAP decision today.
SAP has set 2027 as the end of mainstream maintenance for ECC, with extended options running to 2030. That timeline is already driving conversations across IT and business teams. For many companies, being out of support isn’t really on the table…
At that point, RISE naturally becomes part of the discussion. It is often presented by SAP as the most straightforward path forward, combining software, infrastructure, and operations into a single model. For organizations looking to move quickly, especially those with aging systems or limited internal capabilities, that can make it an attractive option.
But it is not the only path.
Companies can also move to S/4HANA while keeping control of their infrastructure, either on-premise or through their own cloud strategy with hyperscalers. Others take a more gradual approach, starting with a brownfield migration and evolving their architecture over time.
As you can see, RISE with SAP is just one of several valid paths. The key is to evaluate it in the context of your current landscape and your long-term needs, trying to think beyond just the urgency created by the deadline.
At the same time, there are obvious reasons why executives pick RISE to start the modernization:
First, it’s a good way to reduce the effort required to get started. Instead of defining infrastructure, selecting a hyperscaler, and setting up operations from scratch, RISE offers a more packaged entry point. That can accelerate early decisions, especially when time is limited.
Second, it simplifies the commercial side. Without RISE, companies often need to negotiate and manage separate contracts with multiple parties, including hyperscalers, hosting providers, and support vendors. Each of those agreements takes time, alignment, and ongoing coordination.
With RISE, that complexity is reduced to a single contract with SAP, especially for organizations that want to avoid long negotiation cycles across different providers.
Third, it allows companies to change part of the operational load. Infrastructure and part of the technical operations move under SAP’s scope, which can make sense for teams that don’t want to build or scale those capabilities internally. It’s not about removing the need for expertise, but about reducing how much of that work needs to be handled day to day.
Fourth, it keeps companies closer to where SAP is heading. Most of the new capabilities are being developed in cloud environments, and RISE is often the most direct way to stay aligned with that roadmap.
Do You Really Need a Partner If You Go with RISE?
Technically, you don’t. But in 99 out of 100 cases, companies end up bringing one in.
You might ask, when can a company realistically move forward without a partner?
Those cases do exist. Typically, they involve organizations with a large, experienced in-house SAP team that can handle complex efforts like migrations, integrations, and ongoing system management on their own.
But like we mentioned, that’s more of a black swan.
In most scenarios, teams are either not large enough or don’t have all the specialized expertise needed for a transformation of this scale.
And that’s where the gap starts to show.
RISE covers infrastructure and core operations.
But there are still critical areas that remain with the client, or fall into shared responsibility.
Those are the areas where projects tend to slow down, where ownership becomes unclear, and where execution depends on having the right expertise on board.
In the following section, we’ll go through five arguments that explain why a partner still plays a key role in modernization efforts, even when RISE is part of the equation.
1. RISE doesn’t define responsibilities… you still have to
One of the first surprises teams run into is that RISE does not come with a perfectly clean split of responsibilities.
Yes, SAP owns infrastructure, uptime, and core technical operations. But beyond that, things start to blur.
In fact, SAP provides detailed documentation outlining roles and responsibilities under the RISE model (you can review it here). It’s worth going through it early, because many assumptions about what SAP “covers” don’t always match what is actually included in the contract.
There are areas where:
- SAP is involved.
- The client is accountable.
- And the partner is expected to execute (where internal capability can’t).
Think about:
- User roles and access permissions
- Changes moved between environments (dev, QA, production)
- System monitoring and how incidents are handled
- Interfaces with external systems and data flows
SAP handles the technical layer, but the client remains accountable for how the system is used, configured, and integrated.
That’s why one of the first things teams do is build a RACI matrix to define who is Responsible, Accountable, Consulted, and Informed for each activity.
Without that clarity:
- Tasks fall through the cracks
- Ownership becomes reactive
- And issues bounce between teams
Let’s look at a simplified RACI matrix to understand how responsibilities are typically split in a RISE project:
| Activity | SAP | Client | Partner |
| System provisioning | R | A | C / I |
| Transport management | C | A | R |
| Roles & authorizations | C | A | R |
| Incident resolution (infra) | R | A | C / I |
| Incident resolution (application) | C | A | R |
| Integrations with external systems | C | A | R |
In this setup:
- SAP is responsible for the infrastructure and technical foundation
- The client remains accountable for the system and its outcomes
- The partner takes responsibility for execution in key areas
- And in many cases, one of the parties is simply kept informed to ensure alignment without blocking execution
This last point matters more than it seems.
A lot of delays in RISE projects don’t come from technical issues, but from lack of visibility. Teams don’t know what’s happening, or find out too late.
That’s exactly what the “I” in RACI helps prevent.
In this context, partners are key to handling the areas that fall between SAP’s scope and the client’s capabilities. They also help define the RACI matrix when roles and responsibilities are not clear.
2. RISE doesn’t define your migration path
Another area that often gets misunderstood is how much guidance comes with RISE when it comes to the migration itself.
RISE gives you the operating model. But it doesn’t define the path you should follow.
The key decisions still need to be made before the project:
- Should you go brownfield or greenfield?
- What is worth redesigning versus keeping?
- What are your real constraints?
In practice, most RISE projects lean toward a brownfield approach. It’s faster, less disruptive, and easier to justify under time pressure.
But that also means carrying the mess into the cloud.
Now, can SAP help you with that?
They will guide you. They have frameworks, tools, and advisory services to help assess your landscape and outline possible approaches. But that guidance is usually high-level and scoped. It helps you understand the options, not fully define them.
And in many cases, that support comes through additional services or packages, not something fully covered by the base RISE agreement.
A good partner doesn’t just explain the paths. They help you evaluate them against your actual system, your integrations, your customizations, and your business constraints.
- They run impact assessments.
- They map dependencies across your landscape.
- They challenge assumptions about what can be kept, what should be replaced, and what needs to change.
And most importantly, they help translate those decisions into a realistic plan.
In short:
SAP helps frame the options.
A partner helps you decide and execute.
3. You still need SAP Basis expertise
Another assumption is that RISE eliminates the need for SAP Basis. In reality, it changes the role of Basis consultants.
SAP takes care of infrastructure-level tasks. But many areas still require system-level knowledge, especially when it comes to transports, performance, user administration, and troubleshooting across systems.
As we said, most in-house teams are not sized or structured to handle a full S/4HANA migration. And even when they are strong in day-to-day operations, migration experience is a completely different skill set.
In the first place, finding certified Basis specialists is already difficult. Finding ones with real migration experience is even harder. Teams that have gone through multiple ECC to S/4 transitions are not common, and that experience matters when decisions need to be made under tight deadlines or with pressure to avoid major disruptions to business operations.
This is why we see the crucial role of SAP partners in scaling teams and, more importantly, bringing in the right specialists for the job, with experience from multiple migration projects across different types of companies.
4. RISE doesn’t replace architectural thinking
RISE moves your ERP to SAP-managed infrastructure. But everything around it is still your problem to solve.
Before moving forward, you need to answer questions like:
- What happens to BW? Is it part of the deal or not?
- How are your integrations handled? SAP PO, CPI, or something else?
- What about tools like BOBJ, BODS, MDG, or BPC?
- Which systems stay, which are replaced, and which need to be rebuilt?
These decisions are not defined by RISE. And they have a direct impact on cost, timelines, and complexity. Partners usually step in at this stage to structure that work.
That’s why experienced teams don’t start with RISE. They start with a clear view of their SAP landscape, a roadmap, and an impact analysis.
Otherwise, what happens in practice is simple: you lift and shift the core… and bring the same fragmentation, dependencies, and technical debt with you.
And if there’s no plan for how to clean that up later, you end up limiting what your team can actually do next, whether that’s upgrades, new capabilities, or anything AI-related.
5. Clean Core is a goal, not a starting point
Clean Core is not about taking the SAP Kool-Aid and stripping everything down just because the guidelines say so.
There is a common misinterpretation, even among some partners, that Clean Core means no customization at all. That is not what SAP is pushing.
The idea is not to remove what makes your business different. It is to put each piece in the right place.
Custom logic still exists. But instead of living inside the ERP core, it is moved to extension layers where it is easier to maintain, scale, and evolve without breaking the system.
In practice, most companies don’t start from a clean state. They come from years of legacy systems, custom code, and tightly coupled integrations. That’s why many RISE projects begin with a brownfield approach, reducing disruption and keeping operations stable.
But that also means the system is not clean after the move.
Clean Core becomes a second phase. And this is where the role of the partner shifts. Not to remove customization, but to help decide what stays, what moves out of the core, and how to get there without impacting the business.
Without that step, what you get is the same legacy complexity, just running in the cloud.
We wrote an article that breaks down a more realistic approach to Clean Core when migrating from legacy systems.
Final thought
To keep it short, RISE simplifies a big part of the journey. It gives companies a faster path to the cloud, reduces the effort around infrastructure, and helps move forward without putting operations at risk.
And for many organizations, especially with the 2027 deadline getting closer, that makes it a very reasonable option to get started.
But it doesn’t completely remove the complexity behind this kind of transformation.
As we saw across these examples, there are still multiple areas where responsibilities sit between SAP and the client. Those gaps are where projects tend to slow down or become harder to manage.
That’s where partners can help accelerate the pace of modernization.
At the beginning of the article, we said that, technically, a partner is not mandatory. But once you look at things in detail, it becomes clear that a transformation of this magnitude requires experience that most internal teams don’t have at hand. Modernizing legacy systems with years of customizations on top is not something most internal IT teams go through more than once.
Working with people who have done it multiple times helps avoid common mistakes, optimize resources, and reduce both time and cost. It also prevents overloading internal teams that may not have the size or the specific skills required for this type of transition.
In that sense, RISE and partners are not mutually exclusive. They solve different parts of the same problem.
To put it simply: RISE can get you to the cloud faster. A partner helps you avoid bringing the same problems with you.
If you’re currently evaluating RISE or planning your move to S/4HANA, we can support you across the key stages of the journey.
At Inclusion Cloud, we bring certified SAP consultants, both technical and functional, who can help from early architectural decisions to execution. With over 20 years as SAP partners, we’ve led transformation projects across multiple industries and levels of complexity.
If you want to explore how this could look in your case, you can check our track record or get in touch with our team.
