Post
The Graveyard Orbit: Where Good Software Goes When It Doesn't Die
Satellites that can't be brought home get nudged into a quiet parking orbit — still circling, still intact, just not doing anything. Software has the same orbit.
When a satellite's mission ends 36,000 kilometers above Earth, it faces an awkward problem. Bringing it back down costs about 1,500 meters per second of delta-v — fuel the satellite almost certainly doesn't have. So instead, mission control spends a fraction of that — just 11 m/s — to nudge it 300 kilometers higher, into what's called a graveyard orbit.
A quiet parking lot above the action. Still circling. Still intact. Just not doing anything anymore.
Software has the same orbit. And if you've been in tech long enough, you've watched things get pushed there.
What Graveyard Orbit Looks Like in Software
A technology enters graveyard orbit when three things are simultaneously true:
- It's still running — powering real production systems, serving real users
- It's not actively chosen — almost nobody picks it for new projects
- It's not quite dead — no dramatic shutdown, no obituary, no sunset blog post
It's the technological equivalent of "we don't talk about it, but we'd notice if it stopped."
The Orbital Map
| Technology | Peak Era | Still Running On | What Replaced It | Status |
|---|---|---|---|---|
| jQuery | 2010–2015 | ~73% of all websites | React, Vue, vanilla JS | Graveyard orbit |
| Heroku | 2012–2019 | Thousands of production apps | Render, Fly.io, Railway | Graveyard orbit |
| Subversion | 2004–2012 | Enterprise codebases | Git | Graveyard orbit |
| SOAP/XML | 2003–2010 | Banks, healthcare, government | REST/JSON, GraphQL | Deep graveyard orbit |
| IRC | 1998–2015 | Open-source communities | Discord, Slack | Graveyard orbit |
| FTP | 1985–2005 | Legacy file transfers | SFTP, SCP, cloud storage | Graveyard orbit |
| CoffeeScript | 2012–2015 | Legacy Node.js apps | TypeScript, ES6+ | Reentering atmosphere |
| Google Wave | 2009–2010 | Nothing | Nothing | Burned up |
The last two rows matter. They show what graveyard orbit is not.
CoffeeScript isn't in graveyard orbit — it's actively declining, being ripped out of the codebases that used it. It's reentering the atmosphere. Google Wave never reached graveyard orbit at all. It just burned up. Killed, mourned briefly, gone.
Graveyard orbit is a stable state. That's the whole point — it costs more to bring something down than to leave it up there.
What Puts Software in Graveyard Orbit?
Three forces work together.
1. The migration tax is too high. Rewriting a jQuery app in React costs months. Migrating from SVN to Git means retraining teams, reconfiguring CI, rewriting hooks. The working system isn't broken — it's just unfashionable. And "unfashionable" doesn't justify the budget.
2. The replacement isn't a strict superset. Git didn't do everything SVN did the same way. React doesn't solve the same problems jQuery solved. Every migration has edge cases where the old thing actually worked better for that specific use case. Those edge cases become anchors.
3. Institutional knowledge is a one-way function. The person who understood the SOAP integration left three years ago. The Heroku deploy pipeline has twelve undocumented environment variables. Nobody knows why the SVN hooks work — only that they do. Replacing the technology means reverse-engineering years of accumulated decisions, many of which were never written down.
The Uncomfortable Truth
Here's the thing software engineers don't like admitting: graveyard orbit is often the correct decision.
Not everything needs to be migrated. Not every legacy system is technical debt. Sometimes the mature, boring, unmaintained technology is doing its job perfectly well — and the "modern" replacement would cost six months and introduce new bugs for zero user-visible improvement.
jQuery on a marketing site that gets updated twice a year? Leave it. Heroku running an internal tool with four users? Leave it. The SVN repo for a product in maintenance mode? Leave it.
The engineer's instinct to modernize everything is itself a kind of bias — the assumption that newer is inherently better. The satellite doesn't care that it's in graveyard orbit. It's still circling. Still intact. It just stopped pretending it needs to be somewhere else.
When Graveyard Orbit Becomes a Problem
The analogy holds in one more uncomfortable way. In space, graveyard orbits were designed as a permanent solution. But as we launch more satellites, those "empty" parking orbits are filling up. The graveyard is getting crowded.
Software has the same problem. Every technology in graveyard orbit is a dependency that:
- Still needs security patches (who's patching your jQuery 2.x?)
- Still consumes institutional knowledge to maintain
- Still constrains what you can build on top of it
- Still shows up in your CVE reports
A single satellite in graveyard orbit is fine. A hundred of them? That's a debris field waiting to happen.
Audit Your Orbits
The lesson isn't "migrate everything" or "leave everything." It's simpler: know what's in your graveyard orbit, and know why it's there.
The intentional decision to leave jQuery running on a static site is wisdom. The unintentional discovery that your payment system depends on a SOAP endpoint nobody maintains is a risk.
Same orbit. Very different implications.
Sources
- Graveyard Orbits and the Satellite Afterlife — NOAA/NESDIS — the space science behind satellite disposal orbits
- Graveyard orbit — Wikipedia — technical details on orbital mechanics and delta-v costs
- jQuery Usage Statistics — W3Techs — current data showing jQuery still on ~73% of all websites
- Heroku Isn't Dead, But It's Dying in Slow Motion — Janakiram MSV — analysis of Heroku's transition to sustaining engineering