What technology modernization actually costs, and why the quote is always wrong

The board approved a number. The number was the license or subscription figure on the vendor proposal. It was not the cost of the program, it was the cost of the software, and those are different things by a wide margin. The gap between them is where modernization budgets go to die, and it is almost always discovered after the money is committed and the alternative options are gone.

This is part two of a six-part series on technology modernization for executives. Part one covered how to tell whether you actually need to modernize. This part assumes you have decided you do, and answers the question the board should be asking next: what does this really cost, and why is the quote in front of me wrong before I have even read it.

The quote is optimistic by design, not by dishonesty

It is tempting to read an under-scoped quote as a vendor being deceptive. It is usually simpler than that. The vendor is pricing the thing they sell, which is the software. They are not pricing your data, your integrations, your people's time, or your organization's capacity to absorb change, because those are not theirs to price and including them would make their number lose to a competitor who excluded them. Every vendor in the process is under the same pressure, so every quote in the process is optimistic in the same direction. The structural incentive guarantees it.

This means the error is predictable, which is good news. A predictable error can be corrected before the number reaches the board.

The cost categories the quote leaves out

The license figure is the visible tip. The costs that decide whether the program lands on budget sit underneath it, in five categories.

1. Data migration. Moving your data into the new system is almost never a clean export and import. The data is inconsistent, incomplete in the places nobody checked, and structured for the old system's assumptions. Cleaning and mapping it is frequently the single largest line in the real budget, and it is the line the quote is least likely to mention.

2. Integration. The new system has to talk to everything else you run. Each connection is a small project with its own testing and failure modes. If the new system replaces something that sat in the middle of many others, integration can cost more than the software.

3. Parallel running. For a period, often months, you run the old system and the new one at the same time, because turning the old one off before the new one is trusted is how businesses stop. You are paying for both, plus the people operating both.

4. Change management and internal time. Your own people spend hundreds of hours specifying, testing, training, and absorbing the new way of working. That time is real cost even though it never appears on a technology invoice, because those people are not doing their normal jobs while they do this.

5. The second year. The first year gets attention and budget. The second year is when the workarounds you built to go live have to be removed, the things deferred to "phase two" come due, and the support contract steps up. Programs that looked on budget at go-live often are not, and nobody is looking by then.

A working rule for the board number

I do not give precise multipliers, because the honest answer depends on how much sits in those five categories for your specific environment, and anyone who gives you a clean multiple without asking is selling something. But the directionally correct statement, the one worth saying out loud in the room, is this: the license figure is frequently a minority of the total program cost once data, integration, parallel running, internal time, and year two are included. Treat the vendor number as the floor of one category, not the ceiling of the program.

How to read a quote before it goes to the board

You can pressure-test a quote without being technical. Ask the vendor, in writing, to state explicitly what is excluded. Not what is included, what is excluded. The exclusions list is where the truth is, and a vendor who will not produce one is telling you something. Then ask your own operating leaders, separately from the vendor, three questions: how messy is the data we would be moving, how many other systems would this need to connect to, and how many of our own people's hours does this consume over eighteen months. Those three answers, multiplied through, are usually closer to the real number than the proposal is.

The cost you already named in part one

There is one more number that belongs in this comparison, and most boards never put it on the page: the cost of doing nothing. In part one I argued that doing nothing is a legitimate option with a real cost, and that you cannot judge modernization without naming it. The same discipline applies here. A program that looks expensive against zero often looks rational against the true, named cost of leaving the current system in place for three more years. The mistake is comparing the full, honest cost of modernizing against an unstated, assumed-to-be-free cost of standing still. Both numbers have to be honest, or neither comparison means anything.

If you want a fast, vendor-independent read on what a modernization program would actually cost you across all five categories before it reaches your board, that is a conversation I have with finance and operating leaders directly.

This is part two of a six-part series. Part three covers the decision that comes once the budget is real: build it, buy it, or leave it alone.