Article summary
Kicking off the development of a new software product is a fun and exciting process. Creativity flows like an uncapped fire hydrant and the dream of “what could be” starts to solidify and come to fruition. Of course, not every software project that gets funded involves an exciting new product build.
In many instances, a software project involves replacing an existing application that is critical to business operations but that’s no longer viable for one reason or another. These projects often aren’t as flashy or exciting and, in many cases, don’t offer any promise of increased revenue in the short term. But they’re critical to the business nonetheless.
Over the years, we’ve helped many clients who are in this position. In recent years, we’ve seen an uptick in clients who have a legacy Visual FoxPro app and need our help replacing it. If you find yourself in that position, this post is for you.
Visual FoxPro
Visual FoxPro (VFP) is a programming language that started picking up popularity in the early 90s. Its original name was FoxPro but it picked up the “Visual” prefix when Microsoft acquired it and took over the technology in 1992. In 2006, VFP reached its highest ranking, 12th place, in the TIOBE index of most popular programming languages.
VFP is tightly coupled with a relational database. This made it a flexible and powerful tool for building all sorts of applications including desktop, middleware, and web apps. This tight database coupling is likely also a major factor (among others) that led to the language’s demise. This is because Access databases became the clear preference of power users in the Microsoft ecosystem.
In 2004, Microsoft released version 9 of Visual FoxPro, which turned out to be the last major release. In 2007, they announced their plans to kill the product, and on January 13, 2015, all support officially ceased.
While Microsoft axed support for VFP more than seven years ago, it’s clear there are a great number of businesses that still rely on a Visual FoxPro app. While they may be able to limp along, for the time being, savvy business leaders are prioritizing modernization projects and planning for the future.
Choosing a Path Forward
Before selecting a technology partner or writing a single line of code, you should ask yourself, “Is rebuilding a custom app the right answer?” Chances are, if you’re considering modernizing a VFP app, your legacy app is decades old. There’s a real chance you could now find an off-the-shelf application or combination of applications to perform the task of your legacy app. Capterra is a great resource for discovering off-the-shelf software solutions.
Transitioning to off-the-shelf software will almost certainly save you money in the short term versus going fully custom. However, in exchange, you’ll get less control and less flexibility. You may have to alter your business operations to better align with the out-of-the-box functionality. This post by Atomic’s co-CEO, Mike Marsiglia, is a great resource for anyone navigating the build vs. buy decision.
Is Modernizing a VFP App Unique?
Any application rewrite or modernization project is going to be a significant undertaking. When compared to greenfield projects, these types of projects tend to be lengthier, more expensive, more complex, and more difficult to estimate. Atoms have written extensively on the topic:
- Why Software Rewrites Often Fail – and How “User Goals” Can Fix Them
- The Non-Technical Challenges of Rewrites
- Don’t Wait to Modernize Your Custom Software Application
- and many more
But, Visual FoxPro app modernizations come with an added challenge. As previously mentioned, VFP was designed with an integrated database engine. This pattern is uncommon in modern application architectures. That means that there will likely be a much greater delta between the old and new applications.
Given the time it takes to execute a modernization project and the significant risks involved to the business, we always recommend building up the new application alongside the legacy application. It’s also important to create infrastructure to keep the two systems (databases) in sync with one another until the team builds all the required functionality and the new system has been thoroughly and incrementally verified. One of Atomic’s Tech Leads, Jason Porritt, outlines several variations of this approach in his blog post series, Strategies for Data Synchronization on Rewrite Projects.
The integrated VFP database makes this approach extra challenging, but it’s not impossible. Joe Chrysler explains how to do it in his post, How to Extract Data from a Legacy Visual FoxPro Application.
Choosing a Partner
There are a lot of great consultancies out there that can build high quality, robust applications that will set you up for success in the future. When selecting a technology partner for a VFP modernization project, I would look for these three key attributes:
- Significant experience with modernization projects (rewrites)
- Demonstrated expertise with Visual FoxPro
- Strong consultant mentality
The combination of these three attributes will increase your chances of success on a technical level and a project execution level. They will also help you realize additional returns on your investment by pointing out opportunities to save costs and capture low-hanging fruit along the way.