What Is FoxPro and What Should You Do If Your Business Still Runs on It?

Updated

FoxPro is a database and application development system that Microsoft acquired with Fox Software in 1992 and later extended as Visual FoxPro (VFP). It was widely used to build business database applications because it combined a fast local database engine, a forms and reporting layer, and a programming language in one desktop tool. Microsoft ended development and support for Visual FoxPro years ago, so the practical question for a business still running one is not "what is FoxPro" but "what do we do with this application now." The short answer: keep it running only with deliberate risk management, and plan a migration when the application is business-critical, hard to staff, or blocking integration with current systems.

What FoxPro and Visual FoxPro actually are

FoxPro began as a database product for DOS, then moved to Windows. Visual FoxPro added a visual design environment: you built forms, reports, menus, and data tables in a graphical IDE, and wrote logic in the FoxPro language (often called xBase). Key traits that made it popular:

  • Self-contained data engine. Tables, indexes, and the database container lived as files on disk or on a file share, so a small team could ship a working business application without a database server.
  • Rapid application development. Forms, grids, and report writers let developers build data-entry and reporting screens quickly.
  • Client/server reach. VFP could connect to Microsoft SQL Server and other backends through remote views and SQL pass-through, so it was used both as a standalone desktop database and as a front end to a server database.
  • Large installed base in line-of-business software. Inventory, accounting, job tracking, membership, and similar internal tools were commonly written in FoxPro.

That combination is why so many small and mid-sized businesses ended up with a FoxPro application at the center of their operations.

Current support status and the real risks

Microsoft stopped shipping new versions of Visual FoxPro and ended support for it. That has concrete consequences, not just a label:

  • No security patches. Any vulnerability in the runtime or the language libraries stays unpatched. This matters most when the application touches the network or the internet.
  • Operating system drift. Each new Windows release is a compatibility question mark. A FoxPro application that runs today may break or behave differently after an OS upgrade, and there is no vendor to call.
  • Staffing scarcity. Developers who know VFP well are retiring or moving to other stacks. Finding someone to fix a bug or add a feature gets harder and more expensive every year.
  • Integration friction. Modern requirements — APIs, cloud services, web or mobile access, single sign-on, modern reporting — are awkward or impossible to meet from inside a legacy VFP application without building bridges.
  • Data access and concurrency limits. File-share-based tables degrade under concurrent use and are fragile over wide-area networks and VPNs.

None of this means the application stops working tomorrow. It means the risk profile rises over time, and the cost of waiting is usually paid in an emergency rather than on a schedule.

Your three realistic options

Option What it means Best when Main downside
Keep maintaining Retain the VFP application, patch around problems, keep the environment frozen The app is stable, low-risk, and not central to growth Rising staffing and compatibility risk; no security fixes
Modernize in place Keep the FoxPro front end but move data to a server database (for example SQL Server) and add integrations The UI still fits the business and the data layer is the weak point Still carries the unsupported runtime; a partial fix
Migrate or replace Rebuild the application (or buy a package) on a current stack The app is business-critical, hard to staff, or blocking integration Highest upfront cost and effort; needs careful scoping

A common middle path is to migrate the database first and the application second: move the data to a supported database, keep the FoxPro client working against it, then replace screens and reports in stages. This reduces the risk of a single big-bang cutover.

How to assess an existing FoxPro application before deciding

Work through these questions and write down the answers. They drive the decision more than any general rule.

  1. What does it actually do? List the business processes it supports and who depends on it daily.
  2. Where does the data live? Local DBF files, a file share, or a server database? This determines how hard migration is.
  3. How much custom logic is in it? Reports, calculations, and business rules embedded in the code are the expensive part to reproduce.
  4. What integrations exist? Exports, imports, email, file drops, and any connection to accounting, ERP, or web systems.
  5. Who can maintain it? Do you have a developer, an internal person, or a vendor? What happens if they leave?
  6. What is the failure cost? If the application is down for a day, what stops? This sets how urgent migration is.
  7. What is forcing change? An OS upgrade, a security review, a new reporting requirement, or a growth plan. A concrete trigger makes the business case.

If the application is peripheral and stable, maintenance may be a reasonable holding pattern. If it is central and you cannot staff it, treat migration as a project with a timeline, not a someday task.

Where custom software developers fit

This is the kind of work custom software firms do: they read the existing FoxPro code and data model, document what the application does, and rebuild it on a supported stack — often a modern database plus a web or desktop front end — while preserving the business rules that took years to get right. The value is not just rewriting code; it is extracting the logic and data relationships from a system whose original authors may be gone.

When evaluating a developer or firm for this, ask for:

  • A discovery phase that produces a written inventory of screens, reports, and business rules before any rebuild.
  • A data migration plan with a rehearsal and a rollback path.
  • A staged delivery that keeps the business running during the transition.
  • Experience with legacy database applications specifically, not just general web development.

Information Technology Associates, for example, describes itself as specializing in the design, development, and support of mission-critical business software applications, which is the profile of a firm you would approach for this kind of legacy assessment and migration work. The right question to ask any candidate is how they would keep your operation running while the old system is still in use.

A practical next step

Pick one concrete trigger — the next Windows upgrade, a security review, or a reporting requirement the current system cannot meet — and use it to justify a short assessment. The output of that assessment should be a one-page decision: keep, modernize, or migrate, with a rough cost and timeline for each. That document is what turns "we still run FoxPro" from a standing risk into a managed plan.