Visual FoxPro is one of the easiest to use, most versatile programming languages of its time. Unfortunately, that time has now passed. Many businesses that rely on their Visual FoxPro (VFP) software are desperate for a suitable alternative. Ideally an alternative that’s easy to deploy with minimal disruption – and that’s priced realistically.
The Visual FoxPro story started at the height of the microcomputer boom, during the early 1980s. Created by Fox Software in 1984, its original incarnation was FoxBASE, a relational database application. FoxBASE was similar to other popular database management software like dBase II (which ran on CP/M and eventually DOS). While dBase II was popular at the time with programmers, FoxBASE quickly surpassed rivals by being easy to use and comparatively fast. In addition, FoxBASE could run on MS-DOS, Windows, and Mac which were becoming more popular with mainstream users than CP/M operating systems.
By 1989, FoxBASE had evolved into FoxPro. This was released under several versions, including FoxPro 2.x versions for MS-DOS, Windows 3.1, Macintosh, UNIX and Linux.
At its height of popularity, an estimated half a million developers used VFP to build software for a wide variety of clients and end users. FoxPro was among the first Rapid Application Development (RAD) tools, making it easy to create working apps with simple syntax and lightweight code. Although Visual FoxPro was built using C++, it didn’t require the use (or learning) of C++ to create remarkably complex functions with only the VFP syntax.
Like many of the fourth-generation programming languages (4GLs), VFP uses the open object protocol (OOP) based programming. This will be a familiar paradigm for developers who use Java, C#, Python, or VB.NET, with features like Classes, Objects, Variables, modular programming, procedures (and subroutines), and conditionals.
In 1992, Fox Software became part of the Microsoft family. When this happened, FoxPro’s name changed to include the word ‘Visual.’ This made it recognizably related to the Microsoft brand (which also owned Visual Basic). From version 3.0 onwards, FoxPro became known as ‘Visual FoxPro’ (or VFP to its friends).
After becoming part of the Microsoft family of products many assumed that it was now guaranteed a bright future and immortality, through the support of a IT heavyweight. However, this was not to be.
As a popular and easy-to-use programming language Visual FoxPro became widely used throughout the computer boom. It found its way into numerous key roles in business, government, and academic institutions. Despite its shrinking market share, Visual FoxPro is still relied on by numerous businesses and institutions today. It’s most common in the USA, due to the earlier adoption of microcomputers across multiple sectors and fields. Many countries that were slower to start adopting IT have effectively leap-frogged this stage, and gone straight to more advanced software based on Java or the .NET core, and cloud-based apps that use APIs.
Although developers are no longer actively developing new VFP software, many extant Visual FoxPro applications are still relied on for niche purposes in the Financial Services sector, in IT/software, Higher Education, and Local Government. It’s quite commonly used by many businesses that operate in complex sectors, especially where the raw data remains relatively stable and doesn’t need frequent updating. Construction, heavy industry, manufacturing, and retail are all areas of business where VFP is still used to perform core business functions, for example.
Visual FoxPro has many potential applications, due to the customizability of the language and relative ease-of-use. Many businesses have become reliant on their VFP-based programs. They’re a very cheap, yet reliable way to process basic information into meaningful business processes such as invoices, estimates, or orders.
Microsoft made its final update to Visual FoxPro in 2007 with Version 9, so this is the final version. Extended support for VFP has ended, and machines that can run the 32-bit software will become increasingly scarce.
Many might wonder why Microsoft no longer supports such a useful and versatile programming language, or why they didn’t port it to a modern .NET version. The reason, as with so many things in business, is money. Microsoft made a sound business decision to change their model from a purchase/license model to a subscription-based one.
It’s a more sustainable business model that hinges on a ‘fixed lifecycle policy’. According to this policy, all support for ‘bought’ and ‘volume-based’ license software is phased out over a minimum of five years. Extended support can be made available for a limited time for some products with large numbers of dependent users (including Visual FoxPro). However, this support ended for Visual FoxPro on Jan 13th, 2015.
Many business users find that the alternatives to Visual FoxPro just don’t offer the same flexibility, are prohibitively expensive. In the case of custom software development, a long development period to build is another layer of inconvenience and expense.
Anyone still using VFP for mission-critical processes is on borrowed time. In many cases, they’re using an air-gapped Windows XP laptop to run the 32-bit VFP application on-premises.
The number of businesses and institutions still using VFP is comparatively small. Once a market leader, VFP currently takes a 0.18% share of the market, while ‘relative newcomer’ PHP (made in 1995) corners 78.7% of the market. For this reason, developers are not keen to learn VFP, and there is little appetite for them to build a replacement using a .NET core or C#.
So, Visual FoxPro has reached its end-of-life phase. For many, this means their VFP programs are on ‘life support,’ and the clock is ticking until that point when a difficult decision must be made.
Microsoft made its final update to Visual FoxPro in 2007 with Version 9, so this is the final version. Extended support for VFP has ended, and machines that can run the 32-bit software will become increasingly scarce.
Many might wonder why Microsoft no longer supports such a useful and versatile programming language, or why they didn’t port it to a modern .NET version. The reason, as with so many things in business, is money. Microsoft made a sound business decision to change their model from a purchase/license model to a subscription-based one.
It’s a more sustainable business model that hinges on a ‘fixed lifecycle policy’. According to this policy, all support for ‘bought’ and ‘volume-based’ license software is phased out over a minimum of five years. Extended support can be made available for a limited time for some products with large numbers of dependent users (including Visual FoxPro). However, this support ended for Visual FoxPro on Jan 13th, 2015. This marked the beginning of the Visual FoxPro end-of-life stage – which has lasted a remarkably long time.
FoxPro alternatives are not easy to find. Many business users discover that the alternatives to Visual FoxPro just don’t offer the same flexibility or are prohibitively expensive. In the case of custom software development, a long development period to build a FoxPro replacement is another layer of inconvenience and expense.
Anyone still using VFP for mission-critical processes is on borrowed time. In many cases, they’re using an air-gapped Windows XP laptop to run the 32-bit VFP application on-premises.
The number of businesses and institutions still using VFP is comparatively small. Once a market leader, VFP currently takes a 0.18% share of the market, while ‘relative newcomer’ PHP (made in 1995) corners 78.7% of the market. For this reason, developers are not keen to learn VFP, and there is little appetite for them to build a replacement using a .NET core or C#.
So, Visual FoxPro has reached its end-of-life phase. For many, this means their VFP programs are on ‘life support,’ and the clock is ticking until that point when a difficult decision must be made. Read more about Microsoft support of FoxPro.
Let’s look at a typical situation of a business using Visual FoxPro, and see exactly what their options are.
Northwest Homes is a fictitious family-owned construction company that builds houses for middle-income families on greenfield and brownfield sites. Their iconic housing developments have become popular in the tri-state area, and are instantly recognizable by their old-style classic designs.
Northwest Homes is a modern business, using state of the art equipment and materials, but in the back-office their systems use an VFP-based program to create accurate costings for each project.
Data about each material (including length, thickness, gauge, grade, cost, etc.) are held in a DBF file, and their VFP program uses the data from each design to produce an accurate cost for each unit and send the orders to suppliers for the required materials. It even includes data like minimum order quantities, and how much wastage is involved when cutting.
Like many companies in their position, Northwest Homes is totally reliant on this one, critical piece of software to make sure their business can run lean and competitive.
However, time is running out. They need a modern solution, and ideally one that their agents can access via a web app or online portal. This would enable them to create estimates in remote locations, place orders, and update data more rapidly.
There are broadly two options available: use an ‘off-the-shelf’ solution or hire a developer to build a custom application that fulfills the same role.
The ‘off-the-shelf’ solution would clearly be best, except that there’s nothing that matches their exact needs. Licensing one and then customizing it is another route, but this would be cost-prohibitive.
The build-your-own approach will result in the perfect software for their needs, but it could be a risky and costly operation if not managed well. Many projects run over budget and are frequently delivered late. Sometimes they get even canceled before any results can be produced.
Perhaps the greatest worry for many users of VFP, and the reason they are seeking Visual FoxPro alternatives, is the issue of maintenance. Very few developers still use this language, making it hard to ensure that security is maintained and that the VFP software stays relevant to the rest of the business. In case this isn’t reason enough to find a FoxPro alternative, there is also the issue of hardware.
VFP runs on 32-bit; however, 32-bit operating systems are becoming less common. Although a 64-bit system can technically run 32-bit programs using the WOW64 x86 emulator, it has limitations and it’s not natively supported by Windows 11.
Running Visual FoxPro on older hardware is a ‘workaround’ that many businesses already use to address this, but it also brings risk. As older versions of Windows are also no longer being supported, the security risk becomes greater every day. Excluding the threat from malicious actors, older hardware is notoriously susceptible to stability issues over time as drivers become corrupted, components age, motherboards become full of dust and cooling fans stop working properly.
As Visual FoxPro is no longer being maintained, no new code is being added. This means that developers can only use ‘tricks’ within VFPs existing vocabulary. This makes innovation very difficult. As more businesses are starting to use web apps as part of their toolkits, users of FoxPro are at a serious disadvantage.
A lack of new functionality is certainly a major disadvantage to continuing to use FoxPro without either upgrading to a modern alternative, or by rehabilitating and extending the existing software using a modern solution like Servoy. Another issue is the built-in design limitations of Visual FoxPro. When VFP was last updated, a gigabyte database was considered a significant amount of data. As a result, VFP’s native database file (DBF) can only contain a maximum of 2GB. As businesses typically deal with much more data than they did before, managers must make hard choices about what data to store, or use a confusing array of DBFs. A business-worthy FoxPro alternative must be capable of dealing with both DBF and more modern databases like SQL, as well as connecting to additional data sources and apps.
The lack of support for Microsoft Visual FoxPro means that your VFP systems are on life support, and this cannot continue indefinitely. When businesses first deployed their customized VFP-powered software, times were different, and things worked differently. The business has changed, but the software hasn’t.
For too long, employees have had to tiptoe around this indigent and geriatric software, trying to get on with ‘business as normal’ without upsetting it – and that’s not right.
There are a lot of questions that make finding an alternative hard to even think about, like:
While we would always advise a client to use an ‘off-the-shelf’ solution when one is available, custom development is the ideal way to address the demands of the business. Many companies are aware that a custom solution is the ‘better option,’ but this can also be costly and will require some maintenance too.
At Servoy, we often have companies come to us after a failed development project that couldn’t deliver the promised modernization. Many of these custom development projects are still done using a bottom-up and/or a waterfall approach, which exhibits little business value upfront, takes an eternity to deliver, and often fails to address the core demands at the end.
To meet the demands of business today (and tomorrow too), a third approach is the best way to achieve the customizability and long-term stability and security. This approach is to use a powerful low-code platform to create a capable business application that can use the same functions and data sources as your existing VFP solution. You get all the added functionality and stability, without needing to compromise. This is the Servoy approach.
To create a replacement for Visual FoxPro, Servoy uses its proven low-code platform to develop capable business software based on well-supported industry standards and databases.
The priorities for businesses are profitability and continuity, so Servoy recommends starting by building minimum viable products by using a UX-first approach. This means that the business value, the user-experience, and core functionality are all present from the earliest stage. The Servoy Appsurance program is a guarantor of your success with your FoxPro upgrade project, as it makes certain that key targets are hit and that the entire project delivers results on schedule.
Servoy’s solution can talk to your current DBF files as well as modern SQL databases, meaning these can be combined to broaden functionality and enrich experiences. By using the Servoy platform, your ‘FoxPro upgrade’ can also connect to mobile apps, web apps, external applications, web services, email, files of any kind, as well as DLL, COM and .NET resources.
Developers find that the paradigm used by Servoy is similar to VFP, making it easier for developers to rapidly redevelop your VFP software to a modern alternative with more capabilities. Using the Servoy low-code platform to re-tool and upgrade your FoxPro software, your new software can become accessible via web browser, mobile, or web app. Because the user-experience is prioritized from the start, it’s easy to start using the FoxPro replacement – causing minimal disruption to business processes. Servoy isn’t an auto-migration tool, but it makes the transformation process much faster and is capable of delivering reliable results fast.
Servoy customers are often surprised to learn that this solution doesn’t come with a technology lock-in, which is so often found with a custom solution. Instead, Servoy is based on open-source standards that make it easy for your new Visual FoxPro replacement to be enhanced, maintained, and updated.
This means that your new software remains future-proof and easy to maintain, helping you focus on what you do best.
FoxPro (and later Visual FoxPro) is a programming language that enables developers to rapidly build functional software using data stored in FoxPro database files (DBF). It is no longer supported and is becoming obsolete.
Migration of Visual FoxPro to another programming language isn’t an easy matter, and often relies on the development of a custom solution. A better alternative is to rapidly build an alternative to FoxPro using a low-code platform like Servoy.
The best replacement for FoxPro is probably a low-code platform meant for large and scalable business applications. Servoy uses a similar paradigm to FoxPro, but is much more capable and can communicate with other programs regardless of language or protocol using APIs as a common connector.