How much does legacy software really cost: the hidden costs nobody calculates and how to build the modernization business case

The cost of legacy software is decided in a twenty-minute meeting, and almost always on the wrong numbers.

The finance director of a manufacturing company asks the CTO what IT will cost next year.

The answer: "the management system we have used since 2005 costs us €200,000 a year in maintenance."

The CFO makes a note, compares it with the €400,000 estimated for a new system, and closes the topic: "better to keep what we have, it is already written off."

Two years later that system is hit by ransomware (malicious software that locks or encrypts data and demands a payment) exploiting a vulnerability for which no fix exists.

The bill for the incident: €380,000 in recovery, production downtime and consultants.

On top of the €400,000 of maintenance that was paid regularly in the meantime, month after month, without anyone questioning it.

Nobody in that room was careless or incompetent.

One thing was missing: a method for calculating the real cost.

What the CFO sees in the budget is the tip of the iceberg, and it is not the tip that sinks a ship: it is everything that stays hidden below the surface.

The cost of legacy software is not the "IT maintenance" line in the budget. It is the sum of maintenance, inefficiencies, missed opportunities, security and compliance risks, and the cost of staff turnover.

Here you will find a real case with the books open, the costs that show up in the budget and those that never make it there, the formula for calculating your own number, the cost of regulatory risk, the comparison between modernizing and replacing, and the structure of the business case to take to the board.

A company spending €200,000 a year on software from 2005: the real case

A manufacturing company, 180 employees, €35 million in revenue.

Its management system was custom built in 2005 with ASP.NET WebForms on SQL Server 2008, and it runs orders, production, warehouse and invoicing.

There is no backup ERP: that software is the operating system of the company.

The real cost of that system is not €200,000 a year: it is about €507,000.

The difference is not a forgotten line item, it lies in two categories of cost that nobody had ever put on a spreadsheet.

The direct costs add up, and they are exactly what was declared: €145,000 for software maintenance, €28,000 for SQL Server and Windows Server licenses, €15,000 for running the servers in the server room, €12,000 for backup and recovery, with an outdated solution that nobody has ever really tried to restore from.

A total of €200,000.

Up to here the accounts and the perception match, which is why the discussion usually stops here.

Then you look at what people do all day.

Each user loses an average of 45 minutes a day on manual operations needed to work around the limits of the system: manual exports to Excel, data entered twice in two different places, waiting for slow processing.

That is 40 users at an average company cost of €30 an hour.

Forty users times three quarters of an hour times 230 working days times €30 gives €207,000 a year.

On its own, this item exceeds the entire declared IT budget, and it appears in no financial statement because those hours are already paid as salaries.

One last category is missing, the one the CEO grasps immediately.

The system does not integrate with the e-commerce platform the sales team has been asking for over three years, it does not talk to the supplier portal the purchasing department wants, and it does not feed the real-time reporting that management needs.

The value of these three blocked initiatives, estimated prudently, is between €80,000 and €120,000 a year in revenue that never arrives.

Two hundred thousand in direct costs, 207,000 in inefficiencies, 100,000 in missed opportunities: €507,000 a year.

Against a modernization of €400,000 that pays for itself in under twelve months.

The number that led to the wrong decision was not false: it was just the smallest of the three.

The visible costs of legacy software: what shows up in the IT budget

Before diving underwater it is worth looking closely at the part above the surface, because even there the numbers are almost always higher than they appear.

The visible costs of legacy software are four, and they tend to be underestimated not because anyone lies, but because they are scattered across different budget lines that nobody ever adds up: maintenance, licenses, physical infrastructure and user support.

Corrective and evolutionary maintenance

This is the main item, and it is the one that grows on its own.

It grows for two reasons that add up.

The first is the system.

Every year it accumulates quick fixes, workarounds and undocumented changes, and each layer makes the next one harder.

What was a three-day job in 2015 takes two weeks in 2025 to do exactly the same thing.

Nobody notices in a single intervention: you only see it by comparing two quotes ten years apart.

The second is the market.

Someone who knows 2005-era WebForms well does not cost the same as a modern .NET developer, because they are rare and they know it.

The case we started from shows it in plain numbers: maintenance alone is worth €145,000 of the €200,000 in direct costs, or 72%, and licenses, servers and recovery take the rest.

Nothing is left over to build anything new.

In companies with very old systems the proportion is worse, and the consequence is that innovation is not postponed by choice: there is simply no budget.

Software licenses and infrastructure

Legacy systems are tied to specific versions: Windows Server 2012 or 2016 because newer ones might not be compatible, outdated SQL Server versions, third-party commercial components that keep asking for the annual renewal even though the vendor has abandoned them.

There is a detail worth facing squarely: these costs go up, not down.

Anyone selling maintenance on legacy products knows perfectly well that the customer cannot leave, and the price lists reflect it.

Hardware and physical infrastructure

Old systems often demand specific hardware: servers in the server room with particular characteristics, control cards, dedicated backup systems.

Space, power, cooling and physical maintenance have a cost that almost never ends up under the "legacy software" line of the budget, even though it is part of the cost.

And there is one bill that arrives all at once: when that hardware reaches end of life, replacing it to run software that does not work on modern machines is a major expense that nobody planned for.

Support and training

Supporting the users of a legacy system costs more than supporting them on a modern one, for two simple reasons: the interface was designed to the standards of fifteen years ago, and the documentation is incomplete or out of date.

On systems with more than fifty users, internal support and training of new hires easily add up to between €20,000 and €40,000 a year.

Added together, these four costs produce a number that looks high.

The problem is that it is still the wrong one, because it is the total of the visible part only.

Two hundred thousand euros of direct costs already looked like an honest number, before discovering that user inefficiencies weigh almost as much and that missed opportunities triple the real bill.

Seeing it written in an article is one thing, recalculating it on your own system with your own numbers is another exercise, and almost nobody does it well alone the first time.

On the course we work on this too: reading an existing system and turning those numbers into a decision that holds up in front of the board.

The invisible costs nobody calculates: the real weight of legacy software

A CFO once told me a sentence that sums it all up: "if it is not on an invoice, it does not exist for me."

It is a reasonable criterion in accounting and a disastrous one here, because the costs that sink companies never come with an invoice.

The invisible costs of legacy software are four and none of them appears in the budget: the time users lose, the business opportunities the system does not allow you to seize, the turnover of technical staff, and the interest that technical debt accrues every month.

The cost of time lost by users

It is almost always the biggest, and it is the one that surprises management most the first time someone really calculates it.

The mechanism is trivial.

The salesperson exports data to Excel to run an analysis the system cannot do.

The warehouse manager enters the same data into two systems because they do not talk to each other.

The financial controller waits twenty minutes for a report that a modern system produces in thirty seconds.

None of these people complain, because they have worked like this for eight years and have stopped seeing it as a problem: it is simply "how we work here."

The method for measuring it is within anyone's reach.

Take the ten heaviest users of the system and ask them to note down, for one week, every workaround, every wait, every manual step.

Then multiply the average daily time by the total number of users, by the average hourly company cost, by the working days in the year.

The result, almost always, cannot go into a slide without changing the expression of whoever looks at it.

The cost of business opportunities not captured

Every request the system cannot support is a cost, even if nobody writes it down.

It is the hardest to quantify precisely, and also the easiest to list: all you have to do is ask.

Integration with modern e-commerce platforms is impossible, and the digital channel stays closed.

Giving customers real-time data is impossible, and you lose contracts with those who want visibility over the supply chain.

Handling seasonal peaks is impossible, and in periods of high demand you sell less than the market would buy.

Feeding serious analytics tools is impossible, and decisions are made on partial data.

The cost of turnover in the technical team

Developers do not want to work on legacy systems, and it is not a whim: it is a rational career choice.

Someone who spends three years on 2005-era WebForms is not building skills the market pays for, and they know it perfectly well.

The result is higher than average turnover, and every person who leaves takes away knowledge that is written down nowhere.

Replacing an experienced developer, counting search, onboarding and the time needed to reach full productivity, costs between €30,000 and €60,000: it is one of the items that push up the cost of the development team.

If the team maintaining the system has five people and loses two a year, that is €60,000 to €120,000 a year, without counting the worst risk: not finding anyone who can do the job.

The cost of accumulated technical debt

Technical debt pays interest, exactly like financial debt, and the difference is that nobody sends you the statement.

Every workaround, every undocumented quick fix, every outdated component increases complexity and reduces the speed at which the team can change anything.

The effect is not linear: a system with medium technical debt takes twice as long for the same changes as an equivalent modern one, and one with high debt takes three times as long or more.

The point here is a different one: how much technical debt weighs on the annual bill while it stays where it is, not how to measure it or how to pay it down.

It is a cost you pay every single day, in the form of features that arrive late.

Four items without an invoice.

The good news is that all four can be calculated, and the calculation takes half a day of work.

How to calculate the real cost of your legacy software: the practical formula

The number you need is not a consultant's estimate: it is a sum of four terms that you can put together yourself, with data you already have in the company.

The total annual cost of legacy software is calculated by adding four components: direct costs, user inefficiencies, missed opportunities and the cost of risk.

The difficulty is not the mathematics, it is the honesty with which the data is collected.

Component 1: Annual direct costs (CD)

They are the sum of: the cost of the staff dedicated to maintenance, that is annual hours times hourly cost, external consultants included; annual licenses for all the software needed to run it; infrastructure, meaning hardware, hosting, power and backup; vendor support, where it still exists.

Or, in a more compact form:

C₍direct₎ = (H × Cₕ) + Cₑ + L + I + S

where:

• H = annual hours spent on maintenance
• Cₕ = hourly cost of staff
• Cₑ = annual cost of external consultants
• L = annual licenses
• I = annual infrastructure: hardware, hosting, power, backup
• S = annual vendor support

The data sits in IT accounting, in license contracts and in consulting invoices.

It is the easiest piece, and also the only one anyone looks at today.

Component 2: Cost of user inefficiencies (CI)

The formula is: number of users times hours lost per day times working days times average hourly cost.

Cᵢ = U × H × D × Cₕ

where:

• Cᵢ = annual cost of inefficiencies
• U = number of users
• H = hours lost per day
• D = working days per year
• Cₕ = average hourly cost

The only data to collect is the hours lost, and the most reliable way is a structured questionnaire asking users to estimate how much time they spend each day doing by hand things the system does not do, waiting for slow processing, reconciling data between different systems, and fixing the system's output to make it usable.

On old legacy systems, an honest estimate almost always falls between 30 minutes and 2 hours a day per person.

Component 3: Cost of missed opportunities (CO)

It is the hardest figure to quantify and the one with the biggest impact, so it is worth spending half an hour to do it well.

Ask management to list the top three things the business has asked for in the last two years that the system could not support.

For each one, estimate the value: additional revenue, operating costs saved, customers who would not have left.

Then take the lowest of the estimated values, because a conservative number that nobody can challenge is worth more than an optimistic one that someone demolishes in the meeting.

You can express it like this:

Cₒ = min(V₁, V₂, V₃)

where:

• Cₒ = annual cost of lost opportunities
• V₁, V₂, V₃ = estimated economic value of the three main opportunities the legacy system has prevented

Each value V can include, depending on the case:

V = additional revenue + operating costs avoided + value of customers retained

Component 4: Cost of risk (CR)

The formula is: annual probability of an incident times the average cost of the incident, plus the probability of a penalty times the expected average penalty.

That is:

Cᵣ = (Pᵢ × Cᵢ) + (Pₚ × Fₘ)

where:

• Cᵣ = expected annual cost of risk
• Pᵢ = annual probability of an incident
• Cᵢ = average cost of an incident
• Pₚ = probability of a penalty
• Fₘ = expected average penalty

To estimate the probability of a security incident, look at three verifiable things: the age of the dependencies, the presence of known CVEs (publicly catalogued vulnerabilities) with no available fix, and how often security updates were applied over the last three years.

A public probability calculated on the age of dependencies does not exist: the Clusit Report, the annual Italian cybersecurity report, counts the incidents detected, not the state of the software of those who suffer them.

What Clusit 2025 does say, and what your estimate needs, is that in Italy the exploitation of vulnerabilities reached an all-time high, up 90% between 2023 and 2024, and that manufacturing is the second most targeted sector.

On the systems I have seen, with dependencies older than 2015 and no recent security updates, I use an annual probability between 15% and 25%.

It is my own estimate and it should be presented as such: in front of a board a declared estimate holds up, a wrong source does not.

The total cost and the comparison with modernization

The total annual cost is the sum of the four components (Cₜ = C_d + C_i + C_o + C_r)

Before adding them up, it helps to see them side by side, because each one comes from a different source:

It must be compared with the annualized cost of modernization: a €300,000 modernization over two years is worth €150,000 a year.

If the total cost of the legacy system exceeds that €150,000, the modernization pays for itself in the first year.

If it is lower, it still pays for itself in two or three years thanks to the costs that disappear afterwards.

What is interesting is something else: when I saw this calculation being done, management was not convinced because the number was big.

They were convinced because it was the first time anyone had shown them the whole number.

And there is a fourth term that deserves to be opened on its own, because in 2026 it has changed in nature.

The cost of risk: security, compliance and GDPR

It is the item management ignores most willingly, for an understandable psychological reason: nothing has happened yet.

As long as nothing happens, it feels like theory.

The risk of a legacy system is not a hypothesis but a function of time: it grows every month on its own, without anyone doing anything, because every new vulnerability discovered in an abandoned dependency stays open forever.

Security vulnerabilities nobody will fix

When a library, a framework or an operating system goes out of support, the vulnerabilities discovered after that date will never be fixed.

It is not a question of the vendor's priorities: nobody will ever fix them.

The CVE database holds documented vulnerabilities for .NET Framework 3.5, SQL Server 2008, Windows Server 2008 and IIS 7, all technologies still alive in plenty of production systems.

Whoever looks for them finds them, and it is a job that takes less skill than running those systems.

The consequences have known prices.

Ransomware with a complete operational shutdown costs a small or medium-sized business between €50,000 and €300,000 to recover from.

A data breach brings the duty to notify the data protection authority and the possibility of a fine.

Reputational damage has no price list, but the customers who notice it do.

The cost of a serious incident almost always exceeds the cost of the modernization that would have prevented it.

GDPR risks specific to legacy software

The GDPR demands four capabilities that systems from 2008 to 2012 almost never have: deleting all of a person's data on request, completely and provably; exporting it in a standard format; tracking in detail what that person consented to, when and under which version of the privacy notice; and recording who accessed which data, when and why.

A system that does not do these four things is not just old: it is potentially non-compliant, with fines that for a medium-sized company can reach hundreds of thousands of euros.

Italy's data protection authority, the Garante, has stepped up its inspections in recent years, and fines have reached small and medium-sized businesses too.

NIS2 risks: the directive many smaller companies have not yet considered

Here is the news that changes the conversation, and the one that in 2026 is setting off alarms in the wrong meetings.

The NIS2 directive, in force since 2024, extends cybersecurity requirements to a much larger number of companies than before, including manufacturing, food distribution and digital services.

Companies in scope must demonstrate adequate technical and organizational measures on their systems, legacy ones included.

A system with known, unfixable vulnerabilities is, by definition, non-compliant.

Penalties can reach 2% of annual global turnover for important entities and up to €10 million in the most serious cases.

But the point that really moves decisions is another one, and it is worth saying calmly in the meeting: the directive provides for the personal liability of company leadership for documented security failings.

It is no longer IT asking for budget: it is the chief executive who signs.

The personal liability of leadership introduced by NIS2 changes the conversation, because it is no longer just a problem IT can push to the next budget.

Knowing whether your own system really falls within that risk requires a competent technical reading, not just a list of warning signs.

It is the kind of assessment we tackle together with those who take the course, applied to the real system they bring to class.

When legacy software holds back business growth

So far we have talked about money going out.

There is a category of cost that a CEO understands faster than any other, and it is the money that does not come in.

Legacy software stops being a maintenance problem and becomes a strategic limit when it prevents the company from doing three things: integrating with others, growing in volume and deciding quickly.

The trap of impossible integration

The 2026 market is made of integrations.

Selling on a marketplace requires the management system to talk to its APIs.

Using serious analytics tools requires operational data to come out in real time.

Opening a customer portal requires APIs that the legacy system has never exposed.

Systems built between 2005 and 2012 were not designed for this world.

They expose data through SQL stored procedures, CSV files or proprietary interfaces, and every integration requires an expensive and fragile adaptation that adds a layer of complexity, making the next integration more expensive too.

The result is measured in weeks.

A competitor that has modernized implements a new integration in two to four weeks.

The same integration on the legacy system takes three to six months and costs three to five times as much.

Repeated for five integrations over three years, this gap becomes a strategic delay that costs far more than the modernization.

The scalability block

Legacy systems are not designed to grow.

When transactions, users and process complexity increase, the system's response is to degrade.

And the usual countermeasures are all treatments of the symptoms: more powerful hardware, which costs money and delivers less and less; database tuning, which works for a few months; features switched off to lighten the load, which is the moment the company starts working worse to let the software breathe.

None of the three touches the problem, which is architectural.

The cost of slow decisions

Data comes out in formats that are hard to analyze and arrives late.

The sales manager who wants to know which customers reduced their orders in the last quarter has to wait for someone to export, clean up in Excel and assemble a report: hours or days, not seconds.

Every decision that depends on that data has a built-in delay.

In a market where speed of response is a competitive advantage, that delay is a cost, even if you will never see it on an invoice.

Modernization vs replacement: which approach pays off

Once it is established that the system must be dealt with, the question arrives on which boards split: do we modernize it, or throw it away and buy a new one?

There is no universal answer, but there is a criterion that almost always works: you modernize when the business logic is specific and valuable, you replace when it is standard and the technical debt is already out of control.

When modernizing pays off

Modernizing means keeping the business logic and changing the technology underneath.

It pays off when the system implements complex, specific processes that no commercial product covers.

If your software handles production, pricing or supply chain logic that is unique to your sector or your way of working, that logic has real value, often built over twenty years of adjustments made by people who are no longer there.

Rewriting it from scratch is expensive and risky, because inside it sits knowledge that nobody ever wrote in a document.

Modernizing also pays off when the budget cannot support a replacement in one go: the incremental approach, the famous strangler fig, among the patterns of legacy software modernization, lets you migrate piece by piece while keeping the system in production and spreading the spending over time.

When replacement pays off

Replacing with a commercial product, ERP, CRM or vertical platform, pays off when the system does standard things the product covers well, when the technical debt is such that modernizing costs more than replacing, and when the product offers features the legacy system can never have.

There is, however, a figure worth looking at before signing, and one that ERP vendors leave out of their presentations: ERP implementation projects overrun budget or schedule in 60-70% of cases, according to the Panorama Consulting ERP Report 2025.

Adapting business processes to the product, migrating data and training users almost always costs more than what is written in the quote.

The practical assessment: three questions to decide

Three questions, in this order, guide the choice without the need for a consultant.

1. Is the business logic standard or specific? If it is standard, a commercial product covers it.
2. What is the real technical debt? An external technical assessment tells you whether it is worth saving or starting over.
3. Can the budget support a complete replacement, or do you need to proceed in stages? If it is limited, incremental modernization is almost always the prudent choice.

Once you have decided how, what remains is the part where projects die before they are born: convincing the people who sign.

The business case for management: how to present it

I have seen impeccable analyses die in twelve minutes.

Not because of the numbers: because of the language.

"We need to update the technology" is not a business case, it is a request for trust.

The case we started from can be presented in three lines: an ASP.NET WebForms management system on SQL Server 2008 that costs €507,000 a year all in, €400,000 one-off to move it to .NET 10 with a web interface, payback within twelve months.

The board does not have to understand a technology: it has to compare two numbers and a date.

It is the same leap that separates those who treat software as an asset from those who treat it as a cost, and in the boardroom it changes who asks the questions.

Five sections, in this order.

The structure of a winning business case

The first section is the current cost of the problem, with the four components calculated and laid out one under the other.

It is the strongest moment of the whole presentation, because management sees for the first time the difference between the budget line and the real cost.

No emphasis is needed: the sum is enough.

The second is the projection with no intervention, and it is the one that moves decisions.

Maintenance grows by 5-10% a year because developers become rarer, dependencies older and hardware has to be replaced.

Security risk goes up.

Blocked opportunities pile up.

Project the cumulative cost over five years and let the chart speak.

The third is the cost of the project, and this is where credibility is won or lost.

A clear methodology on how the numbers were calculated, a contingency margin of 20% declared openly, realistic timelines with verifiable milestones and a risk management plan.

Never present the optimistic estimate: when management discovers an overrun halfway through the project, they do not lose faith in the project, they lose it in you.

The fourth is the return year by year in the five years after completion: reduced maintenance, reduced inefficiencies, unlocked opportunities, risk valued as a cost avoided.

With inside it the number everyone is waiting for, which is the moment the investment has paid for itself.

In most real cases on old systems, payback sits between 18 and 36 months.

The fifth is the risk of doing nothing, and it is the one to handle with the most care, because a single word too many is enough to make it sound like scaremongering.

Present it with data: documented cases of similar companies, even without names but with real numbers; an estimate of the probability of an incident in the next three years based on verifiable factors; concrete consequences in hours of downtime, recovery cost and possible penalties.

The signs your legacy software has reached breaking point

Not every old system is urgent, and it is worth saying so, because whoever treats every old system as an emergency loses credibility when the emergency is real.

Breaking point is recognized from three families of signs, in decreasing order of severity: risk signs, which call for action now; operational signs, which say the system costs you more than it delivers; and strategic signs, which say you are losing ground.

Signs of urgent risk

There are four, and one is enough to make the topic a priority this year.

The system has dependencies with known CVEs and no fix available, because whoever produced them has shut that product down.

The system does not meet regulatory requirements in force, GDPR or NIS2, and the exposure to penalties is real.

The system has had at least one security incident in the last twenty-four months, even a small one, and a small incident is the best predictor of a large one.

The vendor or the team that built it is no longer available for support.

Signs of operational risk

These do not put you outside the law, they eat your margin.

The annual maintenance cost exceeds 20% of the original development cost.

The time to release a new feature has grown by more than 50% over the last three years.

The team maintaining the system has had turnover above 40% in the last year.

The system can no longer handle the current operating volume, with degraded performance, frequent errors and emergency maintenance that has become routine.

The business has given up on at least three requested features in the last eighteen months.

Signs of strategic blockage

The last family is the quietest and the most expensive.

The company cannot integrate the system with the platforms its strategy requires.

Competitors with modern systems are releasing things you cannot release, and the distance grows every quarter.

The system cannot support the growth forecast for the next three years without disproportionate investment in infrastructure.

Two risk signs or three operational ones and modernization is urgent.

If while reading this list you have already recognized two or three signs in your own system, it is no coincidence: most companies with legacy software accumulate more of them than they thought at the start.

The hard part is not recognizing them, it is working out which to tackle first and with which approach.

It is what we do case by case on the course, starting from the system of the person attending.

How much does modernization really cost (and why it costs less than waiting)

At this point in the meeting the same question always arrives, and it must be answered with a number, not with an "it depends."

Modernizing a legacy system costs between €150,000 and over €2 million depending on size, but the number that decides is not that one: it is the comparison between that figure and the cumulative cost of five years of waiting.

Orders of magnitude for modernization

On projects in Italy, the verified orders of magnitude are three.

A small system, 20-30 screens, few users, relatively simple logic, sits between €150,000 and €300,000 over six to twelve months.

These are departmental applications or secondary systems.

A medium system, 50-100 screens, 30-100 users, moderately complex logic, sits between €300,000 and €700,000 over twelve to twenty-four months.

It is the most common case in manufacturing.

A large system, over a hundred screens and over a hundred users, with critical logic, runs from €700,000 to over €2 million over twenty-four to forty-eight months.

Here we are talking about platforms that are the heart of the business.

Three items are always added to these figures: 20% contingency for the unexpected; the cost of data migration, which on systems with a complex history is worth 10% to 20% of the total and is the most underestimated item of all; and the cost of the period in which the two systems run in parallel to check that they behave the same way.

If the system to migrate is in .NET, and in manufacturing it almost always is, the cost per screen and the timelines by type of application are in the .

The comparison that changes the decision

Take a €400,000 modernization for a medium system and spread it over five years: €80,000 a year.

Compare it with the total cost of the legacy system calculated earlier: if it is €300,000 a year, which is common on medium systems with more than fifty users, the project pays for itself in under two years and in the following three produces a net saving of €220,000 a year.

Over a five-year horizon after the modernization, that is €1,100,000 of savings against €400,000 of investment.

And this is the sentence to bring to the meeting, not the other one: not "modernization costs €400,000", but "not modernizing costs €1,100,000 more over the next five years."

The real cost of waiting

Every year of delay adds three costs.

The operating cost of the legacy system, which continues unchanged.

The increase in the cost of the future modernization, because the system becomes harder and more expensive to migrate every year.

And the increase in the probability of an incident, which grows with the age of the dependencies.

On almost all old systems, the cost of waiting one more year exceeds the cost of starting now.

The difference is that you pay the first anyway, while the second at least decides something.

The cost of legacy software you cannot see is the one that sinks you

The maintenance you see in the budget is real, but it is the part above the surface.

Underneath are the hours your users lose every day without complaining, the contracts you did not win because the system did not expose an API, the good people who left, and the risk that grows on its own while you read.

The method for calculating it does not require sophisticated tools.

It requires discipline in collecting the data, a user questionnaire, a review of licenses, a technical assessment of dependencies; honesty in valuing the items that are usually ignored; and the courage to bring the whole picture to management, without softening it so as not to frighten anyone.

Modernizing legacy software is not an IT expense: it is an investment with a measurable ROI, often higher than most of the alternative investments available. Management that understands this makes better decisions.

There is one thing, though, that the calculation does not give you, and it is the reason why some modernizations succeed and others become the second disaster after the legacy system.

You need people who can read an old system and understand which business rules are hidden inside it, who can choose what to keep and what to throw away, who can say no when someone proposes the shortcut that will cost six months later.

Those skills cannot be bought with the project: they are built beforehand, and in a company they either exist or they have to be trained.

So the question to close with is not whether to modernize.

It is a more uncomfortable one: do you really know how much your legacy software costs you?

Not the budget line, the whole cost.

If the answer is no, you already have the first thing to do this week, and it costs you half a day of work.

If the answer is yes, then the conversation with your management can finally happen on numbers and not on feelings.

Our modernization experts can guide you through a complete assessment of the cost of your system and the construction of a concrete business case, with real numbers and a workable path: not a generic presentation, but an analysis of your system, your team and your context.

The finance director of that opening meeting had not got the sums wrong: he had simply calculated the wrong thing, because nobody had ever shown him the whole number.

You, unlike him, now know where to look: in direct costs, in lost hours, in blocked opportunities and in the risk that grows on its own with every passing month.

The missing part is the same one that was missing for him, namely someone who can read a specific legacy system and help you turn it into a defensible decision, before it is a ransomware attack or a NIS2 inspection that decides it for you.

In the AI Software Architect Course we work on exactly this kind of system, with those who have to decide whether to modernize, how to do it and how to take it to the board with numbers that hold up.

A year from now, those who have done this work will be the ones who have already cut that €507,000 bill.

Those who waited will still be paying it.