Zombie Systems: The Hardest to Kill Still Work

A few years into running mobile engineering, our incident channel lit up again. Wednesday night, same legacy reporting subsystem, same timeout, same two senior engineers dropping everything to stabilize it. By midnight it was stable; by morning standup nobody wanted to talk about it, because talking about it meant owning it.

The code worked like an abandoned building with electricity. No one wanted to walk inside. Every org has a few of these zombie systems—technically alive, structurally dead, and quietly expensive.

The instinct, every time, was to refactor. The right call was to remove. And I avoided that call longer than I should have.

The Fractured Bill

Most engineering orgs treat decommissioning as housekeeping. It’s a portfolio decision that shows up on the wrong line items every sprint.

The bill shows up as features taking longer. Senior engineers pulled into incidents on systems not on their roadmap. Onboarding that runs three weeks long because new hires have to learn one more thing nobody uses directly. A tooling upgrade that stalls because the deprecated framework isn’t supported, so every change in that subsystem costs more than it should.

The CFO sees infrastructure spend. The VP of Engineering sees velocity. The incident rotation sees burnout. The pain is distributed across stakeholders who don’t connect their symptoms, and that distribution dilutes the urgency to fix it. The line item connecting them is the system that should’ve been turned off two years ago.

The Preservation Instinct

Three forces keep them alive.

The first is that the original owners are still in the room. Retirement feels like erasure to the people who built it, so the conversation gets tangled in identity rather than economics. If the original author is now the director, the conversation often doesn’t start.

The second is sunk-cost gravity. The migration that built the system was hard. That memory becomes the reason to avoid the next hard thing, even when it’s shorter and pays back faster than maintaining what’s there.

The third is that nobody owns the kill decision. Feature teams own features. Platform teams own platforms. Nobody owns the end of life for things nobody currently wants but nothing structurally requires. The decision gets deferred every quarter until the system outlives the people who knew why it existed.

The Kill Criteria

The honest test is one question: if this system disappeared tomorrow and we had to rebuild only what we actually use, would we build it?

If the answer is no, the cost of retiring it is lower than the cost of keeping it. And there’s one follow-up that settles most remaining debate: how many engineers are confident they could change it safely? If the answer is one, it’s an organizational liability, not a technical asset—and the person it depends on is one resignation away from being your problem.

If both land hard, the conversation isn’t whether to decommission. It’s who owns the schedule and what gets cut to fund it.

Actually Finishing

Execution is well-trodden. The discipline to finish it is what’s rare, and the failure mode is almost always the same: the code stays in the repo. Six months later, someone resurrects it under deadline pressure to ship a quick fix, and you’re back here in two years explaining why the system you killed is on the incident rotation again. Remove the path back. Delete the code, turn off the infrastructure, and keep only what regulators require—usually a read-only archive satisfies the audit without preserving operational surface area.

The reporting subsystem from the opening got killed a few months later. It took a platform migration to give us the cover. The incidents stopped. Nobody mentioned the subsystem again.

Then quantify the silence in the currency the business already cares about: lower cloud spend, fewer escalations, engineering hours returned to feature work.

The Portfolio Multiplier

Mobile orgs get punished here. A monolithic single-product app has one decommissioning conversation per dead system. A portfolio has the same conversation N times, once per app that still depends on it. The temptation is to keep the system alive in apps that haven’t migrated and revisit when those roadmaps allow. That’s the deferral trap, and the roadmaps never miraculously allow it, because product managers are incentivized to ship visible features over invisible backend work.

That deferral is how portfolios accumulate the silent debt that eventually becomes a reorganization. The shared platform team carries duplicate contracts indefinitely, and a year later someone proposes splitting the team along business lines to “increase responsiveness.” The federated platform that results is the bill for a decommissioning conversation that didn’t happen.

The structural fix is to name the kill decision as a portfolio-level concern. Someone with authority across apps owns it. It gets scheduled deliberately and funded as a line item, not absorbed into team capacity. That’s the posture. The tactic is to exploit forcing functions when they appear—platform migrations, framework deprecations, regulatory deadlines—and attach the kill work to them rather than waiting for a standalone mandate. Posture without tactic means the schedule slips every quarter. Tactic without posture means you only kill things when something else forces your hand, which is most orgs, which is why most orgs are buried in systems that should have died.

The Frame Shift

The question isn’t what to build next. Most engineering orgs already have more answers to that than they have capacity for. The bill for keeping a system past its useful life is paid in the decisions you didn’t have the bandwidth to make—the platform investment you deferred, the migration you pushed to next year, the architectural rework that would have prevented the incident you’re now in.

You are already choosing which systems to keep alive. The question is whether you’re choosing deliberately or inheriting the choice from the team that built them.

So: which one are you afraid to kill?