Bring-your-own-licence and bring-your-own-database constructs let the buyer redeploy existing licence value onto cloud infrastructure without re-buying. The constructs apply differently across the SAP catalogue, hyperscaler hosts, RISE shapes and BTP services. The buyer reads the construct against the contract.
BYOL (bring-your-own-licence) is the construct under which the buyer redeploys an existing perpetual or subscription licence onto cloud infrastructure (typically a hyperscaler-hosted environment) without the publisher re-issuing or re-pricing the licence. The construct presupposes an existing entitlement, a redeployment authorisation in the contract, and a hyperscaler relationship that accepts the BYOL model.
The buyer-side question is whether the existing entitlement actually permits redeployment. SAP's contractual posture on BYOL varies by product line and by contract vintage. Older perpetual contracts often have permissive redeployment language; newer subscription contracts often have more restrictive language tied to specific hosting models.
The detailed reading on the hyperscaler choice for SAP workloads sits in SAP hyperscaler choice, and the parallel RISE composition reading in Anatomy of the RISE bundle.
BYOD (bring-your-own-database) is the parallel construct on the database side. Where the buyer holds an existing Oracle Database or Microsoft SQL Server licence and runs SAP on top of that database, the buyer can typically redeploy the database licence onto cloud infrastructure under the database vendor's BYOL construct rather than buying a new cloud-native database.
The SAP-side question is whether the SAP application licence is compatible with the BYOD posture. RISE with SAP runs on HANA Cloud by default and BYOD is not the relevant construct inside RISE. On-premise S/4HANA and ECC running on AnyDB read BYOD differently depending on the database vendor relationship.
The wider database-side reading sits in the Oracle and Microsoft practice pages at Oracle practice and Microsoft practice, both of which have parallel BYOL constructs that interact with SAP deployments.
AWS, Microsoft Azure and Google Cloud each have a different posture on BYOL for SAP workloads. AWS supports BYOL for both SAP application licences (under SAP's redeployment authorisation) and supporting database licences (under the respective database vendor's BYOL construct). Azure offers similar BYOL plus the Azure Hybrid Benefit construct on Microsoft database licences. Google Cloud supports BYOL on SAP and follows the database vendor's posture on the database side.
The buyer-side question is which hyperscaler offers the best BYOL economics for the specific workload mix. The answer depends on the application licence shape, the database licence shape, the storage and compute pricing on each hyperscaler, and the buyer's existing hyperscaler commitments.
The Admodum methodology models the three-hyperscaler comparison against the BYOL footprint for the buyer's specific licence portfolio. The wider hyperscaler choice context sits in the hyperscaler choice.
RISE with SAP is, in commercial terms, the opposite construct to BYOL. The RISE bundle wraps application licence, infrastructure, hyperscaler, HANA Cloud and managed operations into a single subscription. The BYOL construct does not apply inside RISE because the buyer is not bringing licences; the buyer is buying a subscription.
Where BYOL becomes relevant is in the buyer's decision between RISE and an on-premise (or hyperscaler-hosted) deployment. The on-premise model carries the BYOL option; the RISE model does not. The full reading on the five-year economics across the two models sits in RISE versus on-premise.
Where the buyer holds a heavy perpetual licence position and wants to preserve the asset value, the BYOL path inside an on-premise or hyperscaler-hosted deployment is often the more capital-efficient destination. The Admodum methodology models the asset-preservation question against the operational-burden question and prices the trade-off.
BYOL preserves the licence asset; it does not necessarily preserve the support relationship. The buyer who redeploys a perpetual SAP licence onto a hyperscaler can continue paying SAP for standard support (or for enhanced support), can move to a third-party support provider (Rimini Street, Spinnaker), or can run an unsupported configuration.
The third-party support reading sits in third-party support, the buyer view. The trade-off is between annual support spend (typically 22% of licence value under SAP standard support, or 12% under Rimini Street) and the support coverage scope.
The Admodum methodology models the BYOL plus support decision as a single combined question. The renewal-cycle frame sits in the SAP renewal cycle, and the engagement model in fixed fee or contingency.
Six checks for the buyer reading BYOL and BYOD for SAP: confirm the redeployment authorisation in the contract. Identify which hyperscaler offers the best BYOL economics. Read the database BYOD posture against the database vendor's BYOL construct. Compare the BYOL path against the RISE bundle on five-year economics. Decide the support posture before the redeployment. Consolidate BYOL into the wider renewal commercial picture.
For the wider SAP reading, return to the SAP pillar, visit the SAP knowledge hub, or open a private conversation with a senior Admodum SAP advisor through /contact/.
A senior Admodum SAP advisor will run the methodology through with your CIO, CFO, procurement team or audit response team on a private call. The engagement runs as fixed fee, contingency or annual retainer. Active SAP audits route directly to the Audit Defence programme.