Stability is one of the highest goals in infrastructure work. Predictable systems are easier to operate, easier to reason about, and easier to trust when things go wrong.
But give it enough time and the same forces that make systems reliable can slowly turn them into something else: systems that work, but can no longer change safely.
That’s when stability stops being a strength and quietly becomes legacy.
This transition rarely happens because of negligence or incompetence. It happens because teams make rational decisions under pressure — decisions that make sense at the time, and only reveal their cost over time.
Legacy is not in the tool
In almost every team I’ve worked with, there has always been something considered legacy.
I’ve been part of teams migrating from Jenkins to GitHub Actions. Jenkins didn’t become legacy because it stopped working, it became legacy because:
- pipelines were tightly coupled to specific agents
- changes required tribal knowledge
- upgrades felt risky
- experimentation was expensive
- there were pipelines nobody fully understood
But I’ve also been part of teams migrating from legacy GitHub Actions setups to more flexible setups.
GitHub Actions often starts as a breath of fresh air: simple workflows, YAML in the repo, fast iteration, but, over time, the same forces can apply: copy-pasted logic, hidden assumptions, workflows and permissions no one fully reviews.
Eventually, familiar phrases appear:
- “Don’t touch that workflow.”
- “Only one person understands this.”
- “It works, let’s leave it alone.”
Legacy isn’t Jenkins. Legacy isn’t GitHub Actions. Legacy is the point where change becomes dangerous.
That’s also why many organizations hire new people when facing large legacy migrations — not because existing teams are incapable, but because legacy carries context debt that’s hard to transfer.
How to identify it
On paper, the solution sounds simple: periodic reviews, scheduled refactors, regular upgrades.
But in practice, almost no team dedicates expensive engineering time to revisiting systems that are already running and working fine.
There is no alert for “this is becoming legacy.” There is no incident. No outage. No visible failure.
What is visible is:
- new features
- customer or other team requests
- security patches / vulnerabilities
- production issues
Re-evaluating a stable system rarely wins against those priorities.
Legacy, in most organizations, isn’t born from neglect, it’s born from reasonable prioritization.
Each decision is defensible:
- “Let’s not upgrade right now, it’s risky.”
- “We’ll revisit this once things calm down.”
- “It’s working, let’s not touch it.”
Over time, those decisions accumulate.
The system doesn’t break but it hardens.
How to reduce risks
Freshness alone doesn’t save systems. Stability alone doesn’t either.
Healthy systems evolve slowly and continuously, usually through localized changes driven by friction.
There is always a risk of something eventually becoming legacy, our goal is to delay it, contain it, and reduce the risk it carries.
Stability is not the enemy. Legacy is not a failure.
Legacy is what happens when systems outlive the decisions that shaped them, it doesn’t come from the tool, but from how engineering teams make decisions over time.
A good engineering team doesn’t choose between stability or change, but it knows when each one is becoming dangerous.