Most legacy modernisation business cases die the same way. Somebody quotes an average breach cost from an industry report, a finance director notices that the average blends regulated giants with firms a fiftieth of their size, and the whole argument loses credibility in one sentence. Do not build your case that way.
You can construct an honest comparison without inventing a single figure. Modernisation costs are estimable because they are your costs. Incident costs are largely estimable for the same reason: your payroll, your downtime, your contracts, your excess. The genuine uncertainty is probability, and handling that openly makes the case stronger, not weaker.
Why somebody else's average breach cost is the wrong number
Because it is somebody else's average. Published breach cost figures mix industries, jurisdictions, data types, company sizes and insurance structures. Quoting one at your board invites an argument about methodology instead of a decision about your systems. Build the estimate from your own operational facts and the conversation changes completely.
- ▸Averages hide the shape of the distribution. Most incidents cost far less than the headline average and a few cost vastly more. Your exposure depends entirely on which tail you sit in, which an average cannot tell you.
- ▸Your finance team can verify your numbers. They cannot verify a report's methodology, so they will discount it, and rightly.
- ▸Cite sources for mechanisms, not amounts. Use CISA Stop Ransomware to explain how an extortion incident actually unfolds through remote access and backup destruction, then price your own downtime from your own revenue.
The real cost categories of a modernisation
Modernisation is never one number. Break it into six categories, estimate each from your team's rates and your own delivery history, and the total is usually less alarming than the round figure someone guessed in a meeting. It is also defensible line by line.
- ▸Discovery and inventory. Mapping what exists, what talks to what, what is internet-facing and what nobody can explain. Cheap, fast, and the phase that prevents the expensive surprises.
- ▸Rebuild or replatform engineering. The headline cost, and the one most sensitive to scope discipline.
- ▸Data migration and reconciliation. Routinely underestimated. Budget for extraction, cleaning, mapping, a reconciliation process and at least one full rehearsal.
- ▸Parallel running. Two systems, two sets of licences, two support burdens, for a defined period. Short parallel runs are expensive. Open-ended ones are ruinous.
- ▸Change, training and documentation. People abandon the old workarounds only when the new path is genuinely faster.
- ▸Decommissioning. Archiving, contract exit, hardware disposal, and the recurring licences you finally stop paying.
If the target is a public website, the migration mechanics and the traffic risk are laid out in our migration playbook that does not lose your SEO.
The cost categories of an incident, honestly listed
An incident is not one number either. It is a sequence of costs, several of which arrive months later. List them all before probability enters the picture and you will find that most are computable from contracts and payroll you already have on file.
Costs that land in the first fortnight:
- ▸Downtime. Revenue per hour of outage, plus payroll for people who cannot work.
- ▸Incident response. External forensics at emergency rates, external counsel, communications support.
- ▸Recovery engineering. Restore from backups, verify integrity, rotate every credential and key, rebuild whatever cannot be trusted.
Costs that land later:
- ▸Notification and regulatory. Legal review, notifying customers and authorities, correspondence, potential penalties.
- ▸Contractual. Service credits, customer-initiated audits, remediation commitments, unplanned security questionnaires.
- ▸Commercial. Deals paused while procurement re-checks you, and churn among the customers who asked the hardest questions.
- ▸Insurance. The excess you pay, then the premium and terms you are offered at renewal.
- ▸Opportunity. The roadmap your team did not build because it spent a quarter recovering.
Notice the pattern. Recovery from a serious compromise usually forces the very modernisation you deferred, only now under time pressure, in public, with no negotiating position on price.
Estimate probability without inventing statistics
You cannot calculate your breach probability. You can rank your exposure, which is what the decision actually needs. Use four observable facts per system: is it reachable from the internet, is the software still vendor-supported, are flaws in that product family known to be exploited, and does it hold data that would make an incident reportable.
- ▸Supported or not is a lookup, not an opinion. PHP supported versions and the Node.js release and end-of-life schedule publish exact dates for anyone to read.
- ▸Exploited in the wild or not is also a lookup. The CISA Known Exploited Vulnerabilities catalogue records which issues attackers are actually using, which is a far better prioritisation signal than severity scores alone.
- ▸Dependency rot is measurable inside your own repository. OWASP Dependency-Check will enumerate known-vulnerable components in your build, today, at no licence cost.
- ▸Component ownership is measurable too. Generate a software bill of materials in CycloneDX format and you can answer, in minutes rather than weeks, what you are running and whether anyone still maintains it.
Then express probability in bands, high, medium and low, with the evidence attached to each band. A board can act on "internet-facing, unsupported since last year, known-exploited flaw class, holds personal data" without anybody pretending to know a percentage.
The carrying cost you are already paying
Deferral is not free, it is merely unbilled. Before comparing modernisation against an incident, total what the status quo already costs every year. This number frequently surprises people, and it is the most persuasive part of the case because it is invoiced rather than hypothetical.
- ▸Extended support and legacy licence fees, which typically rise sharply once a product passes end of life.
- ▸Retention premium for scarce skills. Paying above market for the few people who can maintain a dead stack, and carrying the key-person risk when they leave.
- ▸Delivery drag. Every new feature costs more and ships later because the old system fights it.
- ▸Integration tax. Custom connectors and manual exports that exist only because the legacy system cannot speak modern protocols.
- ▸Manual workarounds. Staff hours spent doing what software should do, every week, indefinitely.
- ▸Lost deals. Enterprise security questionnaires you cannot pass, and the pipeline that quietly fails to convert.
- ▸Worse insurance economics, negotiated from a weak technical position.
Compare three options, not two
The honest business case is not modernise against do nothing. It is three options, each with a cost, a residual risk and a review date. Presenting three makes it a decision. Presenting two makes it a pitch, and boards can smell the difference.
- ▸Option A, accept. Cost: the annual carrying cost above. Residual risk: unchanged, and rising as flaws accumulate. It only counts as a legitimate choice with a named owner and a review date.
- ▸Option B, contain. Cost: weeks of engineering rather than months. Remove the system from the public internet or place it behind an identity-aware proxy, segment the network, enforce phishing-resistant MFA on administrative access, verify that isolated backups genuinely restore. Residual risk: materially lower, but the carrying cost continues and the ceiling on the business stays where it is.
- ▸Option C, modernise. Cost: the six categories above, phased. Residual risk: lowest, and it removes the carrying cost instead of paying it forever.
Most sane programmes run B then C. Containment buys the time a phased rebuild needs, and it is precisely the part of proper ongoing maintenance that most retainers quietly omit.
Sequence the work so the number is affordable
A single large number gets rejected. A sequence of funded increments gets approved. Order the work by exposure and by business value, deliver something usable every quarter, and let each phase pay for part of the next through the carrying cost it removes.
- ▸Phase one, visibility. Inventory, software bill of materials, exposure map, dated decisions. Small budget, immediate governance value.
- ▸Phase two, containment. Cut the attack surface of everything you are not rebuilding yet.
- ▸Phase three, the highest-exposure system. Usually internet-facing and holding customer data.
- ▸Phase four onward, the systems of record. The long-lived business software where the data actually lives, and where the strongest efficiency gains hide. Escaping SaaS and migrating to custom software covers how that transition is usually structured.
Never let phase one wait for phases three and four to be funded. Visibility is cheap and it changes every subsequent estimate.
What a defensible one-page business case contains
One page, six blocks, no borrowed statistics. If the case cannot fit on a page, the argument is not finished yet. Every figure on it should trace back to a contract, a payroll rate, a vendor page or your own delivery history.
- ▸The asset: what it is, who owns it, what data it holds, whether it is internet-facing.
- ▸The status: version, support status with the vendor lifecycle source cited, known-exploited flaw classes, dependency findings.
- ▸The carrying cost: this year's real, invoiced cost of keeping it exactly as it is.
- ▸The incident cost categories: your downtime rate, your response retainer or estimated emergency rate, your notification exposure, your policy excess.
- ▸The three options: accept, contain, modernise, each with cost, residual risk and review date.
- ▸The recommendation and the owner: one named person, one date, one decision.
That page survives a board meeting, an insurance renewal and, if the worst happens, an investigation. A slide full of somebody else's averages survives none of them.
How TuniCyberLabs helps
We build the case before we build the software. That means a discovery phase producing the inventory, the software bill of materials, the exposure ranking and the real carrying cost, then a phased modernisation plan with costed increments you can approve one at a time. Containment first where budget is tight, rebuild where risk and business value are concentrated. Engineering in Tunisia, contracting from Estonia, working with clients across the EU and North Africa.
Send us the system you cannot cost, and we will produce the one-page case for it: start a conversation.