A practical guide to building the business case for SAP S/4HANA migration, covering costs, ROI, benefits, risks, and strategic value for UK businesses.
For a UK enterprise, the case for moving to SAP S/4HANA should not be built around a technology upgrade alone.
An S/4HANA programme can require significant investment in software, implementation, data, integrations, testing, change management, infrastructure, and internal resources. The business case therefore needs to demonstrate something more important than technical readiness:
Why should the organisation invest in changing its ERP platform now, and what measurable business value will the investment create?
This is particularly important for organisations still running SAP ERP 6.0. SAP states that mainstream maintenance for the latest three enhancement packages of SAP ERP 6.0 runs through 31 December 2027, followed by optional extended maintenance through 31 December 2030. SAP also maintains its innovation commitment for S/4HANA through 2040, with at least one S/4HANA release in maintenance at any given time.
The maintenance timeline can be an important business driver, but it should not be the entire business case.
A well-structured business case connects:
Business Strategy + Current-State Costs + Transformation Benefits + Migration Investment + Risk + Future Value
The objective is to demonstrate not only that the organisation needs to change, but that the proposed S/4HANA transformation is the right investment compared with the realistic alternatives.
A weak business case often looks like:
Legacy SAP → S/4HANA → Modern Technology
That is not enough to secure a major enterprise investment.
A stronger business case answers six questions:
This means the analysis should start before the S/4HANA solution is selected. The organisation should first understand its current position, define what it needs from the future ERP environment, and then compare the available options.
The main scenarios may include:
Stay on Current SAP
vs.
Optimise the Existing Environment
vs.
Transform to S/4HANA
This approach makes the business case a decision-making framework rather than a justification for a decision that has already been made.
The business case should begin with the organisation's strategy and operational priorities.
Typical drivers for a UK enterprise may include:
For example, a UK manufacturer may not need S/4HANA simply because its ERP is approaching the end of mainstream maintenance.
The underlying business problems may be that:
The business case should connect the ERP problem to the business problem.
Instead of:
“We need S/4HANA because SAP ERP is approaching the end of mainstream maintenance.”
A stronger business framing is:
“We need to modernise our ERP platform to support the business strategy, reduce operational and technical risk, standardise critical processes, and establish a sustainable platform for future growth.”
The maintenance timeline can then be presented as an additional factor that affects the timing of the decision.
Once the business drivers are clear, the next step is to establish what the organisation is spending today and where the current environment creates operational constraints.
The baseline should cover four areas.
Measure:
Measure:
Measure:
Measure:
This baseline provides the reference point for the rest of the business case. Without it, statements such as “S/4HANA will reduce costs” are difficult to validate.
Once the current state is understood, the organisation should assess what happens if it does not transform.
The alternative to migration is not zero cost.
A legacy SAP environment may continue to generate:
For SAP ERP 6.0 EHP6–8, mainstream maintenance ends on 31 December 2027, followed by an optional extended-maintenance phase through 31 December 2030.
This means the business case should model several scenarios.
Include:
Include:
Include:
The purpose is not to make one option appear preferable. It is to understand the economic consequences of each realistic path.
The next step is to identify what the organisation expects to gain from the transformation.
Not every benefit should be placed into a single ROI calculation. Separating value into categories makes assumptions easier to validate.
Examples:
Examples:
Examples:
Examples:
Examples:
These categories should remain connected to the business drivers identified earlier. If a benefit cannot be linked to a meaningful business requirement, its place in the business case should be questioned.
This is where the business case moves from general benefits to measurable outcomes.
Instead of saying:
“S/4HANA improves efficiency.”
identify the specific process, establish the current baseline, and define how improvement will be measured.
Current:
Financial close = 10 business days
Target:
Financial close = 7 business days
Potential value:
Current:
40% of incoming payments require manual intervention
Target:
25%
Potential value:
Current:
Manual purchase-order processing = 30 minutes per transaction
Target:
20 minutes
Potential value:
10 minutes × annual transaction volume × loaded labour cost
Current:
Manual exception handling = 1,500 hours annually
Target:
900 hours
Potential value:
600 hours × loaded labour cost
The important point is that the value should come from the organisation's own processes and data, not from generic S/4HANA benchmarks.
Once the expected value is understood, the organisation can build the investment model.
The cost model should be broader than the implementation partner's proposal because the programme creates costs across technology, business operations, and internal resources.
A comprehensive model should include:
| Cost Category | Examples |
| Assessment | Readiness, discovery, architecture |
| Software | SAP subscriptions / licences where applicable |
| Implementation | Functional and technical delivery |
| Data | Cleansing, mapping, migration, reconciliation |
| Custom Code | Analysis, remediation, redevelopment |
| Integration | Interface redesign and testing |
| Infrastructure | Cloud, hosting, environments |
| Testing | Functional, integration, regression, performance |
| Change Management | Training, communications, adoption |
| Internal Resources | Business SMEs and IT staff |
| Programme Management | PMO, governance, architecture |
| Cutover | Migration rehearsals, downtime, go-live |
| Hypercare | Additional support after go-live |
| Decommissioning | Legacy SAP and related systems |
| Ongoing Operations | AMS, cloud, support, monitoring |
The organisation should also include contingency for material risks rather than assuming the initial implementation estimate is the final investment.
The initial transformation investment is only one part of the financial picture.
The organisation should compare the cost of operating the current environment with the expected cost of operating the target environment.
Infrastructure + Support + Development + Interfaces + Security + Contractors + Operational Inefficiency
with:
Subscription / Licensing + Cloud + Support + AMS + Enhancements + Internal Team + Governance
The planning horizon might be five or seven years, depending on the organisation's investment strategy.
A migration can have a high initial cost while producing a different cost profile over time. Similarly, moving to cloud ERP may shift expenditure from capital investment to recurring operating costs without automatically reducing total cost.
The business case should therefore compare total economic value over the agreed planning period, rather than focusing on the initial migration cost alone.
With investment and benefits defined, the organisation can model the financial return.
A basic ROI calculation is:
ROI = (Total Benefits − Total Investment) ÷ Total Investment × 100
However, enterprise ERP programmes should not be assessed using a single percentage.
The financial model may also include:
Total Quantified Benefits − Total Transformation Cost
How long does it take for cumulative benefits to recover the initial investment?
For larger programmes, calculate Net Present Value over the agreed investment horizon.
For more sophisticated investment cases, calculate the Internal Rate of Return.
Compare the total cost of the current environment with the target S/4HANA environment.
Together, these measures provide finance and executive stakeholders with a more complete view of the investment.
Not every benefit should be treated as guaranteed savings.
These can usually be measured directly.
Examples:
These may create substantial value without appearing as direct P&L savings.
Examples:
Rather than converting every strategic benefit into a speculative cash figure, define its value, measurement method, and confidence level.
| Benefit | Measurement | Confidence |
| Reduced support effort | Support hours / month | High |
| Faster close | Days to close | High |
| Better planning | Forecast accuracy | Medium |
| Faster market entry | Days to launch | Medium |
| Better decision-making | Management reporting cycle | Medium |
This keeps the financial model disciplined while ensuring that strategic value is not ignored.
ERP business cases become less credible when they rely on generic improvement percentages such as:
Published customer examples can be useful benchmarks, but they should not automatically become forecast results for another organisation.
SAP publishes customer and solution material showing benefits from S/4HANA and cloud ERP, but outcomes depend heavily on the implementation, scope, operating model, adoption, and starting point.
For an internal business case, use:
Current Baseline → Target → Measurement Method
This makes assumptions easier to validate and benefits easier to track after go-live.
One of the less obvious S/4HANA benefits can come from process standardisation.
A UK enterprise may have:
The migration creates an opportunity to establish:
Global Process Standard
with:
Approved Local Variations
This can reduce:
For organisations with acquisitions or multiple business units, this can be one of the most important strategic benefits.
A stronger business case also quantifies improvements that sit outside the ERP core.
Measure:
Measure:
S/4HANA transformation may provide an opportunity to rationalise and redesign these areas.
The value should be attributed to specific changes rather than automatically attributed to “S/4HANA”.
Every major SAP transformation carries risk.
The business case should therefore model:
Base Case + Downside Case + Upside Case
Assumes expected implementation cost and benefit levels.
Assumes:
Assumes:
This gives executives a much better understanding of the investment range.
One of the most commonly missed elements is the cost of waiting.
Delaying an S/4HANA programme can have both positive and negative effects.
Potential benefits of delay:
Potential costs:
For UK organisations on SAP ERP 6.0 EHP6–8, maintenance timing is another factor to incorporate into this analysis. SAP's current strategy provides mainstream maintenance through 2027 and optional extended maintenance through 2030.
The relevant comparison is therefore not simply migrate versus do not migrate, but how the economics change when the transformation takes place at different points in time.
Executives are more likely to trust a business case when they can see the alternatives.
Consider at least four scenarios.
Minimal transformation.
Pros:
Cons:
Targeted technical and process improvements.
Pros:
Cons:
Modernise while retaining significant existing configuration.
Pros:
Cons:
Build a new target architecture.
Pros:
Cons:
The right comparison depends on the organisation's starting point, business requirements, technical landscape, and transformation objectives.
The business case should provide the baseline for measuring value after implementation.
Choose KPIs from several relevant categories.
The KPI set should remain focused on the outcomes defined in the business case rather than becoming a generic reporting dashboard.
The business case should continue to guide the programme after approval and go-live.
Each expected benefit should have:
For example:
| Benefit | Owner | Baseline | Target | Measurement |
| Financial close | CFO / Finance | 10 days | 7 days | Close calendar |
| Manual AP effort | Finance Ops | 100% baseline | -25% | FTE / hours |
| Interface incidents | IT | 200 / quarter | <100 | Service management |
| Duplicate vendors | Procurement | 4,500 | <500 | Master-data report |
| Support cost | CIO | £X | £Y | Annual operating cost |
| User adoption | Business | 0% | >90% | Usage data |
This turns the business case from an approval document into a framework for measuring whether the expected value is actually being delivered.
One of the costs most often underestimated is the period when the organisation is running the existing SAP environment while building and deploying S/4HANA.
For large UK enterprises, the transition can create temporary costs such as:
These costs can be material even when the target S/4HANA operating model is expected to be more efficient.
The business case should therefore distinguish between:
Current-State Operations + Transformation and Transition Costs + Target-State Operations
rather than comparing only current and future run costs.
Suppose a business normally spends £4m per year operating SAP.
During a two-year transformation, it may additionally require:
£1.2m annual transformation and transition costs
while still paying most of the existing operating cost.
Those costs do not necessarily indicate that the programme is inefficient.
They are part of the economic reality of the transition.
Create a detailed transition cost curve showing:
This gives decision-makers a clearer view of cash requirements and the timing of payback.
Once the analysis is complete, the board-ready business case should bring the findings together in a concise decision document.
The earlier sections provide the analysis; this section should bring it together into a format that supports an investment decision.
The business-case process can be summarised as:
Assess → Quantify → Compare → Model → Validate → Approve → Measure
Understand the current SAP and business environment.
Measure costs, inefficiencies, technical debt, and business impact.
Evaluate realistic alternatives.
Build financial scenarios and benefits.
Test assumptions with finance, business, IT, SAP specialists, and implementation partners.
Present the investment case to the appropriate governance body.
Track benefits against the baseline after implementation.
The important point is that these stages build on one another. The assessment establishes the baseline, the baseline supports the financial model, and the approved business case becomes the basis for benefits realisation.
For UK organisations still operating SAP ERP 6.0, the timing of business-case development should reflect the actual system release and maintenance position.
SAP's current strategy provides mainstream maintenance for EHP6–8 of SAP ERP 6.0 through 31 December 2027, followed by optional extended maintenance through 31 December 2030. SAP's S/4HANA innovation commitment runs through 2040.
For a UK enterprise, the practical sequence is:
Document:
Establish:
Compare:
Stay → Optimise → Transform
Establish:
Model:
Connect the investment decision to:
This creates a decision framework that connects the current ERP position with the future transformation, rather than treating the business case as simply an implementation budget.
“Real-time analytics”, “AI”, and “cloud” are capabilities.
They are not automatically business benefits. The business case should explain what measurable business outcome each capability is expected to support.
Without current-state data, projected savings are difficult to validate.
Legacy support and technical debt are real costs.
Strategic benefits should be clearly distinguished from direct financial savings.
Training, business participation, testing, and organisational change require real investment.
Dual running, backfill, temporary infrastructure, and hypercare can materially affect the financial model.
A credible case should also consider optimising the existing SAP landscape where appropriate.
Published customer results are not guarantees.
Business value needs to be tracked after the system is operational.
Maintenance deadlines matter, but the investment should be connected to the organisation's broader strategy.
Before seeking final approval, confirm:
The quality of an SAP S/4HANA business case depends on how accurately the organisation understands its current landscape, transformation requirements, costs, and expected benefits.
LeverX can support UK enterprises across the assessment and planning stage and, where required, continue through S/4HANA implementation and optimisation.
|
Business case area |
How LeverX can support |
|
Current-State Assessment |
Review the existing SAP landscape, processes, customisations, integrations, data, and key pain points |
|
S/4HANA Readiness |
Assess technical, functional, data, integration, and organisational readiness for S/4HANA |
|
Business-Case Development |
Define transformation scenarios, investment requirements, expected outcomes, risks, and key assumptions |
|
Target Architecture |
Develop the target SAP architecture, application landscape, integration model, and deployment approach |
|
Migration Strategy |
Evaluate Brownfield, Greenfield, and Selective Data Transition options based on the current landscape and transformation objectives |
|
Process Analysis |
Identify process inefficiencies, standardisation opportunities, and areas for business-process redesign |
|
Data & Integration Assessment |
Evaluate data quality, migration requirements, interfaces, dependencies, and legacy-system complexity |
|
Cost & TCO Modelling |
Estimate implementation, migration, integration, licensing, support, and longer-term operating costs |
|
Benefits & KPI Definition |
Establish measurable business outcomes and KPIs for the transformation programme |
|
Implementation Planning |
Define scope, phases, dependencies, resources, governance, timeline, and initial roadmap |
|
S/4HANA Transformation |
Support the programme through implementation, migration, integration, testing, go-live, and optimisation |
|
Post-Go-Live Optimisation |
Continue improving processes, integrations, data quality, performance, and SAP capabilities after deployment |
Building a business case for SAP S/4HANA migration is not about proving that S/4HANA has more capabilities than the current ERP.
It is about demonstrating that changing the ERP creates enough strategic, operational, financial, and risk-adjusted value to justify the investment.
For UK enterprises, this means bringing together the current-state baseline, cost of staying, future business requirements, migration options, investment, quantified benefits, transition costs, risks, and benefits realisation.
The maintenance timeline can create urgency for organisations still running relevant SAP ERP 6.0 releases, with mainstream maintenance for EHP6–8 ending on 31 December 2027 and optional extended maintenance available through 31 December 2030. But urgency should support the business case rather than replace it.
The key question is not simply:
“Do we need S/4HANA?”
It is:
“What are our realistic options, what will each option cost, what value can each create, and how should we manage the associated risks and timing?”
Answering these questions gives decision-makers a clearer basis for evaluating the transformation and creates a framework for measuring whether the expected value is delivered after go-live.
Because an S/4HANA transformation requires significant investment and organisational change. The business case provides a structured way to evaluate strategic benefits, costs, risks, alternatives, and expected returns.
At minimum: current-state assessment, strategic objectives, migration options, target state, investment costs, benefits, TCO, financial analysis, risks, implementation roadmap, transition costs, and benefits-realisation KPIs.
A basic formula is:
ROI = (Total Benefits − Total Investment) ÷ Total Investment × 100
For larger programmes, also consider NPV, payback period, IRR, TCO, and sensitivity analysis.
Separate benefits into:
Cost Reduction + Operational Efficiency + Risk Reduction + Growth Enablement + Strategic Value
This prevents strategic benefits from being incorrectly presented as guaranteed financial savings.
Include current infrastructure, support, maintenance, custom development, integrations, security, specialist resources, technical debt, and any applicable future maintenance costs.
For SAP ERP 6.0 EHP6–8, SAP currently states that mainstream maintenance ends on 31 December 2027, with optional extended maintenance through 31 December 2030.
Yes, where they apply to the organisation's actual SAP release and commercial situation. However, maintenance should be treated as one business driver rather than the sole reason for transformation.
There is no universal figure. Cost depends on the source system, migration approach, custom code, data, integrations, business-process scope, deployment model, testing, and organisational change.
Yes. If the organisation will operate the existing environment while building or rolling out S/4HANA, the business case should include temporary support, infrastructure, project backfill, parallel testing, hypercare, and other transition costs.
There is no universal payback period. It should be calculated from the organisation's actual investment, benefits, implementation timing, and ramp-up assumptions rather than using a generic benchmark.
They should be included in the overall business case, but not necessarily converted into artificial financial savings. Strategic benefits can be tracked using operational or business KPIs.
At minimum:
Stay on Current SAP + Optimise Existing SAP + S/4HANA Transformation
Where realistic, also compare different S/4HANA transition approaches such as system conversion, selective data transition, and new implementation.
Each benefit should have an owner, baseline, target, measurement method, and target date. This turns the business case into a benefits-realisation framework rather than a document used only to obtain approval.
Disclaimer: SAP product capabilities, maintenance timelines, deployment options, licensing, migration approaches, and technical requirements may change by product edition, release, configuration, and customer scenario. Any financial models, ROI calculations, benefit assumptions, or business outcomes should be based on the organisation's own baseline and validated assumptions. This article provides general information and should not be treated as a financial, procurement, or migration recommendation.