Lesson 3 of 5
Lifecycle cost
9 min
The build estimate is the number everyone sees. It is also the smallest part of what an extension costs. A process owner who approves gaps on build cost alone will be surprised, every year, by the bill for keeping them working. This lesson shows how to estimate the full cost and why many small gaps add up to a big one.
Five cost components
| Component | What it covers | When it recurs |
|---|---|---|
| Design and build | Specification, development, configuration, unit test | Once |
| Project testing | Integration and user acceptance tests that cover the extension, plus negative tests | Once per project |
| Upgrade and change regression | Retesting the extension and the processes it touches at every release upgrade, feature pack or support package, and after related changes | Every release and change |
| Remediation | Fixing the extension when SAP changes something it relied on | Unpredictable; higher for lower clean core levels |
| Support and documentation | Incidents, knowledge transfer, keeping documentation current | Every year |
The five components of extension lifecycle cost.
Why regression testing dominates
Release rhythm drives regression cost. SAP announced in 2022 that SAP S/4HANA on-premise and Private Edition move to a two-year release cycle from the 2023 release, with feature packs in between, and seven years of mainstream maintenance per release. SAP S/4HANA Cloud Public Edition is upgraded by SAP on a fixed schedule, twice a year. Either way, every extension must be retested on SAP's timetable, not yours, and each support package or feature pack you apply is another reason to retest.
The regression cost is not only the extension itself. A custom field on the sales order that flows to billing touches order entry, delivery, billing output and possibly revenue reports. All of those scenarios join the regression set.
A worked estimate
Here is an illustrative estimate for Contoso's "fleet contract number on invoices" extension over seven years. The numbers are examples, not benchmarks; use your own rates.
| Item | Assumption | Person-days |
|---|---|---|
| Build (key user field + output change) | Design, configuration, unit test | 6 |
| Project testing | 4 order-to-cash scenarios with and without the field | 4 |
| Regression per upgrade or feature pack | 4 scenarios × 0.5 day, plus evidence review; about 8 events in 7 years | 8 × 2.5 = 20 |
| Remediation | Level A, low exposure: allow 1 small fix | 2 |
| Support | 0.5 day per year | 3.5 |
| Total | 35.5 (build is 17%) |
Illustrative seven-year cost of one small, clean extension.
Even a small, clean extension costs about six times its build effort over its life in this example. A Level C or D extension can cost much more, because remediation becomes likely rather than occasional and the scope of regression grows.
| Factor | Level A extension | Level D modification |
|---|---|---|
| Build | Similar | Similar or lower |
| Upgrade checks | Released interfaces stay stable | Must be compared against SAP's new version every upgrade |
| Remediation risk | Low | High; breaks silently |
| Regression scope | Processes using the extension | Processes using the modified object, often wider |
| Public Edition | Allowed | Not possible |
- Year 0Build and project test10 person-days: design, configuration, unit, integration and acceptance tests
- Year 1First feature packRegression of 4 scenarios plus evidence review: 2.5 person-days
- Year 2Release upgradeRegression plus a check that the field still flows to billing output
- Years 3–6Feature packs and upgradesAbout six more regression cycles, plus one small fix
- Year 7Review or retireIs the field still required by contract, or does SAP now offer it?
Small gaps add up
Each gap looks cheap on its own. Fifty "small" gaps at 30 person-days each over their lives is 1,500 person-days: several full-time people doing nothing but keeping extensions alive. That is why gap approval needs a running total. Ask the PMO for a gap register that sums lifecycle cost, not just build cost, and review it at every steering meeting.
Questions to ask before you approve
- Which processes and test scenarios does this extension touch, and who owns them?
- How long does one regression cycle for those scenarios take, and can it be automated with SAP's own tools?
- Which clean core level is it, and what SAP objects does it depend on?
- Who supports it after the project team leaves, and is that support funded?
- What would it cost to retire it later if SAP delivers a standard option?
If the answers make the extension look expensive, that is useful information, not a reason to hide it. Sometimes the value case still wins. The point is that the process owner approves the real number, in front of the steering committee, rather than discovering it at the first upgrade.
What would you do?
A developer offers to build Contoso's warranty scoring logic as a quick change inside a standard SAP billing program: "two days, done." A side-by-side app would take 12 days. What should Dan ask before deciding?
- Lifecycle cost = build + project testing + upgrade regression + remediation + support.
- Regression recurs on SAP's release rhythm and usually dominates the total.
- Lower clean core levels raise remediation risk and widen regression scope.
- Keep a running total of lifecycle cost for all approved gaps.
Check your understanding · not graded
Lesson check
1. Which cost component usually dominates an extension's lifecycle cost?
2. How often is SAP S/4HANA Cloud Public Edition upgraded by SAP?
3. Why does a Level D modification usually cost more over time than a Level A extension?
4. What should a gap register sum to make cost visible?