You’ve probably been in that meeting. The one where a fresh-faced CTO looks at a 20-year-old system and says, ‘It’s time to modernize. We’ll rewrite it in [insert trendy framework].’ It sounds so brave, so forward-thinking. It’s actually corporate suicide.
Microsoft officially killed Visual FoxPro in 2007. They pulled the plug, expecting everyone to gracefully migrate to SQL Server and .NET. But here we are, nearly two decades later, and FoxPro is still running everything from local billing departments to niche enterprise apps. Why? Because rewriting a 20-year-old business app is exactly how you lose the business.
The tech industry treats old code like a dirty shirt, but the business world knows it’s the load-bearing wall.
We like to think the true ‘lock-in’ of legacy software is the vendor or the syntax. We tell ourselves that if we just port the code to a modern language, all our problems will disappear. But that’s a lie. The true lock-in isn’t the vendor or the syntax—it’s the invisible business logic that has been debugged, patched, and depended on for 20 years.
That logic is battle-tested. It knows the weird edge cases. It knows that when a customer in New York checks out on a Tuesday, the tax code does something mathematically illegal. You can’t just rewrite that. If you rebuild it from scratch, you lose decades of organizational scar tissue. Rewriting that logic is the real gamble, not re-hosting the old language.
This is why the recent revival of FoxPro on a brand new runtime isn’t a joke or a nostalgia trip. It’s a calculated, risk-averse move by people who actually understand how the world works. Someone out there is literally getting paid to maintain a FoxPro billing system for a Tae Kwon Do studio. Another developer is digging through floppy disks to unearth their father’s FoxPro projects. Kids grew up building UIs to open their favorite sites in FoxPro.
Nostalgia is cute, but preserving a working system is genius.
The tech world demands constant revolution. We are obsessed with the new. But true innovation isn’t always building the next shiny object. Sometimes, innovation is looking at a 32-bit dinosaur and figuring out how to keep it breathing for another decade. It forces us to ask a hard question: what does ‘modernizing’ really mean when the safest way forward is to keep the old engine running?
So the next time someone suggests a total rewrite of your legacy system, look them in the eye and ask: are we doing this because it’s good for the business, or because you’re bored? Don’t rewrite the engine. Just give it a new chassis and let it keep driving.
FAQ
Q: Isn't it just delaying the inevitable to keep running obsolete code?
A: Everything is delaying the inevitable. The goal is to minimize risk and cost today. A new runtime for an old language buys you another decade of stability without gambling your company's core business logic on a ground-up rewrite.
Q: What's the practical implication for engineering teams?
A: If it ain't broke, don't rewrite it. If you must modernize, focus on re-hosting the runtime or wrapping the old system in modern APIs, rather than attempting a total rewrite of business logic that took 20 years to debug.
Q: What's the contrarian take?
A: The tech industry's obsession with 'modernization' is often a grift to sell more consulting hours. The most innovative thing you can do is figure out how to never rewrite your working software.