Outside of software, legacy is a word of pride. People talk about the legacy they want to leave — what they hope to be remembered for, what they want to pass on. The word is used with reverence.

In software, it's a complaint. The legacy database. The legacy frontend. The legacy auth flow.

I try to never use it that way.

In our industry, legacy carries baggage. It implies obsolescence, accumulated pain, something to be embarrassed about. And yet — in almost every case I've worked on — the "legacy" system is the one paying the bills. It's the system serving traffic right now, the one customers are happily using, the one funding the migration to its replacement.

As Bjarne Stroustrup observed:

Legacy code often differs from its suggested alternative by actually working and scaling.

The word shapes how teams treat it. Once a system is legacy, it stops getting investment. Bug reports get triaged differently. New hires are told not to learn it. Engineers who maintain it feel like they're working on something already dead.

And the label sticks. A system usually earns the "legacy" tag the moment a replacement starts being planned — but migrations drag, or don't finish at all. The negative connotation lingers in the organization for years. People want distance from it. Meanwhile the system everyone has decided is legacy keeps doing its job, waiting for a successor that may never quite arrive.

I use classic instead. The classic-cars analogy I owe to Kyle's post on migrations — a system that's earned its place, that we still respect, that we choose to maintain even as we build its successor. Vintage works too, with the same reframing.

This isn't just vocabulary. In the previous post, the renamed build script was proto:gen:classic, not proto:gen:legacy. That wasn't an accident.

When I find myself reaching for legacy, I stop. The system in front of me is probably what's keeping the lights on. I owe it a better word.