The time has come. Your trusty custom VFP application has served you faithfully for years. But it’s getting harder and harder to find competent VFP programmers. So your company has decided to embark on a Visual FoxPro Migration, moving to a new custom software application. Are you wondering which way to go? Well, here are three different paths that you might want to consider:
1) Upsize your FoxPro application to a Website
Migrating your VFP code to a web-based solution can be challenging. Because websites behave very differently than desktop software. But this might be a great option if your workforce works remotely. When you choose this option, your salespeople and remote workers will be able to access data from anywhere in the world. And several web development platforms are available, including ASP.NET, Node and PHP.
Here’s another question to consider: which database should you use? Your answer will depend on several factors. First, how much data are we talking about? Will your project require an enterprise-level solution? Or can you start with something smaller? And keep in mind that some companies have written policies about databases. Does yours prefer open-source, or commercially-developed databases? The three most popular databases our customers have chosen recently are:
- SQL Server – a relational database server from Microsoft
- PostgreSQL – an open-source relational database management system (RDBMS) which emphasizes extensibility and SQL compliance. It has been growing in popularity over the past several years.
- mySQL – another very popular open-source RDBMS
(If you’d like a detailed list of relational databases ranked by popularity, check out db-engines.com)
2) Migrate to C#.NET
Microsoft stands behind C#.net, its desktop platform. C#.NET offers all the user-friendly desktop features you love in your custom VFP application. Plus, it adds more cool bells and whistles than ever before. When you migrate from one desktop application to another, the form layouts and reports will look very familiar to end users. So your company won’t have to spend a lot of time retraining users.
If you go this route, we recommend migrating the VFP databases to SQL Server (or SQL Server Express). Why? Because C#.net is tightly integrated with SQL Server. Opting for a different database is possible, but might take more time to program.
3) Stagger Your VFP Migration
Migrating Visual FoxPro apps can take a lot of time and resources. And if the source code spans hundreds of thousands of lines, it might take even more time. That’s why several of our customers prefer to divide and conquer. That is, they break their project out into phases.
Phase 1 usually involves redoing the user interface so that it talks to SQL Server rather than VFP tables. This phase includes several smaller steps, including:
- Remapping every database transaction
- Normalizing database tables
- Adding primary/foreign keys
- Adding CursorAdapters, special data classes which help make the transition to phase 2 much easier
Phase 2 often comes months–or years–later. This phase involves migrating the user interface to another platform. Often this will be C#.NET, or ASP.NET. But Node or PHP are other possibilities.
Staggering the migration over a longer time frame gives you the added advantage of staggering the cost as well.
The prospect of a Visual FoxPro migration can be overwhelming. Since this can be a complicated process, it often makes sense to create a Systems Design Specification which fleshes out your project in much greater detail.
If you’d like to get objective, unbiased input about your VFP migration, feel free to contact us. We’ll be happy to discuss your unique situation, your goals, and your timeline. And the first hour is always free.