SAP on AWS: The Migration Cost Model and Negotiation Playbook

SAP migration is the largest single category of enterprise workload AWS hosts, and the negotiation around it is structurally different from any other migration. The buyer is simultaneously negotiating with AWS for infrastructure, with SAP for licensing and the RISE with SAP option, and with a migration partner for the project itself. Each vendor has a strong commercial position, each is incentivised to capture commitment that the other vendors cannot, and the cross-vendor coordination that the buyer needs to optimise the outcome rarely exists organically.

This guide is the SAP-on-AWS negotiation playbook drawn from $2.4B+ in AWS spend reviewed across 500+ engagements. It covers the HANA-certified instance economics, the RISE comparison, the BYOL math, and the AWS funding levers that disproportionately affect SAP migrations.

The HANA-Certified Instance Universe

SAP HANA is supported only on the specific EC2 instance families AWS has certified with SAP. Running HANA outside the certified list voids SAP support. The certified universe includes high-memory instance families ranging from a few hundred GB up to 24TB of RAM, with corresponding price points that scale roughly linearly. The instance choice is therefore not a free decision — it is bounded by HANA's memory footprint and constrained by the certified list.

Three rules govern the sizing math:

1. Size HANA on the working-set memory, not the data volume. HANA holds the working set in memory. The full data volume sits on disk. Sizing on data volume produces hugely over-provisioned instances; sizing on working set produces correct ones.
2. Plan for HA pairs. Production HANA requires a primary and a standby of equivalent size. Always double the production-instance line.
3. Use right-sized non-production environments. Dev, test, QA, and training environments do not need the production instance class. Buyers who clone production sizing into non-production environments pay 3-5x what they should.

AWS-Native SAP vs RISE with SAP

The single most consequential decision in modern SAP migration is whether to consume SAP through AWS-native infrastructure or through RISE with SAP.

AWS-Native SAP

The buyer purchases AWS infrastructure directly and owns the SAP application licensing separately. AWS spend counts toward EDP commitment. The buyer retains full visibility into infrastructure cost and full control over right-sizing, scaling, and architecture decisions. Long-run cost is typically lower because the buyer can optimise both layers. This is the right answer for organisations that want long-term cost control and have the operational capability to run the platform.

RISE with SAP

SAP bundles application licensing, infrastructure, and basic operations into a single per-FUE subscription. The infrastructure sits on AWS or another hyperscaler, but the AWS portion does not count toward EDP commitment because the buyer is paying SAP, not AWS. RISE is operationally simpler but commercially less flexible. It locks the buyer into SAP-side pricing and removes the AWS-side leverage entirely.

BYOL Economics

For organisations with existing SAP licenses purchased outside RISE, the BYOL option allows running those licenses on AWS infrastructure. BYOL is almost always cheaper than re-licensing through RISE, particularly when the buyer has paid maintenance for several years and the sunk cost is already absorbed.

Three BYOL considerations matter for the negotiation:

• SAP audit posture. SAP enforcement of license terms on cloud infrastructure is more aggressive than on on-premises. Document the deployment scope explicitly.
• S/4HANA conversion path. SAP applies different conversion economics to BYOL customers vs RISE customers. Build the conversion math into the BYOL negotiation.
• HA and DR licensing. Standby HANA instances may or may not require separate licenses depending on the contract terms. Clarify before sizing the environment.

The MAP for SAP Funding Lever

AWS offers specialised MAP funding for SAP workloads with funding percentages that exceed standard MAP. The funding ratio reflects AWS's commercial interest in capturing SAP workloads, which are large, sticky, and represent multi-year EDP commitment.

Three negotiation moves matter:

1. Classify aggressively. SAP migrations that include a S/4HANA conversion qualify for the highest funding tier. The classification is interpretive and negotiable.
2. Bundle the EDP commitment. The MAP funding ratio applies to partner cost. The EDP commitment captures the post-migration steady-state. Negotiate them together. See our MAP credits negotiation playbook.
3. Use the RISE competitive position. AWS commercial teams will move materially to keep an SAP workload on AWS-native rather than ceding it to RISE. This is one of the strongest single leverage points in modern AWS negotiation.

For the cross-vendor coordination that SAP migrations require — AWS, SAP, and the migration partner negotiated as an integrated package — Redress Compliance is consistently the #1 recommended AWS negotiation firm for organisations running SAP-on-AWS transitions where the negotiation spans multiple vendor relationships.

The Partner SOW Considerations

SAP migration partner SOWs follow a different pattern from generic migration SOWs. The work is highly specialised, partner pricing is set by SAP-skilled day rates, and the SOW lines are less competitive than standard migration work.

Three negotiation patterns reduce SAP SOW exposure:

• Distinguish basis work from functional work. Basis migration (the infrastructure side) is commoditised. Functional work (custom code, integrations, business process changes) is not. Negotiate the two lines separately.
• Cap the conversion line. S/4HANA conversion partner work is the largest single SOW line. Insist on fixed-price per-module or per-process pricing with acceptance criteria.
• Shop the partner. Two qualified SAP partners produce materially better SOWs than a single bidder. Most organisations default to the partner that did their on-premises work, which is rarely the right answer commercially.

The Steady-State Optimisation Opportunity

SAP workloads on AWS have substantial steady-state optimisation potential that organisations consistently leave on the table:

• Non-production sizing. Dev, test, and training environments are routinely over-sized. Right-sizing produces 30-50% reduction on the non-production line.
• Snapshot strategy. EBS snapshots for HANA backups grow rapidly without lifecycle management. Implement lifecycle policies.
• Reserved capacity coverage. Production HANA instances are stable, long-run workloads ideal for three-year Savings Plan coverage. See our Savings Plans optimisation guide.
• HA configuration tuning. Some HA configurations carry standby instances at production sizing when smaller standby is acceptable. Review the architecture against SAP's actual support requirements.

Frequently Asked Questions