Your Visual FoxPro application still opens every morning and still does the job. That is exactly why the risk is so easy to ignore. "It works" and "it is safe" are two different statements, and the gap between them widens every year Microsoft leaves the product untouched.
Here is the plain version, with the dates that matter.
The support timeline is not ambiguous
Microsoft shipped the last version of Visual FoxPro, VFP 9.0 Service Pack 2, in 2007, and announced the same year that there would be no version 10. Per Microsoft's published product lifecycle, extended support for Visual FoxPro 9.0 ended on January 13, 2015. Since that date there have been no security patches, no bug fixes, and no official support of any kind. That is more than a decade of an internet-connected world moving on while the runtime stood still. Our own end-of-life guide walks the full timeline.
What "unpatched" actually means
A supported product gets a fix when a vulnerability is found. An end-of-life product does not. When a flaw is discovered in the FoxPro runtime, its ODBC and OLE DB drivers, or a common ActiveX control your forms depend on, no fix is coming. The window never closes. Attackers know which software is abandoned, and abandoned software is a preferred target precisely because the defender cannot respond.
- No runtime patches. A memory-safety or parsing bug in the VFP runtime stays open forever.
- Aging data drivers. The connectors that move data in and out of DBF files are frozen in 2007.
- Third-party controls. Many VFP apps rely on OCX/ActiveX components that are just as unsupported.
The compliance problem you may not see coming
Even if nothing is ever exploited, running end-of-life software is increasingly a finding in its own right. Auditors for PCI DSS, HIPAA, SOC 2, and cyber-insurance renewals routinely flag unsupported software as an unacceptable control gap. "It has not been breached yet" is not an answer an auditor accepts. More companies are discovering the cost of VFP not through an incident, but through a failed audit or a declined insurance policy that stops a deal.
The quiet risk: the most common way a FoxPro system finally forces a decision is not a dramatic hack. It is a compliance questionnaire, an insurer's checklist, or a customer's security review that will not sign off on unsupported software.
The single-expert risk sits on top of all of it
Security is not only software. It is people. Most FoxPro systems are understood by one or two developers, often nearing retirement. If that person is unavailable when something breaks, you are exposed on two fronts at once: an unpatchable runtime and no one who can safely touch it. That combination is how a manageable modernization turns into an emergency.
What to do instead of waiting
You do not have to replace everything overnight, and you should not. The lowest-risk first move is to get the application honestly assessed and to start with a read-only data layer, so modern, supported systems can reach your data while the FoxPro front end keeps running. From there the work phases in deliberately, on your schedule, instead of under duress.
Bottom line: Visual FoxPro running is not the same as Visual FoxPro being safe. The runtime has been unsupported since 2015, the compliance pressure is rising, and the expertise is thinning. The safe move is to start the transition while it is still your choice.
Want to know exactly where your application stands? Our free assessment gives you a clear-eyed risk and modernization picture, with no obligation.