Visual FoxPro has been without official Microsoft support for more than a decade, yet companies still run applications built with the platform to manage billing, inventory, orders, accounting, and internal business processes. That persistence becomes less surprising once its history is understood. FoxPro was remarkably effective at building database-driven business applications, and over the years those systems accumulated something far harder to migrate than their DBF files: the business rules of thousands of organizations.
The FoxPro story in 30 seconds
- Fox Software turned FoxBASE and later FoxPro into major competitors to dBASE during the 1980s and early 1990s.
- Rushmore used indexes to accelerate certain queries and helped establish FoxPro’s reputation for performance.
- Microsoft announced its acquisition of Fox Software in March 1992, in a deal valued at roughly $173 million at the time.
- Visual FoxPro 9 was the final major release, and extended support ended in January 2015.
- Many applications survived because migrating them means rebuilding code, data, and decades of business rules.
The story also challenges a long-standing explanation: Microsoft did not acquire FoxPro in 1992 and immediately shut it down. After the deal, the company continued developing it, brought FoxPro further into Windows, and released several generations of Visual FoxPro. The real problem came much later, when Microsoft’s development strategy increasingly centered on .NET, Visual Studio, and SQL Server.
That created a situation many system administrators know well: a product can lose its commercial future long before the applications built with it stop being useful.
From Competing With dBASE to Building Complete Business Applications
Understanding FoxPro requires going back to a very different era of business computing.
During the 1980s, building a management application did not necessarily require a separate SQL server, an API, a backend, and a frontend.
A database could live directly in files stored on a PC or local network. Developers could then build screens, reports, queries, and business logic around those files.
dBASE became one of the defining products of that generation.
Its importance eventually extended beyond the product itself. Its commands, DBF file format, and programming conventions helped create a family of compatible database languages and tools generally known as xBase.
Fox Software entered that market with FoxBASE.
Led by Dave Fulton, the company focused on maintaining compatibility with applications and skills from the dBASE environment while placing particular emphasis on performance.
That approach reduced one of the biggest barriers to migration: starting over.
Developers could preserve much of what they already knew, while organizations could continue working with existing data as they moved to a different tool.
Fox Software eventually evolved FoxBASE into FoxPro.
One of its best-known technical advances was Rushmore, a query optimization technology introduced with FoxPro 2.0.
Its basic principle remains familiar to database administrators today: use available indexes to avoid unnecessarily scanning every record in a table.
If an application contained hundreds of thousands of invoices and needed to find those belonging to a particular customer, a suitable index could dramatically reduce the amount of work required.
Rushmore did not automatically fix poor database design. Indexes still had costs, and queries needed to be structured in ways that could take advantage of them. But the technology helped establish FoxPro’s reputation as an exceptionally fast platform for working with local data.
Fox Software’s growing success also led to a major legal battle.
Ashton-Tate sued Fox Software for copyright infringement involving dBASE. The case eventually became complicated for Ashton-Tate itself.
In 1990, a US court found that the company had failed to disclose material information to the Copyright Office concerning the relationship between dBASE and JPLDIS, public-domain software developed at the Jet Propulsion Laboratory. The court invalidated the dBASE copyrights involved in the litigation and dismissed the corresponding claims.
The case should not simply be summarized as “Fox copied dBASE and won.” The litigation dealt with specific questions surrounding copyright, derivation, and the information provided when those copyrights were registered.
Microsoft Paid Around $173 Million and Kept Developing FoxPro
The next major change came in 1992.
Microsoft and Fox Software announced on March 24 that they intended to merge. Contemporary reports valued the transaction at approximately $173 million in Microsoft stock.
For Microsoft, the acquisition provided an immediate and substantial position in the personal-computer database market. For Fox Software, it meant joining a company that was turning Windows into the dominant PC platform.
The acquisition did not end FoxPro.
Microsoft continued developing the product, and in 1995 it released Visual FoxPro 3.0, adapting the platform to graphical Windows application development.
Visual FoxPro was attractive because it brought together many of the components needed to build a business application.
Developers had a programming language, database engine, forms, queries, reporting, and development tools inside the same environment.
For small businesses and independent developers, that could significantly reduce the number of separate technologies required to deliver a finished application.
A retailer could use it for inventory and billing. A distributor could build an order-management system. A small manufacturer could track production, suppliers, parts, and deliveries.
Developers could then modify the application whenever a customer developed a specific requirement.
That flexibility is also part of the reason these systems can be so difficult to replace today.
A business application maintained for 15 or 20 years stops being merely an executable connected to a collection of tables.
It begins accumulating exceptions.
One customer receives a special discount. A particular product can be sold without stock under specific conditions. A report calculates commissions using an old formula. Accounting requires a particular export because another process still depends on it.
Thousands of small decisions eventually become embedded in the code.
The application effectively becomes executable documentation of how the company operates, even if nobody originally designed it for that purpose.
Visual FoxPro Ended, but Its Applications Did Not
By the 2000s, the software market was changing.
Business applications were moving toward client-server architectures, web services, browsers, and centralized database servers.
Microsoft was also building a different development strategy.
.NET provided a common platform for multiple programming languages, Visual Studio was becoming Microsoft’s central development environment, and SQL Server was taking an increasingly important position in the company’s enterprise data strategy.
Visual FoxPro could connect to remote databases and work with some of these technologies, but it still maintained its own language, runtime, tools, and developer community.
Microsoft released Visual FoxPro 9 in December 2004. It would become the final major version.
In 2007, the company confirmed that there would be no Visual FoxPro 10. The Sedna project later provided components intended to improve interoperability with newer technologies, but it was not a complete new generation of Visual FoxPro.
Mainstream support for Visual FoxPro 9 ended in January 2010, while extended support ended on January 13, 2015, according to Microsoft’s official lifecycle documentation.
Then something happened that is very common with legacy systems: almost nothing.
The applications did not suddenly stop launching.
DBF files did not disappear.
Billing systems continued generating invoices.
The end of vendor support and the operational death of an application are two entirely different events.
A company can keep a legacy system running as long as it continues to work on available versions of Windows, people remain capable of maintaining it, and its external dependencies do not change too dramatically.
The risks accumulate gradually.
Every operating system update requires more testing. Every integration with a modern service may require additional workarounds. Every specialist developer who retires or moves on reduces the amount of available knowledge.
And then comes the hardest problem: migrating FoxPro usually means much more than converting DBF tables into SQL Server, PostgreSQL, or another modern database.
The organization first needs to discover what the application actually does.
That includes code, queries, reports, permissions, calculations, and processes that may never have been properly documented. It can also include behaviors users have learned over many years.
For that reason, some organizations keep these applications inside controlled environments. Others first move the data to a SQL server while temporarily retaining FoxPro as the frontend. Some replace individual modules progressively instead of attempting a complete rewrite.
There is no universal strategy.
A small departmental application may be relatively straightforward to replace. A custom ERP system developed and modified over 25 years may contain millions of lines of code and an unknown amount of embedded business logic.
That is why FoxPro still appears inside companies decades after its peak.
It did not survive because Microsoft continues to develop it.
It survives because the cost of replacing business software depends less on the age of its programming language than on how much organizational knowledge ended up encoded inside it.
Microsoft did not eliminate FoxPro immediately after acquiring Fox Software. It developed the platform for more than a decade and later chose to direct investment toward other technologies.
The result is one of the more interesting examples of legacy software: an officially discontinued development platform whose real lifespan has been determined by the applications developers built with it.
And as long as those applications continue to perform processes a company needs every morning, some Visual FoxPro window is likely to keep opening on Windows long after the product that created it disappeared from Microsoft’s roadmap.
Frequently Asked Questions
Did Microsoft buy FoxPro just to kill it?
The historical record does not support that simplified interpretation. Microsoft acquired Fox Software in 1992 and continued developing FoxPro for years, including several generations of Visual FoxPro.
How much did Microsoft pay for Fox Software?
Contemporary reports valued the 1992 acquisition at approximately $173 million in Microsoft stock. Microsoft officially announced its intention to merge with Fox Software on March 24, 1992.
What was the final version of Visual FoxPro?
Visual FoxPro 9 was the final major release. Microsoft never developed Visual FoxPro 10, and extended support for version 9 ended in January 2015.
Why are FoxPro applications still running?
Many contain years or decades of business rules, reports, processes, and customizations. Replacing them may require rebuilding not only their data structures but also operational knowledge that sometimes exists only inside the source code.