advanced 3 min answer

SAP has published that mainstream maintenance for the SAP Business Suite 7 core applications runs to the end of 2027, with optional extended maintenance from 2028 to the end of 2030 at a premium of two percentage points on the maintenance base. Your conversion programme is estimated at 30 months and has not started. Which date do you take into the funding conversation, and what would be wrong to conclude from the published one?

sapvendor maintenancedeadlinesprogramme planningfunding
Show the full answer Hide the answer

The situation the date creates

An architect almost never has an externally set deadline they did not have to justify. A vendor's published end-of-maintenance date is one, and SAP's is unusually explicit: mainstream maintenance for the Business Suite 7 core applications to the end of 2027, an optional extended-maintenance window from the start of 2028 to the end of 2030 priced at two percentage points on the existing maintenance base, and customer-specific maintenance after that for anyone who does not take the extension. SAP has separately published an innovation commitment for S/4HANA to 2040.

This is the rare case where the constraint is not yours to argue about, which makes it the strongest material an architect gets. It is also the easiest to waste.

What the vendor's date is worth

Almost nothing on its own, because 2027 does not compete with this quarter. A deadline more than a budget cycle away loses every prioritisation contest to something with a date this year. Presenting it produces agreement in principle and no money, which is the outcome most of these conversations reach.

The number you actually negotiate with

Work backwards. A 30-month programme with a realistic 20% contingency is 36 months. Counting back from the end of 2027 puts the last safe start at the end of 2024, which has passed — so the mainstream date is already unreachable and arguing for it is arguing for a plan that cannot succeed. The binding date is the end of 2030, which puts the last safe start at the end of 2027, with the extension premium payable from the start of 2028.

That converts the conversation into two decisions with dates inside the planning horizon:

  1. Approve the extended-maintenance premium in the 2027 budget, because from 2028 it is not optional for you.
  2. Fund programme start by Q4 2027, because after that the 2030 finish needs scope cut rather than money.

The date you negotiate with is the last safe start, not the vendor's deadline, and its authority comes from arithmetic you own rather than from a vendor page.

What the extension costs

Two percentage points on the maintenance base is a real recurring number: on a maintenance bill of $4M a year it is roughly $80k a year for three years. Price it as what it is: a put option on schedule risk. The comparison is not against zero, it is against the cost of compressing a 36-month programme into 30, which in practice means overtime, more parallel change and a higher chance of a bad cutover.

Where copying this is a mistake

  • Treating every vendor date as equally firm. This one is published, dated and priced, with a named successor product and a stated commitment horizon. A roadmap slide from a small vendor is not the same object, and a programme built on one needs a decision point that does not depend on the date holding.
  • Using the date as the argument. The date creates the obligation; the last-safe-start arithmetic creates the urgency. Bring both, lead with the second.
  • Assuming the conversion is the only way to comply. Staying on a supported release, moving only what the business needs, or accepting customer-specific maintenance for a bounded, ring-fenced system are all legitimate answers, and each has a cost you can quantify. Presenting one option with a deadline attached reads as a threat; presenting three with costs reads as a decision.

Common weak answers

  • "The vendor will extend the date again." Sometimes true, and it is not a plan. A programme whose viability depends on a date moving has no decision point of its own, so build one: a scope-cut trigger at a date you set, independent of the vendor.
  • "Present the 2027 date every year until it is funded." This is what produced two years of agreement in principle and no money. The date did not fail because it was unclear; it failed because it was outside the planning horizon.
  • "Start immediately to be safe." Starting an unfunded 36-month programme produces a stalled one and burns the credibility needed for the funded attempt.