Posted on
October 28, 2026
Updated on
October 29, 2026
Read time
11 mins read
Quick Answer: A museum codebase is a system you pay to preserve rather than to progress: the retainer keeps the exhibit running, and nothing new ever ships. The maintenance bill looks cheaper than modernization only because four line items never appear on it: the scarcity premium on the one developer who understands the system, the carrying cost of unpatchable security exposure, the revenue lost at integration walls, and the roadmap nobody proposes anymore. The decision rule: total those honestly, and when the real annual ledger rivals the amortized cost of an incremental modernization, maintenance is the expensive option wearing the cheap label.
The pattern runs all the way to the top: GAO testimony to Congress found more than 75% of the US federal IT budget consumed by operating and maintaining existing systems, and CISQ puts the accumulated principal of US software technical debt at roughly $1.5 trillion. Museums are expensive. The admission is just collected in installments.
Here is the situation as owners describe it: one developer in the world understands the system, every change takes weeks, the framework is too old to hire for, and the rebuild quote was terrifying, so the maintenance bill gets paid again. If you’re not yet sure whether that describes your system, start with our seven-sign modernization diagnostic, which scores the question properly. This article is for the owners who already know, and keep paying anyway, because the only number they’ve ever compared the maintenance bill against is a rebuild quote designed to be compared against zero. What follows is the comparison that was never put on paper: what the museum actually costs per year, and what an exit actually costs per month.
You’re Not Paying for Maintenance. You’re Paying Admission.
Maintenance, in the healthy sense, is upkeep on an asset that still produces: the oil change on a truck that hauls. What a museum codebase receives is different in kind, and Michael Feathers gave the field its sharpest definition of the category:
“To me, legacy code is simply code without tests.”
Michael Feathers, Working Effectively with Legacy Code (2004)
Code without tests can’t be changed safely, so it stops being changed; it can only be preserved, and preservation is what your retainer buys: patches that keep the exhibit exactly as it was in 2014, climate control against an environment (browsers, OS versions, TLS standards, attacker capabilities) that keeps moving. The industry-wide scale of that preservation work is measured: Stripe found developers spending roughly 42% of their time on maintenance and bad code rather than new capability. The question this article answers is not whether the preservation is skilled (it usually is) but what it totals when the invisible lines are added, because the retainer is only the ticket price.
The Invisible Ledger: Four Lines the Maintenance Bill Never Shows
The scarcity premium. The market for developers willing to work on your stack shrinks every year while the system gets harder to learn, so the one person who knows it prices accordingly, at every renewal. Price it by comparing their rate trajectory against market rates for mainstream stacks; the gap is the premium, and it compounds, because the premium is also a retention hostage situation nobody names (its vendor-shaped cousin is the hostage codebase).
The security carrying cost. A museum stack usually runs past its framework’s end of life: as of late 2026, PHP 8.1 and everything before it receives no security patches, and 8.2 exits support on December 31, 2026, which puts the great majority of legacy PHP applications years past their safety net. The cost isn’t hypothetical: it’s the known CVEs you can’t patch without breaking the app, accepted and renewed annually, priced as exposure times likelihood, plus what your cyber-insurance and enterprise customers’ security questionnaires are already charging you for it. PHP application modernization exists as a category precisely because this line compounds on a published schedule.
Integration walls. Every tool your business adopts (the CRM, the analytics stack, the AI tooling) stops at the museum’s border, and somewhere in your sales history are deals that died at “does it integrate?” Price it as lost deals per year plus the hours of manual re-keying that bridge the gaps; this is usually the first line that shocks, because it’s revenue, not cost.
The velocity tax and the silent roadmap. Every change takes weeks of somebody’s salary, which is priceable; the bigger line is the changes nobody requests anymore, because the organization has learned what the answer costs. A roadmap that froze years ago has a price too: it’s whatever your competitors shipped in the meantime. That freeze is the end state of the drag mechanics in terminal velocity, and the fact that it produces no invoice is exactly why the museum keeps winning budget reviews.
Two Annual Budgets, Honestly Totaled
Put illustrative numbers on a mid-size legacy web app and the comparison the rebuild quote never allowed becomes visible. Another year of the museum: $48,000 of retainer, $11,000 of emergency fixes, a $9,000 scarcity premium on renewal, $30,000+ of integration-shaped revenue that quietly didn’t happen, call it ~$98,000, rising 10-15% a year, ending with nothing new owned. A year of the funded exit: ~$90,000 as year one of a two-year incremental modernization, with the legacy system kept running underneath, the riskiest routes retired first, and the first new features in years shipping along the way, then dropping to routine care on a hireable stack. Your numbers will differ; the shape won’t. Similar annual spend, and one of them is rent on the past while the other is a mortgage on an asset you end up owning. (What the modern build itself should cost, tier by tier, is in the 2026 cost guide; the per-year figure above is that total, phased.)
Want the ledger filled in for your actual system?
Techuz delivers application modernization services starting with the audit: your real retainer history, your stack’s EOL exposure, your integration losses, and the two-budget comparison on one page, whether or not we do the build.
When Keeping the Museum Is the Right Call
Economics cuts both ways, and an honest ledger sometimes defends the museum. Keep paying admission, deliberately, when the system is genuinely stable (incidents rare, the same ones not recurring), when its scope is frozen by nature rather than by fear (a back-office tool doing one unchanging job), when the business plans to retire the process itself within a couple of years (never modernize a system whose job is ending), or when the honest ledger really is small because the invisible lines genuinely don’t apply: no integration ambitions, no hiring needs, no enterprise security reviews. The discipline is the same either way: total the ledger annually, on a calendar date, so “keep patching” is a decision with a number attached instead of a default with a feeling attached. And resist the opposite reflex too: the from-scratch rewrite that a terrifying ledger tempts you toward is its own famous trap, the one Joel Spolsky called the worst strategic mistake a software company can make; the diagnostic post covers when to rewrite software and the three narrow exceptions where a clean rebuild genuinely wins. For everything in between, there’s the financing plan.
The Strangler-Fig Path, Read as a Financing Plan
The technical mechanics of strangler-fig modernization (the routing facade, route-by-route migration, the quiet retirement) are covered in the modernization diagnostic. What belongs in this article is the financial reading, because it dissolves the exact fear that keeps the museum funded. The rebuild quote terrifies because it arrives as one number demanding one approval. The strangler path arrives as a monthly spend remarkably close to the one you already approve without blinking: roughly the maintenance budget, redirected, for 18-24 months, buying an exit instead of admission. Three financial properties follow. The spend is incremental and pausable: every stage is a safe stopping point, so a bad quarter pauses the program instead of killing it. It’s self-derisking: the riskiest, most-changed routes move first, so the earliest dollars retire the most expensive exposure. And it produces during payment: new features ship on the new stack from the first months, which means the roadmap unfreezes while the migration runs, not after it. The museum’s monthly bill and the exit’s monthly bill are nearly the same size; the difference is entirely in what’s left when the paying stops.
The CFO Worksheet: Pricing Your Own Ledger
| Line item | How to price it | Where the number hides |
|---|---|---|
| Visible maintenance | Retainer plus every emergency invoice, trailing 12 months | Accounts payable; this one you already know |
| Scarcity premium | Your key developer’s rate trajectory vs market rate for mainstream stacks | The last two renewal conversations |
| Security carrying cost | Open unpatchable CVEs × plausible incident cost × odds, plus insurance and audit friction | The accepted-risk register, and the security questionnaires you answer slowly |
| Integration losses | Deals lost or discounted at “does it connect?”, plus hours of manual re-keying × salary | Sales post-mortems and the ops team’s spreadsheet folder |
| Velocity tax | (Weeks per change on the museum minus days per change on a modern stack) × changes per year × salary | The ticket queue’s timestamps |
| The silent roadmap | The three features you’d propose tomorrow on a modern stack, valued the way you’d value them in a business case | Nowhere; that’s the point. Write them down anyway |
Fill the right column, add it up, and set the total next to a phased modernization quote from a web application development company you’ve vetted (our 12-question guide is the vetting instrument, and the overrun controls belong in the contract). If the museum’s honest total comes in well under the exit’s annual cost, congratulations: keep the museum, on purpose, and re-total next year. In our experience the more common discovery is the one this article is named for: the museum was never the cheap option. It was the option whose price was never added up.
Fund the exit from the budget you already spend
As a custom web development company in the USA market, Techuz runs legacy application modernization as a phased strangler-fig program: priced per stage, pausable at every stage, shipping features from the first months, and ending with an asset instead of an exhibit.
FAQs
How much does it really cost to maintain a legacy web application?
Far more than the retainer. The honest annual ledger adds four invisible lines: the scarcity premium on the dwindling pool of developers who know the stack, the carrying cost of security exposure you can’t patch, revenue lost at integration walls, and the velocity tax plus the features nobody proposes anymore. For a mid-size system, a $48,000 retainer routinely totals near $100,000 a year once those are priced, rising 10-15% annually.
When does replacing a legacy app cost less than maintaining it?
When the honest annual ledger rivals the amortized cost of an incremental modernization, which for many mid-size systems is a two-year phased program costing about what the museum already costs per year. The decision rule: total the visible and invisible lines annually, set them against a phased quote, and choose on paper. Keep maintaining, deliberately, when the system is stable, its scope is naturally frozen, or the process itself retires soon.
Why does the rebuild quote feel so much bigger than the maintenance bill?
Because the two numbers are presented differently, not because they are differently sized. The rebuild arrives as one total demanding one approval; the maintenance cost arrives in installments that no one adds up, with its largest lines (scarcity premiums, security exposure, lost integrations, the frozen roadmap) never invoiced at all. A phased strangler-fig program removes the asymmetry: it costs roughly the monthly spend you already approve, with an end date attached.
What are the hidden costs of running on an end-of-life framework like old PHP?
Every CVE published after the end-of-life date goes permanently unpatched upstream, so exposure grows on a schedule you don’t control; as of late 2026, PHP 8.1 and below receive no security fixes and 8.2 exits support at year’s end. The cost shows up as accepted risks renewed annually, slower enterprise security reviews, rising cyber-insurance friction, and eventually an upgrade that can’t be done in place, which is the signal that PHP application modernization is due.
Can I fund modernization out of my existing maintenance budget?
Often, nearly. A strangler-fig program typically runs at a monthly spend close to the combined maintenance retainer and emergency-fix budget, for 18-24 months, while the legacy system keeps running underneath. The spend is pausable at every stage, the riskiest routes retire first, and new features ship during the migration rather than after it, so the roadmap unfreezes while you pay. The difference from maintenance isn’t the size of the bill; it’s that this one ends, and ends with an asset.
Sources
- US Government Accountability Office, testimony to Congress on federal IT: over 75% of the IT budget spent operating and maintaining existing systems
- CISQ, The Cost of Poor Software Quality in the US (2022; ~$1.5T accumulated technical-debt principal)
- Stripe, The Developer Coefficient (~42% of developer time on maintenance and bad code)
- PHP, Supported Versions (official end-of-life schedule)
- Michael Feathers, Working Effectively with Legacy Code (2004)
Looking for timeline and cost estimates for your app?
Contact us
Nilesh K.
Nilesh Kadivar leads Marketing & GTM at Techuz, where he helps startups and enterprises turn software, AI, and automation ideas into shipped products. He's spent 10+ years in business development and enjoys writing about tech trends, growth strategy, and the realities of building for the web and mobile.
