Data portability and exit clauses in RISE.

The data portability and exit clauses in the standard RISE with SAP order form do not read as weak on first inspection. They use familiar contract language, they reference industry standard data formats, and they invoke a transition support obligation that sounds reassuring to a buyer reading it once. The weakness only becomes visible when the clauses are tested against the practical question of what the buyer can actually take with them, in what format, on what timeline, and with what indemnity coverage if the extract proves incomplete. A buyer that negotiates these clauses at the level of detail they deserve typically discovers that the SAP standard language commits the seller to almost nothing it would not have done anyway, and that the genuine portability and exit protections require redrafting rather than minor amendment. This article walks the clauses that matter, the SAP standard language, the gaps that surface in practice, and the buyer side positions that close those gaps.

What the standard order form actually says

The standard RISE with SAP order form addresses data portability through a reference to the SAP cloud services agreement, which itself addresses portability through a transition assistance clause and a data extraction commitment. The transition assistance clause obligates SAP to provide reasonable cooperation in transitioning the buyer to a successor system at the end of the contract term. The data extraction commitment obligates SAP to make the buyer data available in a format that allows the buyer to import it into another system, with the format described as industry standard or commercially reasonable.

The language sounds adequate until the practical test arrives. Reasonable cooperation is not defined in time, in scope, or in cost. Industry standard format is not defined as CSV, XML, JSON, or proprietary HANA artifacts. The data extraction commitment does not address custom code, configuration, integration mappings, or the metadata that gives the data its meaning. The transition assistance does not commit to a successor system handover plan, to a parallel run period, or to the operational support during the cutover.

The standard order form also addresses exit through a termination for convenience clause that gives SAP, but not the buyer, the right to terminate on notice. The buyer termination rights are limited to material breach or insolvency, with the material breach standard high enough that it rarely produces a clean exit path. The contractual asymmetry on termination rights is one of the most undernegotiated structural features of the standard agreement.

The data portability gaps in practice

The data portability gaps surface in the actual exit scenarios that engagement files document. The most common gap is the metadata gap. The buyer receives a data extract that contains the transactional records but does not contain the configuration metadata, the master data hierarchies, or the cross reference tables that convert the raw records into operational meaning. The extract is technically a data extract, but the receiving system cannot interpret it without the metadata that the standard clause does not require SAP to provide.

The second gap is the custom code gap. The buyer that has invested in custom ABAP enhancements, in BTP extensions, or in integration suite scenarios discovers that the exit clause does not address ownership, transfer, or technical handover of the custom code base. The custom code that the buyer commissioned, often for several million dollars across the contract life, sits inside the RISE perimeter and is not portable under the standard clause.

The third gap is the timeline gap. The standard transition assistance commitment runs for a defined period after termination, typically thirty to ninety days. The practical exit of a complex SAP estate to a successor system or a successor operator usually takes six to twelve months. The window the standard clause provides is insufficient. The buyer that did not negotiate an extended transition window discovers during the exit that it is paying SAP for extended support at unfavourable rates, or that it is operating without the support it needs during the cutover period.

The fourth gap is the format gap. The standard reference to industry standard format does not commit SAP to provide data in the specific format the successor system requires. SAP can satisfy the standard clause by delivering data in a format that no successor system can import without significant transformation. The buyer that did not negotiate a specific format requirement carries the transformation cost.

The buyer side positions on data portability

The buyer side positions on data portability close each of the gaps with specific clause language. On metadata, the buyer should require SAP to deliver the configuration metadata, the master data hierarchies, the cross reference tables, and the documentation that supports the operational interpretation of the data extract. The clause should name the artifacts in a defined annex rather than leaving them to a generic obligation.

On custom code, the buyer should require SAP to provide the buyer with the source code, the build artifacts, and the deployment documentation for all custom code developed during the contract life. The clause should explicitly address ABAP enhancements, BTP extensions, integration suite scenarios, and any analytics content built on the SAP Analytics Cloud or on the Datasphere components. The ownership of the custom code should sit with the buyer rather than with SAP.

On timeline, the buyer should require an extended transition window of twelve months at minimum, with the option for the buyer to extend by an additional six months on commercially reasonable terms. The clause should commit SAP to maintain operational support, security patching, and incident response across the extended window at pricing defined in the original contract rather than at exit pricing.

On format, the buyer should require data delivery in named formats. The standard buyer specification is CSV for transactional records, structured XML for configuration metadata, JSON for integration definitions, and source for custom code. The clause should commit SAP to deliver the data in the named formats at a frequency that the buyer specifies, with the option for a final full extract at the end of the transition window.

The exit clause structural negotiations

The exit clause structural negotiations sit above the data portability detail. The first structural question is the symmetry of termination rights. The buyer should require a termination for convenience right that mirrors the SAP right, with a notice period that accommodates the operational transition. The reciprocal termination right is rarely conceded in full, but a partial right, typically a termination for convenience at the end of year three or year five with defined fee implications, is commercially available.

The second structural question is the exit credit. An exit credit is a commercial mechanism that compensates the buyer for the operational cost of the exit transition. The exit credit is structured as a defined percentage of the most recent annual fee, often in the range of twenty to thirty percent, paid by SAP to the buyer if the buyer exercises a termination right at end of contract. The credit funds the buyer side cost of the transition without requiring the buyer to negotiate the credit at the moment of exit, when the buyer leverage is at its weakest.

The third structural question is the no penalty exit. The standard contract includes a range of fees, penalties, and accelerated charges that can apply to a buyer initiated exit. The buyer should negotiate explicit confirmation that an exit at end of term, or under the defined termination rights, does not trigger early termination fees, accelerated subscription charges, or restoration costs beyond the standard transition assistance.

What SAP typically concedes

SAP responses to these buyer side positions are documented across engagement files. On metadata, the SAP standard concession is to commit to deliver the metadata in the agreed format, usually after escalation to regional leadership. On custom code, the SAP standard concession is to provide the source code and the build artifacts, with a usually accepted carve out that the SAP delivered standard objects remain SAP intellectual property. On timeline, the SAP standard concession is to extend the transition window to six months as the first move, with extensions to nine or twelve months available at the regional senior vice president level. On format, the SAP standard concession is to commit to named formats once the buyer specifies them clearly.

On termination rights, the SAP standard concession is partial. A full reciprocal termination for convenience is rarely conceded. A termination at end of year three with defined fee implications, or a termination at end of year five with no incremental fee, is achievable at the senior vice president level. The exit credit is rarely conceded at the local account team level but is achievable at the regional level, often in the range of fifteen to twenty five percent of the most recent annual fee.

Conclusion: the exit is negotiated at signing, not at exit

The exit from a RISE with SAP contract is negotiated when the contract is signed, not when the buyer wants to leave. A buyer that signs the standard order form and then attempts to negotiate exit terms at year six discovers that the contractual leverage has shifted entirely to SAP. The data is inside the SAP perimeter. The custom code is inside the SAP perimeter. The operational continuity depends on SAP cooperation. The buyer side position at exit is structurally weak. The position is built at signing through specific clause language on metadata, custom code, timeline, format, termination rights, and exit credits. The buyer that brings these positions to the negotiation, with documented language and named approval thresholds, captures the protection the standard clauses do not provide. The buyer that does not bring these positions accepts an exit pathway that exists in name but not in operational practice.