Alkemia · Enterprise Apps Strategy

Six conditions set what the contract will cost,
and they arrive filled in by default.

The cost of a Cloud ERP contract across its term is set by conditions which arrive filled in by default, are rarely presented as a choice, and stop being negotiable on the day of signature. There are six, all of them legible in documents the customer already holds. The starting price is the most contested term in the proposal, and usually the only one the negotiation reaches.
For anyone holding a SAP Cloud ERP proposal under evaluation
Where the terms live

A Cloud ERP contract is spread across several documents, and the difference between two of them decides what is worth negotiating. The general terms carry the conditions that hold for the whole family of contracts and are not rewritten customer by customer. The order form and the service annexes carry what is specific to that operation: duration, contracted entitlements, escalation, service scope, availability levels. A team that does not separate the two spends negotiating capital where nothing moves, and accepts as immutable what was the real subject of the conversation.

The two documents

One part is constant. The other is the negotiation.

Constant

General terms

They hold for the whole family of contracts and are not rewritten per customer. This is where the absence of termination for convenience sits, along with the absence of a fallback to a perpetual licence and the inability to reduce contracted volume inside the term.

Knowing they are constant keeps the negotiation from being spent where it has no effect. The content of those clauses remains decision information: it is what defines the cost of changing your mind.

Specific

Order form and annexes

They carry what belongs to that operation: duration, entitlements and the bases they are metered against, annual escalation, renewal mechanics and notice periods, included service scope, availability level, and what counts as an additional service.

This is where the proposal can still change before signature, and it is the part that arrives pre filled with default values nobody presented as a decision.

Why the window is short

The maintenance clock compresses the phase that sets the economics.

The dates are public and specific. For Business Suite 7, which includes SAP ERP 6.0 (ECC) and is the on-premise generation before S/4HANA, SAP provides mainstream maintenance for the core applications until the end of 2027. From 2028 to 2030 there is optional extended maintenance, carrying a premium of two percentage points on the maintenance basis, applicable to the Business Suite 7 support scope and not only to the part still being converted. Customers who do not elect it move to customer-specific maintenance. For the core applications, these mainstream and extended maintenance windows cover only the three most recent enhancement packages (EHP) of each application (for SAP ERP 6.0, EHP 6, 7 and 8). Systems with no enhancement package or on an earlier level must upgrade to one of these eligible levels to receive maintenance under these windows. For the most complex scenarios, the SAP ERP, private edition, transition option provides a continuity subscription between 2031 and 2033, with prerequisites of its own, among them migration to SAP ERP, private edition on SAP HANA completed before the end of 2030. For S/4HANA, SAP has committed to there always being at least one release in maintenance through the end of 2040.

The effect of those dates on the negotiation is indirect, and that is the point. They shorten the time available for the one phase in which the terms are still reversible, and that phase is the first to be cut when the schedule tightens, because it is the one that produces no visible deliverable. The diligence that disappears is the commercial and contractual one, because it usually has no designated owner.

After signature the same request changes in nature. Before, it is backed by a concrete alternative: do not sign, sign something else, sign later. Afterwards it becomes a change request assessed with no counterparty, and what used to be negotiated is now bought.

What has to be settled

Six decisions, and the document where each one is read.

None of them requires privileged access to vendor information. All of them are written in documents the customer receives before signing. What changes the outcome is treating them as decisions while there is still an alternative on the other side.

  • A

    The baseline of what is already owned

    What of the current estate enters the subscription, and what leaves before it does.

    A proposal is sized against a reading of what the customer already owns and already uses. Where that reading has not been redone, idle entitlement crosses into the conversion and stops being a parked asset to become a recurring commitment, paid every year of the term. Redoing that reading before signature changes the calculation base on which everything else is priced.

    Where it is read: The customer’s own contracts and entitlement history, against the baseline the proposal assumes.

  • B

    The measurement base of each service

    What the cost grows against, service by service, across the term.

    Subscribed services do not all meter the same thing. Some scale by classified user, some by document processed through a third party system, some by business volume. Two practical consequences follow: the projection has to be built on projected volume rather than current volume, and it is worth checking whether two different services meter against the same base, which exposes one quantity twice.

    Where it is read: The entitlement lines of the order form and the service description behind each item.

  • C

    What sits inside the fee and what is a separate line

    The boundary between included service and additional service, written down before it is needed.

    The subscription carries a service baseline. Items that real operations usually require sit outside it: security and compliance packages scoped against documented gaps, extended backup retention, non production environments and the number of test cycles they support. None of these is a contractual surprise, all of them are written down. What decides the cost is whether they were scoped before signature or requested afterwards, when the price stops being comparable.

    Where it is read: The roles and responsibilities document, which separates standard service from additional service.

  • D

    The mechanics of the term

    Duration, renewal, escalation, and what happens if the requirement shrinks.

    This is the distinction that changes the conversation most. Part of these conditions is standard across the general terms and holds for every contract in the family: there is no termination for convenience, no fallback to a perpetual licence, no reduction of contracted volume within the term. Another part belongs to the order form and varies case by case: duration, annual escalation, and the renewal mechanics, including any asymmetry between the customer’s notice period and the vendor’s. Treating both as the same thing makes a team spend negotiating capital where nothing moves, and accept as fixed what was the real subject of the conversation.

    Where it is read: The general terms for what is standard, the order form for what varies.

  • E

    The economics of the service level

    What the availability commitment is worth against the cost of an hour of downtime.

    The contractual remedy for unavailability is a credit against the fee, and it is capped. The ceiling of that remedy is a function of the fee paid to the vendor, while the loss from an outage is a function of what stopped operating. These are two independent quantities. The decision lies in comparing the price of the higher commitment against the customer’s own cost of an hour of downtime in the processes that genuinely stop. For many operations the standard level is enough, and that is a defensible conclusion too.

    Where it is read: The service level annex, read against a downtime cost the customer has calculated.

  • F

    The exit

    What it costs to recover your own data, and how many times that is included.

    Data handover at offboarding is a standard service, delivered once per contract cycle, with planning, transfer and storage sitting with the customer. Any further occurrence during the term is an additional service. This matters before signature because fairly common scenarios call for more than one extraction: a parallel run, a carve out, the departure of a business unit. Modelling the exit at signature is the only moment when it is still comparable against alternatives.

    Where it is read: The service description for data handover and what it assigns to the customer.

The order matters. The first three fix the calculation base, and the last three can only be assessed once that base exists.

Each of these six is a choice until signature. At signature, they all become assumptions.

Alexandre Pereira

The next step

Test the proposal while the assumptions are still reversible.

For the CFO who answers for the multi year commitment and the CIO who answers for the architecture it fixes, the operational question is: of the six, how many are settled in writing in the current proposal. A 30-minute conversation, with no obligation, is enough to identify which ones were left open and which depend on information that has not yet been requested from the vendor. If the conclusion is that the proposal already holds as it stands, that is a useful answer too, and it is the one that makes the rest of the work unnecessary.

Discuss your decision

contact@alkemia.io

When the work needs to go beyond a conversation, the entry point is the pre signature diagnostic.

For the same programme read from the failure side, see why SAP Cloud ERP programmes fail.

Frequently asked questions

The pre signature decision, in practical terms.

When does SAP ECC maintenance end?
SAP ECC (SAP ERP 6.0) is part of SAP Business Suite 7, the on-premise generation before S/4HANA. SAP provides mainstream maintenance for the core applications of Business Suite 7 until the end of 2027. From 2028 to the end of 2030 there is optional extended maintenance, carrying a premium of two percentage points on the maintenance basis, applicable to the Business Suite 7 support scope. Customers who do not elect it move to customer-specific maintenance. For the core applications, these mainstream and extended maintenance windows cover only the three most recent enhancement packages (EHP) of each application (for SAP ERP 6.0, EHP 6, 7 and 8). Separately, SAP has committed to there always being at least one release of S/4HANA in maintenance through the end of 2040.
Is there a path after 2030?
There is, and it has a shape of its own: a time bound subscription with its own scope, price and prerequisites. SAP offers SAP ERP, private edition, transition option for business continuity between 2031 and 2033. The published prerequisites are specific: the system must have migrated to SAP ERP, private edition on SAP HANA before 31 December 2030, SAP HANA is the only supported database, there is a minimum size of 2 TB, and the offering exists only in combination with the max success plan, SAP’s success plan carrying additional transformation services, during the period. Each of those prerequisites is a decision that has to fit the current schedule, because the migration window closes on 31 December 2030.
Does negotiating the discount well not settle the cost of the contract?
It settles one part, and it is the part that receives the most attention. The discount applies to the starting price. What the contract costs across the term also depends on the base each service is metered against, on what sits inside the fee and what is a separate line, on the annual escalation and on whether volume can be reduced at all, and on the cost of leaving. Those conditions keep applying long after the discount has been granted, and most of them are never presented as a choice because they arrive filled in by default.
What can still be changed after signature?
Less than is usually assumed, for a structural reason. Before signature there is a concrete alternative: do not sign, sign something else, sign later. That alternative is what gives economic content to any request. After signature the same requests become change requests, assessed with no alternative on the other side, and the price of those changes reflects that absence.
How does the ERP contract affect the AI agenda?
A Cloud ERP contract fixes, for several years, the transactional core the AI agenda will operate on: where the data sits, in what format it leaves, which integrations are contracted, and what each document processed by an external system costs. AI initiatives that depend on reading from or writing to that core inherit those conditions without being able to renegotiate them. It is worth bringing the AI use cases already foreseen into the evaluation of the proposal, while the measurement bases and the extraction rights are still open.
Does every proposal need this review?
No. Where the estate is small and homogeneous, the entitlement inventory is current, there are no material integrations with third party systems and the committed value is modest, an independent review tends not to repay the time it consumes. The work earns its place when the committed value is material, when the measurement base is uncertain, or when the schedule is pressing the decision hard enough that diligence is being cut to fit the window.

The conditions of a specific contract depend on the edition of the applicable documents, on the order form actually proposed, and on the jurisdiction. Before acting, it is worth validating the concrete case against your own documents and with legal support.

SAP and SAP product names are trademarks of SAP SE or its affiliates. Alkemia is an independent consultancy with no affiliation to, endorsement from, or representation of SAP. This material is informational, describes contractual structures in general terms, and constitutes neither legal advice nor a determination of the terms of any specific contract. The maintenance dates reflect positions published by SAP and consulted in August 2026.