RISE for technology. Coexistence with existing cloud spend.

Technology sector buyers approach RISE with SAP from a different starting point than most other industries. The technology buyer typically operates a mature hyperscaler footprint, with an enterprise agreement that has been in place for three to seven years, a committed annual spend that runs from tens of millions to hundreds of millions of dollars, and operational engineering capability that uses the hyperscaler primitives directly. The arrival of a RISE proposal into that environment is not a greenfield decision. The RISE deal must coexist with the existing cloud spend, and the coexistence question is at least as important as the commercial question on the SAP unit pricing. This article describes the coexistence patterns, the negotiation levers, and the structural choices that produce a workable RISE deal for technology buyers.

The starting hyperscaler footprint.

Technology buyers typically carry a hyperscaler enterprise agreement that covers the engineering platform, the data infrastructure, the customer facing services, and the corporate productivity tooling. The committed annual spend on the enterprise agreement is the dominant cloud expenditure, and the enterprise agreement pricing is materially below the public list pricing. The buyer engineering organisation has built tooling, processes, and skills around the hyperscaler environment. Migrating workloads away from the existing hyperscaler is operationally expensive even when commercially attractive.

The SAP RISE proposal arrives into this environment with a default bundled structure. The bundled structure prices the infrastructure component at SAP list pricing rather than at the buyer enterprise agreement rate. The pricing differential between the bundled rate and the enterprise agreement rate is typically thirty to fifty percent. For a technology buyer with a meaningful hyperscaler relationship, accepting the bundled structure means paying SAP a margin on infrastructure the buyer could procure more cheaply through the existing relationship. The pricing differential alone is the largest single negotiation issue for technology sector RISE deals.

The bring your own license structure.

The first coexistence pattern is the bring your own license structure, where the buyer continues to procure hyperscaler capacity through the existing enterprise agreement and SAP provides the managed services layer separately. The structure preserves the buyer enterprise agreement pricing, preserves the buyer operational tooling, and limits the SAP relationship to the application and managed service domain. The bring your own license structure produces meaningful cost reduction relative to the bundled structure, often in the range of fifteen to twenty five percent on the infrastructure component alone.

The structure is achievable in approximately fifty percent of technology sector RISE engagements where the buyer requests it. The negotiation requires the buyer to demonstrate the enterprise agreement coverage, to commit to maintaining the agreement through the RISE term, and to define the operational interfaces between the SAP managed service and the buyer managed infrastructure. SAP account teams resist the structure because it removes the infrastructure margin from the deal, but the resistance softens when the buyer is large, the enterprise agreement is well established, and the alternative is the buyer walking from the deal.

The multi cloud coexistence.

Some technology buyers operate across multiple hyperscalers, with different workloads on AWS, Azure, and GCP based on the suitability of each platform. The multi cloud environment complicates the RISE deployment, because the SAP managed service typically supports a single hyperscaler per deployment, and the choice of hyperscaler is constrained by SAP partner agreements and operational readiness. The buyer who has standardised on one hyperscaler for SAP workloads has a simpler RISE conversation. The buyer who has split SAP workloads across hyperscalers needs to make a consolidation decision before or during the RISE negotiation.

The consolidation decision has commercial and operational implications. Commercially, consolidating SAP workloads onto a single hyperscaler may unlock additional volume discounts on the existing enterprise agreement, particularly if the SAP workload is meaningful relative to the existing committed spend. Operationally, consolidation produces a simpler integration architecture, a more focused engineering effort, and a clearer service ownership model. The buyer team should evaluate the consolidation in parallel with the RISE negotiation rather than treating them as separate decisions.

The reserved capacity question.

Technology buyers typically optimise their hyperscaler spend through reserved capacity, savings plans, and committed use discounts. The reserved capacity instruments produce meaningful cost reduction at the cost of operational flexibility, and technology engineering teams are sophisticated in their management. The RISE deployment introduces a new workload into the reserved capacity calculation, and the question is whether the new workload should be covered under the buyer reserved instruments or treated as a separate procurement.

The bundled RISE structure treats the new workload as a separate procurement, with SAP capturing the reserved capacity benefit rather than the buyer. The unbundled structure brings the new workload under the buyer reserved instruments, capturing the benefit for the buyer. The difference in lifetime cost is meaningful, particularly for buyers with mature reserved capacity programmes. The technology buyer who has a defined reserved capacity strategy should treat the unbundling as a structural priority, not a commercial preference.

The data residency and locality requirements.

Technology sector data residency requirements are often more demanding than general enterprise requirements. Engineering teams may need to operate workloads in specific regions for latency reasons, customer data may be subject to specific jurisdictional protection, and the SAP environment may need to be deployed in regions that align with the existing hyperscaler footprint. The RISE proposal may default to SAP recommended regions that do not match the buyer requirement, and the alignment work is part of the negotiation.

The buyer should map the existing hyperscaler region footprint, the data residency requirements that apply to the SAP workload, and the SAP supported regions for each RISE deployment scenario. The map produces the deployment region recommendation, which becomes part of the contractual specification. The discipline matters because changing the deployment region after signature is operationally expensive and frequently produces commercial renegotiation. The decision belongs at signature time.

The technology RISE deal is not a greenfield decision. The RISE deployment must coexist with the existing cloud footprint, and the coexistence question is at least as consequential as the commercial question.

The operational integration.

The final coexistence question is the operational integration. The buyer engineering organisation already operates the existing cloud footprint with defined tools, defined processes, and defined skills. The SAP managed service operates with a different toolset, different processes, and different escalation paths. The integration between the two operating models needs to be defined explicitly in the contract and in the operating procedure.

The integration covers several dimensions. Monitoring data flowing from the SAP environment into the buyer observability platform, with defined metrics and defined data formats. Incident escalation between the SAP service desk and the buyer engineering team, with defined severity levels and defined response times. Change management coordination between SAP managed change windows and the buyer change management cadence. Network and security integration between the SAP environment and the buyer hyperscaler environment, with defined connectivity, defined identity federation, and defined data protection controls. Each integration dimension produces specific contractual language and operational documentation. The technology buyer who treats the integration as a contract level issue captures clearer operating economics than the buyer who treats it as a post signature project.

Conclusion.

The RISE deal for a technology sector buyer is a coexistence decision more than a procurement decision. The existing hyperscaler footprint, the mature engineering practice, the established reserved capacity programme, and the multi cloud reality each create commercial and operational constraints on the RISE structure. The bundled default does not fit. The bring your own license structure, the multi cloud consolidation, the reserved capacity capture, the data residency alignment, and the operational integration are each negotiable, and each produces material value for the buyer who pursues them. The technology buyer who treats the RISE proposal as a coexistence problem captures the value. The technology buyer who accepts the bundled default cedes the value back to SAP and accepts an operating model that competes with the existing cloud relationship rather than complementing it. The work belongs to the buyer team at signature, not after.