Defence prime negotiates RISE with SAP while preserving sovereign hosting requirements.

Why the proposal did not fit.

The defence prime operates across three regulatory regimes, two of which carry sovereign hosting requirements for classified programmes. The RISE with SAP proposal landed on the desk of the CIO with a single bundled architecture, all workloads on one public hyperscaler in one named region. The proposal carried a forty seven percent headline discount, a $28.5M total contract value, and a Digital Access entitlement scoped against a global document volume that included workloads the prime could not legally host on public infrastructure.

The opening conversation with the SAP account team was framed around the discount headline and the bundled value. The substantive question, whether RISE could accommodate sovereign and air gapped workloads at all, was deferred to a later phase. That sequencing was a problem. The prime needed to know the hosting answer before committing to a financial envelope, not after.

The engagement was scoped at eleven weeks, with a clear early objective. Confirm what RISE can and cannot host for this organisation, and rebuild the commercial proposal around the workloads RISE can legally accept.

Sequenced negotiation, hosting confirmed first.

The workload split.

The workload classification work produced a clear answer. Of the SAP estate, sixty four percent could move to RISE with SAP Cloud Private Edition on a sovereign hosting partner inside the qualifying jurisdiction. Twenty one percent could move to RISE on a standard hyperscaler. Fifteen percent could not move to RISE at any tier and would remain on dedicated infrastructure with SAP support, separate from the RISE commercial envelope.

The Digital Access scope inside the original proposal had been built against the full document volume, including the workloads that would never move to RISE. Rebasing the Digital Access commitment against only the RISE eligible scope reduced the entitlement by thirty one percent, with a true up mechanism rather than a flat commitment.

The proposal's BTP credit allocation was sized against a global integration roadmap. The roadmap was reviewed against funded business cases, and the credits were unbundled with a reduced commitment for year one through three and a usage trigger for years four through six.

The hosting question had to be answered before the commercial envelope was agreed. Reversing that sequence is the most common failure mode we see in defence and regulated industry RISE engagements.

What signature looked like.

The final RISE contract closed at $11.2M total contract value across six years. Sovereign hosting was preserved for the qualifying workloads, with the hosting provider named in the contract and price held against a transparent infrastructure pass through. The classified workloads outside RISE were addressed in a separate support agreement, not bundled into the RISE commercial envelope.

The commitment ramp was staged. Years one and two carried a reduced commitment while the workload migration was sequenced. Years three through six carried the steady state commitment. Exit windows were aligned with classification review cycles inside the prime's regulatory framework, giving the company the right to scale down the RISE commitment if a classified workload required relocation.

Transition assistance was committed for twelve months post termination. Data extraction was specified in a defined open format with sixty day extraction commitments. The Digital Access entitlement was rebased to RISE eligible scope with a true up mechanism. The six year price hold carried a three percent annual cap with a hard ceiling.