Microsoft quit their support of FoxPro around OS Vista in 2007, but has now announced their mainstream support of Windows 10 will end this October. Since then, we have had an uptick in inquiries about Visual FoxPro conversions and migrations. In the next two blogs we’ll look at the specific questions we are getting and include our opinion. We will follow up with a second blog that gives our recommendations.
Why You Don’t Want to Do a FoxPro Migration
It might be tempting to migrate your FoxPro applications to a modern platform. And if there was a viable solution to automatically do that, it would be a beautiful thing. However, that solution does not exist in reality. The automation techniques out there simply do code-generation and leave you to clean up the mess. And by the way, you’ll need to learn .NET in the process.
Another reason not to migrate your Visual FoxPro (VFP) apps to another platform is that without sufficient in-house capability, businesses must hire expensive consulting to rewrite, test and deploy the application (most of these apps have extensive and complex business logic too).
VFP End of Life Is Not the End of the World
VFP end-of-life is not the reason you should be modernizing. Yes, your application could “explode” tomorrow. A Windows update could irreparably break it, but the chances are high that it won’t.
Our experience with companies across the world that have modernized parts of their product suite shows that they are in large part still confident in their legacy systems for three big reasons. They have:
- Full control over their stack
- In-house expertise to work-around challenges to keep VFP running
- Domain knowledge that outweighs any technology decisions
Don’t Migrate, Modernize VFP
You don’t want to migrate your VFP application…that is, unless you have a lot of time, energy, and money to spend. However, there are compelling reasons to modernize that make sense from the larger business application economy. These days, you have to keep up with the competition that’s offering apps with a rich UI, web & mobile versions, and the ability to integrate with many platforms and cloud service providers. Modernizing your app may also bring:
- Cost savings on redundant hardware, terminal services licensing, windows licensing
- Cost savings and flexibility for on-premises deployments
Recommendations on Modernizing Your FoxPro Application
In the previous blog, we mentioned why modernizing is better than migrating your FoxPro app. Based on our experience with clients dealing with this dilemma, here are our recommendations.
Scenario 1: For in-house applications, where UX matters more than UI, you should consider the following options:
- Virtualize your application. Try using remote desktop or terminal services to “deploy” the application. This comes at a cost in terms of deployment, but the benefit is that you don’t need to immediately redo the application, which eliminates risks.
- Migrate customer-facing or other critical parts to a browser-based application. Use a minimal viable product (MVP) approach to do this migration. There may be some cases where it makes sense to leave your data in the DBF format, but at some point you should consider migrating or syncing to a SQL database.
- If your application has many screens or reports and not too much complex business logic, consider an automated conversion. It’s important to note that this is not something we typically advise people to do since the “80/20 rule” often ends up applying here. This is where 80% of the conversion goes smoothly and seamlessly, but that last 20% involves time-consuming clean-up. Another downside is that from a UI perspective, you end up with the same “legacy” look and feel. Last but not least, you are converting very old (sub-optimal) code that would perform better if written from scratch.
Scenario 2: For software vendors that need a competitive application, (that is, where UI, UX, and business logic are crucial) here are some important considerations.
This might be a good point to consider doing a complete rewrite from scratch and go to the cloud and create a mobile app option. It’s important to make sure you can still deploy on-premises for government or large enterprise clientele that demand hosting on-site for security reasons and such. This still requires an MVP approach creating your application on a module-by-module basis. In other words, to ensure success, try to avoid a “big-bang” approach as much as possible.
- Avoid a DIY approach and use a RAD environment that feels like your current VP setting, in order to leverage your existing resources and talent as much as possible.
- Reduce your risks by not using a piece-meal approach. Don’t start bottom-up by migrating your DBF database first. (This will come later.) Instead, try to find commercially viable pieces first, where you can involve (new or existing) customers and understand what features are important to them from the very start. As you continue, you can get continuous feedback (reducing risk and ensuring buy-in) and maybe even some additional revenue while you are at it.
- Pick a future-proof language. Don’t get caught in the trendiest code of the moment–remember, what was hot last year may not be so hot in a couple of years. (Think Ruby on Rails, PHP, and others.) might be “old” this year (node.js, React, etc). Also don’t confuse UI tool selection with strategy. Yes, it’s cool to talk about the latest UI tool, but what’s popular today is often quickly obsolete tomorrow. You need to move forward thinking about if a component can be swapped out seamlessly.
- Keep in mind what’s best for your company. For developers on your team, there is nothing cooler for them to add “full-stack developer” on their resume. However, while this may be beneficial for them, it can often be interpreted negatively against your company as being slow in productivity as well as time-to-market.