By Ghulam Nabi Shah | August 3rd, 2022 |
This is my shortest note so far, but it is my most important one in every way. Here is the synopsis of the challenge I want to present to you.
“If you are a midsized company and have a VFP application, then NOW is the time to convert it to a .Net framework (or other such), and my company, MACROSOFT, is the only company you should consider to partner with you in doing the conversion.”
I am not trying to engage in marketing hyperbola in this note. Instead, I am trying to stay as fact-based as possible. Below are some genuine facts which I found. I am writing this note to encourage you to finally decide and see how you can successfully get off of VFP.
Believe it or not, there are still a ton of working (and often critically important) VFP applications in the IT infrastructure of many mid-sized companies. The VFP applications work well and span the range of VFP tools from VFP.9 to some of the oldest possible tools, including DOS VFP. Many have multiple tools (external libraries), making conversion even more complicated. And the fact is these tools generally work successfully to do the job they initially developed.
In the general estimate of the addressable market worldwide, there are at least 1000+ applications out there still with 500,000 or more lines of code, meaning a total of 500 million lines of code. I believe this to be a minimum estimate, and there could be ten times this estimate.
I do not include in this estimate the small applications run in small companies for which the current system does the job, and there is no need or the necessary resources to do a conversion. In many of these situations, a dedicated VFP developer continues to improve and enhance the VFP application as much as possible. But for a growing mid-sized company, this is not a tenable position to be in.
For any mid-sized company (say about $50 – $500 million range or higher), it is clear that the VFP will have to go now or in the next 3 to 5 years for sure. While VFP has been a magnificent tool and has led to tremendous productive systems, its time has come and gone for mid-sized companies. It cannot keep holding its place going forward.
There are so many reasons it is no longer suitable for thriving and growing companies to keep large VFP applications in the mix doing essential business functions. We all know the causes, and I will not dwell on them in this note: security, cloud, web, new features, new operating systems, dearth of developers, and so on. Macrosoft’s website has many recent papers on the benefits of the conversion from VFP to a .Net framework.
And, of course, we all know that a VFP system playing an important role for a company will be a show-stopper for any type of process, financial audit, or possible merger or acquisition. It is often too late to deal with a conversion at such a time since the transformation of sizable applications will take approximately 12 months or longer.
Macrosoft is the only global company that can partner with you on a successful VFP conversion. We have the methodology, intensive in-depth know-how, and a growing suite of automation tools that make large (on the order of 500,000 lines of code or larger) conversions possible.
We continue to invest in further advancement of our automation tools to make them even more versatile and productive. Overall, our suite of 8 tools currently reduces manual efforts by over 65%, and that automation figure continues to increase.
We also continue to invest in our teams to further train them in our fine-tuned development and testing methodologies that work successfully for VFP conversions. If you think an intelligent group of developers can, right off the bat, handle a conversion on their own, I am sorry to say you will be deeply disappointed for sure, spending a lot of money and getting nowhere. I have talked to many companies that have tried this path.
You might also think that other large-scale vendors say some of the US or sub-continent-based IT behemoth can do this job. Well, no, not really. Every time they have a client who needs such a conversion, they call us and want to know if we can support them and, most significantly, provide them with our automation tools. In all of these cases, we back off. We know this is a beginning of a disaster in the making.
In many other cases, we have worked with large companies about partnering with them to do a conversion of their VFP application. And along the way, they decided to hold off or go with an off-the-shelf product or thought they could build it internally. In every such case I know of, the company is still on their VFP application, either because they never started a conversion internally, couldn’t find the right commercial product, or did so but never got very far.
Finding a commercial product to do the job of the VFP application is usually a two-edged sword. If you can find a suitable product, that is undoubtedly a good start, but I hear of two problems that often pop up. One is the ongoing license cost of the commercial product each year beyond the initial investment, and the other concern is the usual ultra-high cost of customizations needed for the commercial product to fit into the suitable space you need.
Moreover, when you give up your VFP application, you are giving up all the fine-tuned business rules that work perfectly for your business, and your business teams will need to conform to the business rules embodied in the commercial product.
When we convert a VFP application to a .Net framework, we usually do an apples-to-apples conversion. So, all the business rules in the original VFP application are in a new application. Moreover, if there are changes/upgrades you need to make to your VFP application, we (or your team) can do those quickly once the application is converted. Since the new application is your property, your team can make any and all desired changes. That is certainly not the case with commercial products.
Converting a large VFP application is a complicated task, and if I can leave you with one important thought, you really need to have in-depth knowledge and background for a successful VFP conversion on a large scale.
We now have 3 and 5-year plans to increase our capacity to 10 million lines of code in 3 years and 25 million in 5 years. We will reach these higher capacities through two parallel strategies – half the gain will come from further and complete automation of the conversion processes, and the other half will come about via the expansions of our international development team.
The further enhancements of our automation tools will lead to two significant subsidiary benefits: shorter conversion times and lower conversion costs. Both these benefits will make VFP conversions much more attractive for mid-sized companies.
In terms of our expansions of the international development teams to handle our projected scaling of VFP conversion work, I want to emphasize that all new developers hired at our international facilities for our conversion teams get intensive and proprietary training on our conversion development and testing methodologies. It is only after the completion of this 6-months program these new members of the team are ready to start taking on limited tasks within our conversion line of work. As I noted above, VFP conversions are a far cry from regular enterprise development, and we have many hundreds of things that we teach our new recruits in order to make them ready and able to do VFP conversion projects.
As far as I know, there is no other company in the world that can come close to these actuals and plans. In fact, I am not aware of any successful conversion of a VFP application in the around 1 million loc or larger range that has used a streamlined methodology specific to VFP conversions and is able to use automation tools to do the majority of the conversion.
I know of many disasters where the project was abandoned well before completion, with costs astronomically above initial estimates. Again, this is not something to take lightly.
Overall, the cost for us doing a conversion is somewhere between $2.5 to $4 per line of code. This estimate range typically includes code-level quality control and three months of UAT. The content reflects the range in the complexity of the application’s business rules and the number and complexity of the reporting framework.
So, for 500,000 lines of code application, the cost will be in the range of $1.25 to 2 million, and 1 million lines of code application will be in the range of $2.5 to 4 million. For sure, that is a sizable amount of money. But, it is ordinarily payable monthly over two financial calendar years.
This should be a reasonable expense for a mid-sized company with revenue in the range of $50 million and up, especially if booked over two years. And the fact is, you will need to do this sooner or later. Waiting for a long time is just not an option since it can impede so many other advancements in your overall IT infrastructure.
Hence, now is the time to start planning your VFP migration seriously, and Macrosoft is the only viable choice to partner with you. Call me, and I will be happy to discuss the particulars of your situation.
Thank you!
For more details, contact us
