··· HISTORY ···
··· ANATOMY ···
After 23 years of working on dozens of FoxPro apps for clients of all sizes, I’ve noticed a similar pattern over and over:
Client has one large VFP application – 150K to 1M lines of code, 100+ native and/or SQL/Oracle tables, dozens of forms and classes, 100+ reports
The app core was initially created by one person about 20 years ago – who was its driving force, but since have moved elsewhere
The app was gradually upgraded through multiple FoxPro/VFP versions and now resides in VFP 6,7,8 or 9
The app usually connects to MS SQL or Oracle, despite its native tables
The app has hundreds or thousands of in-house/external users
No one particular person is familiar all of the app’s business logic
The app has been updated, maintained and fixed by a number of employees and consultants over the years
The app still looks like it was made in 1997
The app is very poorly documented or not documented at all
The code comments are seldom and sporadic
Client has attempted to migrate from VFP at least once, using local or offshore resources and still is in the middle of migration or has failed
··· CHALLENGES ···
So, why is it so hard to migrate from FoxPro? Well, FoxPro is a database-oriented Rapid Application Development (RAD) platform, so the nature of its code is quite specific and is unlike anything else. Below are the two most popular migration approaches:
Approach #1: Gathering specs from code
Front-end, back-end, business logic and reports are all part of one system. Even though the code is broken into logical blocks – it is also intertwined between different layers of the application, which allows for rapid development
Due to rapid development nature of FoxPro, the application grows to very large proportions quickly and without proper design/planning
Due to mixture of layers it is very hard to extract business logic from the code and stored procedures (if SQL/Oracle is involved)
Since FoxPro is a database-oriented language, data calls / processing (native or external) are present in about every procedure, function and method, making it near impossible to move it into a separate layer
FoxPro frameworks (e.g. Visual FoxExpress, Visual Extend, Visual ProMatrix or in-house) are very popular. Frameworks add an extra layer of complexity to the application.
It becomes increasingly difficult to locate qualified FoxPro developers, as over 99% have retired or moved on
Approach #2: Gathering specs from users
Users possess knowledge within their specific areas of the application. There’s a very small chance that there is a “superuser” that knows the whole system inside and out. The application is simply too vast.
The only “superuser” would be the application creator, but he has likely moved on and is not currently reachable on a full-time basis. Even if the application creator would be available, he would not know all the new features added to the application over the years.
A FoxPro BA analyzing the app would have hard time representing the business logic/process workflow in some “pseudo-language”, as that code would resemble FoxPro code one-to-one. That would beg the question – why write specifications at all?
Using workflow diagrams to document business logic/processes would be very time consuming and fruitless as well – due to complexity. It would create more confusion and questions than anything else.
Even if business logic is somehow collected and/or extracted from code, the client would still have to redesign the whole app: front-end, reports and possibly the back-end (with exception of where the most of data has already been moved to SQL/Oracle). The front-end is always highly outdated and sometimes inconsistent, as many developers “enhanced” it over the years without a coherent plan. The reports are limited by the capabilities of FoxPro’s own built-in viewer.
··· WHY MIGRATE? ···
FoxPro offers lots of advantages – however, in the modern world, it also lacks some potentially crucial features:
One FoxPro developer can handle front-end, back-end and reporting from the same IDE. No need to get front-end, back-end and design teams involved. This is a great cost saver for maintenance and enhancements
Users experience fast (“snappy”) interface, since FoxPro programs are always desktop (not web), highly-integrated applications
Visual FoxPro offers ultra-fast database engine with Rushmore optimization and aggressive usage of cache – one of the best on the market, even today. All the SQL, XML and text IO data processing are done blazingly fast. Moreover, VFP can handle very large databases
VFP apps can relatively easily handle hundreds of users simultaneously
FoxPro apps are highly portable – the installation just needs an executable and basic DLLs
FoxPro apps could be distributed free of charge
No official support from Microsoft as of 2015
Uncertainty of VFP functionality in the future
Inability of VFP working on 64-bit OS (without recompiling its kernel)
Inability of VFP working on the web natively. There are many techniques to “webify” VFP, but none of them are straightforward or effective
Lack of mobile app development platform (e.g. for iOS/Android)
Highly outdated user interface
Lack of enterprise-level security and scalability
··· SERVICES ···
I will provide your company with an initial and ongoing consultations that could save you millions of dollars and years of frustration. Whether you are thinking about FoxPro migration or already actively working on it, these consultations are surely to prove to be absolutely invaluable. Over the years I’ve seen many companies of all sizes continuously make poor decisions in this regard. Collectively, just some of my clients who initially did not consult with me wasted over 300 men/years and tens of millions of dollars in migration costs and ended up with a worse application or no application at all.
All the work will be performed remotely, so I would need full access to your application. We can sign a NDA (Non-Disclosure Agreement). Whether it takes me 10, 100 or a 1,000 hours to get your company on the right track, I charge a flat rate of $175/h. My services are in high demand, so I can provide consultations in accordance with my current bandwidth. I will outline my current availability prior to commencing. Below are some highlights of my services:
Provide a comprehensive report with detailed analysis of all FoxPro assets (e.g. databases/tables, forms, classes, reports, etc.) for your company’s application
Provide a comprehensive report with detailed analysis of all non-FoxPro technologies (e.g. frameworks, libraries, ActiveX controls, etc.) that work in conjunction with FoxPro to make your application run
Identify all the weak points, challenges and potential issues in migration of your FoxPro application
Identify the neccessary project management, business analysis, design, development and quality assurance human resources for the most streamlined and cost-efficient migration of your application
··· ABOUT ···
Timothy J. Maxwell
I have been programming computers for 32 years with 23 years in FoxPro and Visual FoxPro. Over the years I’ve participated in every aspect of FoxPro migration from design to writing specs to development to quality assurance. I’ve seen many attempts of FoxPro migration to a variety of technologies utilizing all combinations of local, distributed and offshore resources.
All of that experience coupled with my business and financial background allows me to evaluate systems quickly and efficiently and choose the right direction for your application.
··· CLIENTS ···
Over the years, I have consulted dozens of companies of all sizes (from 12 to nearly 300,000 employees) in many industries. Most clients, interestingly, have been in either financial or healthcare field. I think that’s because FoxPro is particularly well suited for those business sectors. Some of the recent clients are shown below:
··· FAQ ···
I’ve been often asked to talk or write about the future of FoxPro. Below are some of the most frequently asked questions I receive:
A. It depends on a number of factors. However, one very rough rule of thumb would be – $10/line of code. So, an 300,000 line (PRGs, SCXs & VCXs) app would cost approximately $3.0 million (including testing & UAT). However, this implies great planning and near perfect execution.
A. No. All major FoxPro applications are extremely custom. I’ve never seen a replacement software that would offer more than 30% of required functionality, which would make it completely unusable.
A. No. While you might be able to convert some forms / reports, the functionality will not be converted properly, interface will still look outdated and you’ll end up in a technology that wouldn’t bring any benefits anyway.
A. No. As long as you keep upgrading your hardware and software, but the Windows OS version on your PCs is still fully compatible with the 32-bit applications, your FoxPro program should function fine (with minor exceptions).
A. No issues for the most part. I’ve run a lot of tests and the only potential issues could be some printing problems, third-party DLL registrations and other quite rare cases.
A. Yes, using Chinese unofficial C++ compiled 64-bit VFP “version 10” kernel.