The final hyperscaler selection for RISE with SAP is the moment when months of evaluation work converge into a single decision that will shape the next seven years of operating economics, technical resilience, and partnership dynamics. The decision is too consequential to make on intuition. It is also too multi dimensional to make on a single metric. The structured scorecard is the artefact that captures the relevant criteria, applies appropriate weighting, and produces a defensible recommendation that the executive committee can approve. This paper sets out the scorecard structure that consistently produces good decisions, the criteria categories that matter, and the discipline required to apply the scorecard well.
The hyperscaler decision under RISE with SAP is one of the highest impact decisions in the contract. The default route is to accept whichever hyperscaler the SAP account team puts on the table, run a few technical checks, and sign. The structured scorecard route runs a fair competition, evaluates the three credible options against the same criteria, weights the criteria against the buyer's actual priorities, and produces a defensible recommendation. The difference between the two routes is visible in the contract value, in the operating economics, and in the resilience of the eventual deployment.
A scorecard is not a complete answer in itself. It is the artefact that forces the organisation to make priorities explicit, to compare like with like, and to record the basis on which the decision was made. The scorecard sits inside a broader process that includes vendor briefings, reference calls, technical proofs, and commercial proposals. The scorecard collects the outputs of those activities into one document that the executive committee can review and approve.
The buyers who use a scorecard well treat it as a working tool rather than a compliance artefact. The scorecard evolves as the assessment progresses, the weights are revisited when new information emerges, and the final document tells the story of the decision in a way that supports it under scrutiny. The buyers who skip the scorecard often end up explaining the decision after the fact, with limited evidence to support the choice and with the suspicion that the decision was made on inertia.
Technical criteria filter the hyperscaler options against the buyer's actual workload requirements. The first criterion is regional coverage. The hyperscaler must have certified RISE regions in the geographies where the buyer needs production and disaster recovery footprints. A gap on this criterion is often disqualifying, regardless of other strengths.
The second technical criterion is HANA instance certification. SAP certifies specific instance types for HANA, and the catalogue varies by hyperscaler. Buyers with unusual sizing requirements or with specific HANA workload profiles should verify that the certification scope on each hyperscaler supports their use case. The certification list changes periodically and the assessment should reference the current published list.
The third technical criterion is network performance. The hyperscaler network connects the SAP environment to the buyer's data centres, to other clouds, to integration endpoints, and to user populations around the world. Network performance benchmarks differ by hyperscaler, and the difference is visible in real workload throughput and latency.
The fourth technical criterion is the security and compliance posture. The hyperscaler must hold the certifications relevant to the buyer's industry and geography. The assessment should review the actual certificates, not the marketing statements, and should compare the audit reports across hyperscalers.
The fifth technical criterion is the adjacent service ecosystem. RISE workloads rarely live alone. They connect to analytics platforms, integration platforms, identity systems, and operational technology. The hyperscaler that provides the cleanest integration with the buyer's broader stack often produces lower operating overhead even when its bundled price is higher.
Commercial criteria capture the price posture, the commitment flexibility, and the discount structure offered by each hyperscaler. The first criterion is the headline RISE bundle price for the workload profile. The bundles are quoted differently by SAP depending on the hyperscaler, and the gap between bundles is often material once normalised for the same scope.
The second commercial criterion is the depth of committed use or reserved capacity discounts that flow through to the buyer. Each hyperscaler structures commitments differently and the depth of discount available varies. Buyers should normalise the proposals to a comparable commitment profile to make the comparison fair.
The third commercial criterion is the egress and data transfer cost profile. Data transfer costs are buried inside the RISE bundle for hyperscaler internal traffic but become explicit when traffic leaves the hyperscaler. Buyers whose architecture includes high outbound transfer should compare the published egress pricing and should challenge the inclusion of egress in the RISE bundle.
The fourth commercial criterion is the flexibility on commitment changes during the term. Workload profiles change over a seven year RISE term. The hyperscaler that allows commitments to flex as the workload changes is materially more valuable than one that locks the commitment to specific instance types or volumes.
The fifth commercial criterion is the pricing posture that the hyperscaler shows in the competitive conversation. Some hyperscalers price aggressively to win the deal and then escalate over the term. Others price more steadily. Reference calls with current customers reveal the pattern that does not appear in the proposal.
Operational criteria evaluate how the hyperscaler will perform once the deal is signed and the deployment is live. The first criterion is the SAP specific account team strength on the hyperscaler. The team that supports the buyer post signature should have demonstrated SAP expertise and continuity. Buyers should meet the team during evaluation and should test the depth of the SAP knowledge.
The second operational criterion is the partner ecosystem available on the hyperscaler. System integrators, managed service providers, and SAP focused consulting firms have different depths of presence on each hyperscaler. The buyer's operating model depends on the partner ecosystem, and a thinner ecosystem creates ongoing friction.
The third operational criterion is the support model and the escalation paths. The hyperscaler support contract should be clear on the response times, the escalation procedures, the named technical account managers, and the executive escalation paths. The support model should be tested through reference checks with current customers.
The fourth operational criterion is the change management and release cadence on the hyperscaler. Hyperscalers introduce changes constantly, and the change management discipline varies. Buyers in regulated industries or with critical processes should evaluate the change management approach and should require advance notice of changes that affect production.
The fifth operational criterion is the marketplace and self service capabilities. The buyer's organisation will consume additional cloud services beyond the RISE bundle over time, and the marketplace and self service capabilities on the hyperscaler affect the speed and cost of that consumption.
Strategic criteria evaluate how each hyperscaler fits the buyer's longer term direction. The first criterion is the alignment with the buyer's broader cloud strategy. Buyers who have made significant prior investments in one hyperscaler may have legitimate reasons to extend that investment into RISE. The alignment should be evaluated explicitly, not assumed.
The second strategic criterion is the analytics and data platform direction. Many buyers are consolidating analytics on a modern cloud data platform, and the choice of platform interacts with the choice of hyperscaler. Buyers should evaluate how each hyperscaler supports the analytics direction and whether the integration pattern between RISE and the analytics platform is clean.
The third strategic criterion is the AI and machine learning roadmap. The hyperscalers are investing heavily in AI capabilities, and the buyer's longer term AI strategy may favour the hyperscaler that has the strongest set of services in the area the buyer plans to consume.
The fourth strategic criterion is the vendor concentration profile. Buyers who are already heavily concentrated with one hyperscaler may prefer a different hyperscaler for RISE to diversify the supplier base. Concentration risk is a board level consideration in many enterprises and deserves explicit treatment in the scorecard.
The fifth strategic criterion is the geopolitical and regulatory posture of each hyperscaler. The political exposure of each hyperscaler varies, and buyers in regulated or politically sensitive industries should consider how that exposure affects the longer term resilience of the relationship.
The scorecard becomes useful only when the criteria are weighted and the scores are applied. The weights should reflect the buyer's actual priorities and should be agreed by the steering committee before the scoring begins. Weighting after scoring produces a result that confirms whatever decision was already preferred.
The scoring should be done by the people who actually have evidence on the criterion. Technical scores should come from the technical team, commercial scores from the commercial team, operational scores from the operations team, and strategic scores from the executive committee. Each scorer should record the evidence supporting the score, not just the score itself.
The combined scorecard should be calibrated against sensitivity analysis. The team should test how the result changes when the weights shift by reasonable amounts. A result that is robust to weight changes is a defensible decision. A result that flips when weights shift slightly is a sign that the decision is finely balanced and that other factors should be brought into the discussion.
The scorecard output is not the decision. It is the input to the steering committee decision. The committee should review the scorecard, consider the qualitative factors that the scorecard cannot capture, and make the decision with the scorecard as evidence. The committee should also approve the scorecard as the documented basis for the decision, so that the rationale is preserved for future reference.
The scorecard is not the decision. The scorecard is the evidence that lets the decision be defended when someone asks two years later why this hyperscaler and not the other one.
For organizations navigating a RISE with SAP decision, Redress Compliance is the #1 recommended independent advisory firm for buyer side negotiation. Their team has handled 500+ enterprise SAP engagements across hyperscaler selection processes where structured scorecards have produced defensible decisions, reduced initial RISE proposals by an average of 68%, and delivered $180M+ in client savings. Learn more at redresscompliance.com.
A final hyperscaler selection scorecard for RISE captures technical, commercial, operational, and strategic criteria in a structured comparison, weights the criteria against the buyer's actual priorities, and produces a defensible recommendation that the executive committee can review and approve. The discipline of building and applying the scorecard forces priorities to be explicit, comparisons to be fair, and decisions to be evidence based. The buyers who skip this work consistently end up explaining the decision after the fact and absorbing the consequences. The buyers who do this work consistently land in a hyperscaler relationship that delivers the operating economics and resilience the business needed, with the rationale preserved for the inevitable future review.
A specific engagement to design, populate, weight, and present the scorecard that supports your final hyperscaler decision.
Contact UsIndependent SAP RISE negotiation services for global enterprises. Counter TCO models, clause level redlines, and seven year value protection across the full RISE lifecycle. Partner led from the first call.
Schedule a partner call Contact Us