The Revenue Line Lies
A product that generates several million dollars a year looks like an asset on a spreadsheet. It has customers, a payment processor, and a support queue. Finance calls it a profit center. Engineering calls it a nightmare.
The gap between those two assessments is where companies quietly bleed. Software products that appear profitable by conventional accounting can carry costs so thoroughly distributed across an organization that no single budget line ever captures the full picture. When you finally add them up, the math often favors a funeral.
This is not a fringe case. It is one of the most common traps in mature software businesses, and it explains decisions that seem irrational from the outside: a company sunsetting a product with hundreds of thousands of users, or a private equity firm buying a software portfolio and immediately terminating three products that looked like winners.
How Accounting Hides the Real Cost
Standard product P&L accounting assigns direct costs well. Hosting bills, dedicated support staff, per-product licensing fees. These show up cleanly. What it systematically undercounts is shared cost allocation.
Consider what a legacy product actually consumes. It pulls senior engineers into incident reviews because the codebase predates current architecture patterns. It requires security patches on a dependency chain no one fully understands anymore. It occupies space in the release pipeline, meaning every deployment cycle for the healthy core product has to accommodate its quirks. Its data model influences decisions about the shared database schema. Its edge cases live in the heads of your most experienced people, taxing their cognitive bandwidth in ways that never appear on a timesheet.
None of these costs are zero. But because they are shared and distributed, they tend to get absorbed into overhead rather than attributed to the product generating them. The product looks profitable. The company is subsidizing it invisibly.
The Maintenance Treadmill
Software does not hold still. A product that required a certain maintenance effort in 2018 requires more in 2024, not because anything went wrong, but because the world moved and the product did not.
Dependencies age out of support. Security standards tighten. Compliance requirements multiply. The cloud provider deprecates the instance type you built on. The payment processor you integrated changes its API. None of this generates revenue. All of it demands engineering time.
The treadmill nature of maintenance means costs for a static product compound over time while revenue from that same product often plateaus or declines. Customers on old products are frequently on old pricing. Churn nibbles at the edges. New customers prefer the newer product. The ratio of revenue to maintenance burden tilts further against you every year, but slowly enough that it rarely triggers alarm.
This dynamic is especially punishing for companies that grew through acquisition. A portfolio assembled from five separate acquisitions may contain five separate authentication systems, five data models, five deployment pipelines, and five customer data schemas that resist consolidation. Each product looked profitable when purchased. The collective cost of keeping all five on life support can dwarf what the portfolio earns.
The Hidden Tax on Future Work
Legacy products do not just consume resources directly. They constrain what the rest of the company can do.
Engineering decisions made to preserve backward compatibility with an old product can block architectural improvements across the entire platform. If the old product cannot tolerate a database migration strategy the modern products need, the modern products wait. If the old product has undocumented behavior that a shared service relies on, refactoring that service becomes dangerous. The old product becomes load-bearing in ways nobody planned and nobody can fully map.
This is the most underappreciated cost: optionality. A product you cannot kill is a product you cannot move past. It limits your architectural choices, your hiring pitch (engineers do not line up to work on PHP 5 codebases), and your ability to consolidate infrastructure. The cost is not just what you spend maintaining it today, but the future work you cannot do, or must do less efficiently, because the old product is in the way.
Why Organizations Resist the Math
If the economics often favor termination, why do companies keep maintaining products well past the point where it makes sense?
Several forces push in the wrong direction. The revenue is real and visible. The costs are distributed and invisible. Anyone who proposes killing a profitable product faces an immediate political problem: you are proposing to eliminate revenue that finance can see in exchange for savings they cannot easily quantify. The burden of proof is asymmetric.
There is also the customer relationship problem. Long-tenured customers on old products are often the most vocal, and sometimes the most strategically significant in terms of enterprise relationships. Telling them the product is ending triggers a negotiation, a potential churn event, and sometimes a public complaint. The path of least resistance is always to extend the sunset deadline by another year.
Organizations also underestimate migration costs. When someone finally proposes killing the old product and moving customers to the new one, the actual cost of migration, in professional services hours, support volume, and engineering work to close feature gaps, can look larger than continued maintenance. The calculation is usually wrong, because it compares a known migration cost against a falsely low maintenance estimate that ignores all the distributed costs. But it feels right, and so the old product lives.
How to Actually Run the Numbers
The corrective is to run an honest total cost of ownership calculation, one that forces attribution of shared costs.
Start with a full allocation of engineering time. This means tracking not just dedicated product engineers but the percentage of platform, security, infrastructure, and on-call time attributable to the product. Many companies that have done this exercise find that the shared infrastructure burden alone doubles or triples the apparent engineering cost of the product.
Then price the optionality cost. This is harder but not impossible. Identify the architectural decisions that are blocked or constrained by the legacy product’s existence. Estimate the engineering cost of those constraints. If the old product’s data model requires you to maintain a compatibility layer that takes two engineers six months a year to manage, that cost belongs on the old product’s ledger.
Finally, stress-test the revenue. Not just current revenue but projected revenue accounting for natural churn, pricing pressure, and the competitive dynamics of a product you are no longer investing in. A product generating steady revenue today on a flat or declining trajectory is worth considerably less than its current run rate suggests. Your burn rate is the wrong number to watch, and the same logic applies to legacy revenue: the number on the income statement is not the number that matters for decisions about the future.
The Case for a Hard Sunset
Companies that execute clean product sunsets generally find the decision looks better in retrospect than it did in prospect. The engineering capacity that comes back is often larger than anticipated. The architectural freedom unlocked by removing the legacy constraint accelerates work on the core product in ways that are hard to predict in advance but show up clearly afterward.
Google, for all the mockery it receives for killing products, has generally been better than most large software companies at executing these decisions. The harder cases are mid-sized companies where a legacy product represents a large enough share of total revenue that the political cost of sunsetting it is high, but where the maintenance burden is quietly taxing the team building the future.
The practical answer for companies in that position is not to pretend the economics work out. It is to build a migration path aggressive enough to actually move customers, treat the migration as a product investment rather than a support cost, and set a hard termination date before the exercise begins. Sunset timelines without commitment dates are not sunsets. They are deferrals.
The profitable product you cannot afford to kill is usually one you also cannot afford to keep. Recognizing that earlier, before the maintenance treadmill has fully accelerated, is almost always worth the political difficulty of making the call.
What This Means
The core insight: Standard product P&L hides distributed costs in overhead, making legacy products appear more profitable than they are. Full cost attribution routinely reveals that the real margin is far thinner than reported, and sometimes negative.
The compounding problem: Maintenance costs grow over time for a static product. Revenue from that product tends to plateau or decline. The ratio deteriorates every year, slowly enough to avoid triggering alarms.
The hidden cost: Legacy products constrain architectural decisions, limit engineering quality and hiring, and consume the attention of senior people in ways that never appear in the product’s budget.
The political trap: Revenue is visible. Distributed maintenance costs are not. Proposals to sunset profitable products face an asymmetric burden of proof that biases organizations toward inaction.
The corrective: Run a full total cost of ownership calculation with honest shared cost attribution. Price the optionality cost of keeping the product alive. Stress-test the revenue trajectory. The math is rarely as close as it appears.
