Why VFP systems are still running in 2026

Say “Visual FoxPro” today and you’ll usually get a tired smile back. Fair enough — Microsoft officially discontinued the platform in 2007, and the last build (VFP 9 SP2) dates from that year. And yet: in warehouses, trade businesses and mid-sized manufacturing companies, code written in the late 90s is still running today, in 2026.

It’s rarely a technical failure

The reason is rarely ignorance. VFP applications were unusually robust for their time: the DBF/CDX data structure is simple enough to stay readable even after two decades without active maintenance, and the language itself was pragmatically built for business logic rather than academic elegance.

The real problem is rarely the code itself — it’s the dependencies around it. A VFP program that has been running since 2003 often has a very specific Windows version, a very specific printer driver, and a very specific network share path baked into its assumptions. The application survives almost everything. Its environment does not.

Migration is a risk, so is standing still

Which is exactly why “let’s just rewrite the whole thing” is often the riskier option, not the safer one. A rescue audit first — understanding what the code actually does, which reports are actually still used, which interfaces are actually still being called — saves months in the end.

Gradual modernisation, for example towards Servoy, works far more reliably than a big bang: new interface, existing data, a transition period included. The system doesn’t have to die in order to grow.