Budget overrun patterns in RISE conversions.

Roughly seven in ten RISE with SAP conversion programmes close above their approved budget. The overrun is rarely catastrophic at any single line. It is the cumulative effect of six predictable patterns, each one accepted as a normal in flight adjustment, that together produce a final spend twenty two to thirty eight percent above the original board approved number. Every one of those patterns is visible at the point of contract, and every one of them can be priced into the original budget if the buyer side leads know where to look. This piece walks the patterns the firm has tracked across more than five hundred engagements, the contractual surfaces that allow them to surface, and the controls that hold the line through go live.

Pattern one. Hyperscaler infrastructure trues up to actual usage

The bundled RISE proposal carries an infrastructure line sized against an SAP supplied workload estimate. The estimate is consistently conservative on the storage tier, the network egress allowance, and the non production environment sizing. When the conversion lands and the actual workload is measured, the production environment runs within the original estimate, the non production environments run thirty to fifty percent above the estimate, and the storage tier carries an unforecast premium for the workload mix that SAP delivers under RISE.

The line on the original proposal looks bounded. The reality is that the line is sized against a sample workload and the true up at the end of year one is the moment the budget breaks. The firm has tracked the infrastructure true up across the engagement base. The median overrun on the year one infrastructure line is fourteen percent against the proposal. The mechanism is structural to the way SAP scopes the bundled infrastructure, and the only buyer side defence is to require the workload sizing to be jointly validated against the existing system telemetry before signature, with the true up rate capped inside the contract at the original closing rate plus a defined annual uplift.

Pattern two. Custom code remediation runs above the SI estimate

The SI partner bid for the conversion programme is anchored against the SAP Custom Code Migration analysis, which scans the existing ECC or older S/4HANA codebase and reports a remediation effort estimate. The estimate is reliable for the unambiguous cases. It is unreliable for the boundary cases where the custom code interacts with third party add ons, with bespoke Z transactions that have evolved through multiple developers, and with reporting layers that sit outside the formal change control records.

The actual remediation effort across the firm engagement base runs between eighteen and forty two percent above the SI bid estimate, with the higher end concentrated in organisations that have run SAP for more than fifteen years. The pattern surfaces in month three of the conversion programme, by which point the SI partner has burned the contingency on the unambiguous cases and the boundary cases land as change requests against the buyer budget. The buyer side control is to set the SI contract on a fixed price for the unambiguous cases and a not to exceed cap on the boundary cases, with a joint sign off process on each change request and a contractual obligation on the SI to absorb the first ten percent of the boundary case overrun.

Pattern three. Integration and middleware costs land outside the RISE bundle

The RISE proposal carries a BTP integration credit allocation, sized against the integration roadmap presented during the negotiation. The allocation rarely covers the full integration scope that emerges through detailed design. The patterns the firm has seen include legacy middleware that the buyer assumed would be retired but that needs to run in parallel for two years, third party integration platforms that hold business critical interfaces and that fall outside the BTP perimeter, and event streaming infrastructure that the BTP allocation does not include.

The cost surfaces as an unbudgeted line, typically in month six of the conversion, when the integration architecture decisions are made and the gap between the BTP allocation and the actual integration scope is documented. The median overrun across the firm engagement base on the integration line is twenty one percent against the original budget. The buyer side control is to map the full integration scope before signature, to size the BTP credit against the SAP native integration use cases only, to keep the non SAP integration platforms on a separate budget line, and to negotiate a BTP overage rate that is bounded inside the contract.

Pattern four. Change management and adoption costs are underfunded

The change management line on the original conversion budget is, in the firm engagement base, consistently undersized against the actual programme need. The default budget allocation runs at between three and five percent of the total programme cost. The actual change management spend, measured at go live across successful conversions, runs at between eight and twelve percent of total programme cost. The gap surfaces late, in the final quarter before go live, when the adoption work that has been deferred has to be funded against the contingency.

The pattern repeats because the original budget treats change management as a category the SI can deliver with a small named team. The reality is that the change management work spans user research, business process documentation, training material design and translation, super user enablement, hyper care staffing, and the post go live optimisation work that runs for six months into production. Each of these workstreams has a real cost, and the sum is materially above the default allocation. The buyer side control is to build the change management budget against a benchmarked allocation of eight percent of total programme cost, with the line approved at the original budget rather than landing as a contingency draw in month twelve.

Pattern five. Testing and parallel run extends beyond the planned window

The conversion plan includes a defined testing and parallel run window, typically scoped at three months from system integration testing through to go live. The plan assumes that the test cycles complete on schedule and that the parallel run period closes cleanly. Across the firm engagement base, neither assumption holds for the majority of conversions. The test cycles uncover defects that require remediation cycles, the parallel run period extends when business critical processes do not reconcile cleanly between the legacy system and the new RISE environment, and the go live date slips by between four and ten weeks.

The cost of the extension is concentrated in three areas. The SI partner remains on the programme longer than the original statement of work covers, with the extension billed at time and materials. The internal team backfill costs continue to accrue against the operational budget. The legacy system runs in parallel for longer than planned, with the licence, support, and infrastructure cost continuing through the extension. The firm has tracked the cost of slip across the engagement base, and the median value of a four week slip on a conversion programme of two hundred users is in the order of one and a half million dollars. The buyer side control is to build the conversion plan with a documented slip contingency, to set the SI extension rate inside the original contract, and to scope the legacy system run down with optionality for an extension at a pre agreed rate.

Pattern six. The post go live stabilisation period is rarely budgeted

The final pattern surfaces after go live. The original budget closes at the go live milestone, with a small hyper care allocation and an assumption that the system enters steady state operation. The reality across the firm engagement base is that the first six months after go live carry a stabilisation cost between five and nine percent of the total conversion budget. The cost covers the residual defect remediation, the unplanned BTP consumption against the integration patterns that emerge in production, the user adoption support that scales when the full user base lands on the system, and the additional infrastructure scaling that the year one workload demands.

The pattern is consistent across industries and conversion sizes. The buyer side control is to define the stabilisation period explicitly inside the original budget, to allocate a dedicated stabilisation budget that is separate from the conversion contingency, and to staff the stabilisation period with a defined team rather than treating it as a residual of the conversion programme. The discipline allows the programme to close the conversion budget cleanly at six months post go live, with the operating budget taking the system from that point onwards.

The patterns are predictable and the controls are available

Each of the six patterns is visible at the point of contract negotiation. Each one can be priced into the original budget if the buyer side leads recognise the pattern and build the controls in. The compounding effect of the six patterns, left uncontrolled, produces the twenty two to thirty eight percent overrun that the firm sees across the engagement base. The same six patterns, with the controls in place, produce a programme that closes within five percent of the original board approved number. The work is not analytical complexity, it is pattern recognition. The RISE conversion programmes that close on budget are the programmes where the buyer side leads have walked the patterns before signature, priced each one into the original number, and held the line through the conversion with the contractual controls that the negotiation has put in place. The method is the discipline, and the discipline starts at the negotiation table rather than at the conversion kickoff.