In February 2020 SAP announced mainstream maintenance for the core applications of SAP Business Suite 7 through to the end of 2027, with optional extended maintenance at a premium to the end of 2030, alongside a maintenance commitment for SAP S/4HANA to 2040. A manufacturer running that stack has roughly 700 custom modifications to standard objects in its ERP core. What kind of architectural constraint is a vendor maintenance date, what should it change about the plan and where would copying the obvious response be a mistake?

The situation they are in

The date is not a technology problem and not negotiable by the customer. It is an external, dated constraint with a priced option attached — which is a rare and useful shape, because it converts an open-ended "we should modernise" into arithmetic. Extended maintenance to 2030 is a purchasable extension rather than a reprieve: SAP set it at a premium of 2 percentage points on the maintenance base, so three more years has a published price and no new capability attached to it.

What the date actually is

Treat it the way you treat a regulatory application date rather than a stakeholder preference: it removes options rather than making them inconvenient. Two consequences follow immediately. The programme's end date is fixed and its scope is the variable, which inverts the usual planning conversation. And the option price is the cost of a decision, so the question to put to the board is not "do we move?" but "what do we buy for the premium, and which decisions will we have taken by the time it expires?"

What it costs them

Not the platform move. The 700 modifications are the work, because each one is a place where the organisation's rules were written into the vendor's objects, and each has to be classified as retire, re-implement through a supported extension point, or keep as an exception with a named owner. A realistic first pass is weeks of discovery per few hundred objects, and the usual finding is that a third are dead, a third are configuration someone implemented as code, and the remainder are the genuine business logic. The failure mode is discovering the count late: a programme sized on the platform migration and not on the modification inventory overruns by the length of the discovery it skipped.

The decision rule it should produce

SAP's published clean-core guidance is the useful part to copy, independent of the deadline: extend only through released interfaces and business events that carry a stability contract, and put new behaviour beside the core rather than inside it. The point is not tidiness. It is that an upgrade's cost is proportional to the number of unsupported touch points, so a clean core is what stops the next vendor deadline costing the same as this one. Make "no new modifications to standard objects without a recorded exception" a rule from the day the programme starts, or the inventory grows while you are clearing it.

When not to copy this

Two cases. A company with 30 modifications and a standard process should not run a multi-year programme; choose the vendor's path on the vendor's timetable and spend the money elsewhere. And do not assume the extension is available or cheap for your contract and your release level — the dates differ by product version, and a plan built on an assumed 2030 that turns out to be an earlier date for your release has lost 100% of its slack. Confirm your own end dates in writing before the plan depends on them.