🇪🇸 Leer en español →
ROI Estratégico 24 de May de 2026 6 min 59 reads

The Cost of Not Migrating Your ERP: NPV, Discount Rate and the Scenario Nobody Models

Most ERP migration business cases compare the investment against zero. This article explains how to build the correct financial argument: NPV, discount rate and the real cost of staying with the current system.

Share this article: LinkedIn X

The operations manager knows before anyone else that the system is no longer up to the job. Processes that should be automatic are handled manually by someone. Integrations work, but only because one person knows exactly how to patch them when they fail. The reports the business needs come from Excel, not the ERP.

The problem is not technical. When the time comes to take it to the committee, the conversation narrows to one question: how much does it cost?

And that is where most projects die. The investment is rarely the real obstacle. The problem is that nobody has built the counter-argument: how much does it cost to do nothing?

This article proposes a way to answer that question with financial rigour.

The starting point: what NPV measures

Before discussing how to evaluate the project, it is worth being clear about the tool we are using.

NPV (Net Present Value) is the standard indicator in corporate finance for evaluating investment projects. It answers a specific question: taking into account the time value of money, how much value does this project generate?

The logic is straightforward: one euro of benefit three years from now is worth less than one euro today, because today you could invest it. NPV discounts all future project flows (investment, costs, benefits) to present value and sums the result. If it is positive, the project creates value. If it is negative, it destroys it.

The key lies in the rate at which those flows are discounted. That is the discount rate.

The discount rate: where it comes from and why it matters so much

The discount rate expresses the cost of capital: the minimum return the project must generate to make it worthwhile to commit resources to it for several years.

In the business cases I have reviewed, the discount rate tends to appear already fixed before anyone questions it: ten per cent, or the corporate WACC (Weighted Average Cost of Capital, which combines the cost of equity and the cost of debt according to the company's financial structure). It is copied without adjustment. (Some argue for simply using the WACC, and for very stable companies with projects that closely resemble their core business, that holds up. An ERP migration is a different animal.)

That figure reflects the risk of the company's normal operations. An ERP migration does not resemble normal operations. The benefits depend on system adoption, process redesign, and whether the project stays on schedule. That additional risk should appear in the rate.

How to build it correctly

The reference model in corporate finance is the CAPM (Capital Asset Pricing Model), which builds the cost of equity from three components. Before the formula, the intuition:

Minimum required return = what a safe asset yields + what you demand for taking on the risk of this project

Ke = Rf + β · (Rm − Rf)

Rf (risk-free rate). What a risk-free asset yields. The ten-year German Bund is used, around 2.5% at the start of 2025. It is the floor: no investment with risk should demand less than this.

Rm − Rf (market risk premium). The additional return that equities have historically offered over the risk-free asset. For Spain it sits between 6% and 6.5%, according to evidence documented by Professor Fernández at IESE.

β (sector beta). Adjusts that premium to the type of project. A beta of 1 equals average market risk. For enterprise software, Damodaran publishes values around 1.2 in his global sector tables.

Applying these figures: Ke = 2.5% + 1.2 · 6.2% ≈ 10%

To that you need to add a project-specific premium of between one and three percentage points to reflect the real execution risk: implementation delays, benefits that do not materialise on schedule, or simply low adoption once the system goes live. The result for a typical ERP migration should sit between 9% and 13%, not the 7% that comes from copying the corporate WACC without adjustment.

What changes in the numbers

A distribution company, 800 employees, a system implemented twelve years ago. Migration budget: 800,000 euros. Benefits grow progressively from 120,000 euros in year one to 250,000 euros in year seven, as the organisation adopts the new system.

Discount rateNPV at 7 yearsDiscounted payback
8%+€247,0005.1 years
11%+€112,0005.8 years
14%-€14,000> 7 years

The same project, the same flows. With a reasonable rate it creates value; with a slightly higher rate it destroys it. Choosing the right rate is not an administrative step: it shifts the result more than any other assumption in the model, and it is the one most rarely questioned in the room.

The scenario nobody models: the cost of staying put

This is the argument most frequently missing from migration business cases.

When the committee asks how much the project costs, it compares the investment against zero. As if keeping the current system were free. But that system has a cost that grows every year: maintenance with annual price escalations, integrations that someone maintains by hand, auxiliary licences that cover what the ERP does not do, working hours spent on processes that a more mature system would automate.

The correct formulation does not compare the investment against zero. It compares it against the accumulated cost of doing nothing:

NPV = −Investment + Σ (Benefits of new system + Avoided current system costs) / (1 + r)ⁿ

The avoided current system costs are real, verifiable positive cash flows (not estimates) that almost never appear in the model. Ignoring them undervalues the project, and not by a small margin.

And they have a direct effect on the discount rate. When part of the benefits are costs that stop being paid (maintenance, licences, integrations), the model's uncertainty falls. Less uncertainty justifies a lower risk premium and therefore a lower rate. Migration projects towards more mature systems have a better NPV than standard models show. The problem is that they are almost never built with the correct alternative scenario.

Conclusion

The operations manager who knows they need to change systems is right. The problem is that taking that conviction to a committee requires a different language: cash flows, discount rate, NPV.

Building that argument is not complex, but it requires two things that are rarely done together: choosing the discount rate with rigour (not copying it) and modelling the alternative scenario correctly. Staying with the current system is not free. Putting a number on that cost tends to be the hardest part of the business case to defend, and the one that most changes the final result.

References

SUBSCRIBE & FOLLOW

Interested in the financial evaluation of technology projects?

This article is part of a series on Corporate Finance methodologies applied to digital transformation. Follow the project via RSS, connect on LinkedIn for daily insights, or explore related articles below.

Á

Ángel Carlos del Pozo Muela

Executive MBA · Corporate Finance applied to ERP projects

Business development in the tech sector. Writes about applying Corporate Finance to ERP project evaluation.

Disclaimer

Las opiniones expresadas en este artículo son personales y no representan necesariamente la posición de ninguna organización con la que el autor esté relacionado.

Last updated: 24 de May de 2026

Related articles