RISE with SAP: Architecture Constraints That Enterprise Leaders Discover Too Late

Introduction

RISE with SAP architecture constraints are not prominently featured in the conversations that lead organizations to commit to RISE. They surface during implementation, when the gap between the architectural flexibility that enterprise ERP historically provided and the constraints that a managed cloud SAP environment imposes becomes operationally significant. Decision-makers who understood RISE as an accelerated path to S/4HANA in the cloud—with all the customization and integration capability that SAP has historically offered—frequently discover that the managed service model comes with boundaries that affect development practices, integration architecture, and data governance in ways that their business cases did not account for.

What RISE with SAP Actually Provides

RISE with SAP is a bundled offering that packages S/4HANA Cloud with infrastructure, Business Technology Platform (BTP) access, managed services, and tools for business process transformation. The value proposition is simplification: rather than procuring and managing each of these components separately, organizations receive them in a single commercial arrangement with a defined migration pathway and service level framework.

The architectural tradeoff that simplification introduces is reduced configurability at the infrastructure layer. In a RISE managed cloud environment, organizations do not have direct access to the underlying infrastructure and have limited ability to modify the operating environment beyond what SAP’s managed service framework permits. For organizations with on-premises SAP environments where direct infrastructure access was used for performance tuning, backup customization, or security configuration beyond SAP’s standard framework, this constraint is significant.

The Extensibility Boundary

SAP’s extensibility philosophy for RISE with SAP and S/4HANA Cloud directs custom development through the Business Technology Platform rather than through core application modification. In-app extensibility through the ABAP environment on BTP and side-by-side extensibility through BTP services replace the direct core modification approach that many organizations used in ECC and earlier S/4HANA on-premises implementations. This philosophy is architecturally sound—reducing core modification reduces upgrade complexity and maintains supportability—but it requires a different development approach than many SAP teams have historically used.

Organizations with large portfolios of custom ABAP code built directly in the core are not simply migrating that code to RISE; they are redesigning it to comply with SAP’s clean core extensibility framework. The scope of that redesign effort is frequently underestimated in RISE migration business cases, which assume that custom code can be migrated more directly than the extensibility framework actually permits. The gap between the assumed and actual custom code remediation effort is one of the most consistent sources of RISE migration timeline and budget overruns.

According to Gartner’s SAP S/4HANA migration research (https://www.gartner.com/en/information-technology/, custom code remediation consistently represents the largest source of scope underestimation in SAP S/4HANA migration programs, with organizations discovering on average that their actual custom code footprint is significantly larger than their pre-migration assessments indicated.

Integration Architecture in a Managed Cloud Environment

Integration architecture for RISE with SAP is substantially different from on-premises SAP integration architecture. On-premises SAP environments allowed organizations to implement direct database-level integration, custom RFC calls, and application server-level integrations that are not supported in the RISE managed cloud environment. Organizations that relied on these integration patterns—often for high-volume, low-latency integration with legacy systems—must redesign those integrations using SAP Integration Suite or BTP-based API management.

The integration redesign effort is compounded by the fact that many direct-access integrations were built by third parties or internal teams without documentation that accurately describes what they do and how they do it. Reverse-engineering undocumented integrations to understand their behavior before redesigning them for the RISE-compatible API model is time-consuming work that business cases do not typically budget for explicitly.

For context on SAP implementation partner selection and how it affects the ability to navigate these constraints, see Solix’s analysis of SAP implementation partner selection mistakes.

Data Architecture Implications of RISE

RISE with SAP has data architecture implications that extend beyond the S/4HANA system itself. SAP’s data product strategy for RISE environments encourages use of SAP Datasphere for analytics and SAP HANA Cloud for data management adjacent to the core ERP. Organizations that have invested in non-SAP data platforms—Databricks, Snowflake, or AWS-native data services—must decide how to integrate those platforms with the RISE data architecture, a decision that involves both commercial considerations (additional licensing costs for SAP data platform products) and technical ones (integration patterns for SAP data extraction at scale).

The data archiving and retention implications of RISE are also more constrained than on-premises SAP. Organizations with on-premises SAP have historically used SAP’s data archiving framework to manage data growth and compliance retention directly within the ERP environment. In RISE, data archiving strategies must work within the managed cloud framework, and organizations with large historical data volumes requiring long-term retention outside SAP’s native tools need to architect archiving solutions that are compatible with the RISE environment’s access patterns.

Making RISE Decisions With Accurate Information

Organizations that make RISE decisions with full awareness of the architecture constraints—and budget accordingly for custom code remediation, integration redesign, and extensibility framework adoption—are able to realize the genuine benefits that RISE provides: a managed path to S/4HANA with reduced infrastructure management overhead and a defined upgrade pathway. Organizations that proceed without this awareness encounter the constraints as surprises that consume budget and timeline that was allocated for other program priorities. The preparation investment required to make an informed RISE decision is substantially smaller than the cost of the rework required when constraints are discovered during implementation.