Software maintenance costs about 15% to 20% of the original build cost per year. On a $300,000 build that is $45,000 to $60,000 a year. The figure is a rule of thumb, and I could not trace it to a study: the pages I read that repeat it cite none. What I could check is what the rule assumes, what vendors charge and what two agencies measured. The measured spread is 6% to 40%.
What the rule assumes is an EltexSoft calculation, made in November 2026. The method: take the maintenance equations of COCOMO II, the public cost model from the University of Southern California, leave every rating at nominal, rate the maintainers as "somewhat familiar" with the code, and vary the share of code added or modified in a year. When 15% to 20% of the code changes, annual maintenance effort is 14% to 19% of the original development effort. Project size cancels out of the ratio. So the rule amounts to assuming that 15% to 20% of the code is added or modified every year. It is an assumption about change, not a measurement of cost.
EltexSoft quotes the 15% to 20% rule on its own pages. So I went looking for the page where it first appeared.
Where the Rule Comes From
I read five agency pages that state the range, as 15% to 20% or 15% to 25%. None cites a study. Two call it an industry standard or a rule of thumb, and two say it matches their own client work. One has "Gartner Rule" in its page title and links no Gartner document.
The oldest page I found that calls the figure a rule of thumb for software built for a client was posted on December 19, 2016. An agency, Blue Acorn, now Blue Acorn iCi, wrote that "a general rule of thumb" is to "set aside roughly 20% of that initial effort to support and maintain that software on an annual basis". It was a rule of thumb then too, with no source.
The figure itself is older than that page. The oldest document I read that puts a yearly percentage on build cost is a Stanford paper on valuing software, dated April 2007 (a shorter version ran in Communications of the ACM in September 2006). Its worked example, a vendor's own product with an initial cost of $500K, says "Maintenance costs are best estimated based on initial software cost" and assumes "a relatively high 20% annual cost of maintenance". The rate is an assumption, and the paper cites no source for it. The same paper has the percentage on another base, the yearly support fee on a software licence: "Typical rates charged customers for ongoing support are 15% of the original purchase price." In January 2005 Computerworld reported a Gartner analyst saying that application vendors had raised maintenance and support fees "from 14% to 15% of annual licensing fees to 18% to 20%". That is the only Gartner statement I found near the number, and it is about licence fees. So by 2007 one paper carried both bases, a fee on purchase price and an assumed rate on initial cost. I found no measurement behind either, and no document that connects them to the agency rule.
Three Checks on 15% to 20%
22%, vendor support fees. Oracle's technology price list of September 15, 2026 prints a licence price and a support price for each product. I divided one by the other on all 366 pairs, and every one is 22% (EltexSoft calculation). Database Enterprise Edition lists at $47,500 per processor and $10,450 for support. The list calls these "annual fees" for "first year support only"; renewals rise by an inflation adjustment. SAP says its Enterprise Support list price "remains fixed at 22 percent until 2025" and gives no later figure. Both are prices for packaged software, set by the seller. Oracle's is a share of licence price; SAP's page does not say what its 22 percent is a share of. They show what the market pays, not what maintenance costs.
14% to 19%, the COCOMO II model. The model's manual counts maintenance as "adding new capabilities and fixing or adapting existing capabilities" and leaves out rebuilds that change more than half the code. The share of code changed per year is an input, and the manual gives no typical value. At 15% to 20%, the equations return 14% to 19% of development effort (EltexSoft calculation). Who maintains the code moves the result as well: at the same 15% to 20% change, a team that knows the code completely comes out at 12% to 17%, and a team new to it at 17% to 23%.
6% to 40%, actual hours. Two agencies have published their own numbers. Blue Acorn, in the post above, measured support and maintenance as a yearly percentage of the original project, in actual hours, for sites launched in 2014 and 2015. It listed five clients: 6%, 12%, about 15% to 20%, 23% and 40%. The average is 19.6%, and the post adds that "the average is a terrible way to estimate cost". In 2026 Wavect reported median yearly spend of 21% to 26% of build cost across 24 products. That figure includes product iteration, and Wavect calls it "directional, not a statistically representative survey".
Ask Whether It Includes New Features
In the oldest data, most maintenance is enhancement. The best-known breakdown of maintenance work is a 1978 survey of 69 data processing organizations. It found that 48.0% of annual staff hours went to maintaining and enhancing existing systems. Inside that work, 60.3% was "perfective": user enhancements, improved documentation and recoding for efficiency. Adapting to changes in data, hardware and system software was 18.2%. Emergency fixes and routine debugging were 17.4%. A 2003 study that measured change records for three products found corrective work at more than twice the survey's share, so read the split as managers' estimates.
Definitions differ in the same way today. Blue Acorn's 6% to 40% leaves out enhancements, which it budgets separately. COCOMO II and Wavect count them. A percentage means little until you know which one you were quoted.
Why 60% to 80% of Lifetime Cost Is the Same Rule
The other figure in circulation is that maintenance is 60% to 80% of what software costs over its life. The abstract of the 1978 survey already said "rough estimates" of the resources consumed "range as high as 75-80 percent". A talk summary on the site of ISBSG, a software benchmarking group, says "it is generally believed" to be "somewhere between 65 and 85 percent".
Held flat, 15% to 20% a year adds up to the build cost in 5 to 6.7 years. After ten years it is 1.5 to 2 times the build, which is 60% to 67% of everything spent. Reaching 80% takes 20 to 27 years (EltexSoft calculation: annual rate times years, with no inflation and no growth in the codebase). Growth shortens that: the Stanford paper's own example, 20% a year on a codebase that keeps growing, reaches about 80% of total cost by year seven. The two rules are one rule at two time scales. A lifetime share says more about how long the software lived and how much it grew than about what it cost to keep.
A Share of the IT Budget Is a Different Number
Budget shares get quoted as if they were maintenance costs. GAO reports that about $83 billion, 79% of planned federal IT spending for fiscal 2025 at 24 agencies, was meant for operations and maintenance. Deloitte's 2026 survey of technology leaders puts the "run" share of technology budgets at 38%, down from 58% in 2020. Both describe an organization's whole technology budget, not the cost of keeping one application. We cover the legacy budget trap and technical debt separately.
How to Use the Number
Budget 15% to 20% of the build cost a year for keeping the software running, and budget features separately. Blue Acorn's own advice was to start at 20% and adjust: closer to 10% to 15% when the roadmap is strategic, 20% to 40% when it keeps changing, and higher with every third-party integration.
Part of the work arrives on someone else's schedule. Since August 31, 2026, Google Play requires new apps and app updates to target Android 16 or higher. Since April 28, 2026, Apple accepts only uploads built with Xcode 26 or later. Skip that work for a year and the next update cannot be submitted.
When someone quotes you a maintenance percentage, ask three things. Percent of what: build cost, licence price or last year's fee? Does it include new features? What was it measured on? EltexSoft has kept client products in production for up to ten years. If you need a team that stays past launch, look at how we build custom software.