Migration from Visual FoxPro 2.6

[nageshbv]

Friends

I am working on an initiative to migrate from Foxpro 2.6 (for Windows). The biggest problem I am facing is the bosses are not convinced about the migration.

Can you please help me with the following.
1. What are the top 5 reasons to migrate from FoxPro 2.6
2. If we are installing more copies of FP 2.6 on developers and end-users machines, are we violating any license agreements?
3. How many installations might still be there with FoxPro 2.6 ?
4. The potential problems we may be facing as we stick to FoxPro 2.6.

I understand that one may not be able to give precise numbers or exact answers, but you are most welcome to share your thoughts.

Thanks a lot for the help.

regards,
nagesh

 

[mmerlinn]

You have run into the classic business brick wall: If it ain't broke, don't fix it. Unless you can justify the expense of conversion to your boss, it will never happen. No successful business EVER spends money unless they MUST or unless the return is GREATER than the cost. Government entities run on the opposite principal, we must spend it (no matter how idiotic the project) or our budget gets cut next year.

Witness the number of COBOL programs still running on computers worldwide. It is much cheaper to maintain the COBOL on them than it is to start over from scratch. And all of the original COBOL programmers are either retired or dead, so it is up to the next generation of COBOL programmers to keep these applications running.

The biggest potential problem that I can think of is that at some point your FP 2.6 application will not operate properly on the latest computers. At that point you have two choices, either never move to later computers so the FP application will continue to operate properly, or rewrite the application in a modern language to run on the latest computers.

My suggestion is to find a job 1) that is NOT being done, 2) that NEEDS to be done, & 3) that can be done with VFP. Then convince your boss to fund the resources (including VFP) to get the job done. Then write the program to do THAT job only.

Be sure to ask for more computers, programs, etc than you will need to get the job done. It is much easier to cut back to what you really need than it is to come back afterwards asking for more funding because you didn't ask for what you needed the first time.

Once this new application is up and running, it will be much easier to convince your boss to move to the 21st century. The biggest hurdle, cost of resources to do the job, will have already been justified and the resources will already be in place. More importantly, at that time he will be able to SEE the advantages of moving forward.


mmerlinn

"Political correctness is the BADGE of a COWARD!"

 

[Scott24x7]

Nageshvb,
You are faced with a number of challenges. I will assume first that you understand VFP, and how it works. Before I start to answer your questions, let's start with defining "Migration". You need to be very careful how you use this word, and your understanding of its meaning vs your leadership's understanding. If Migration is "Recompile existing screens & code under VFP" you are in for a shock, as it is not that simple... the VFP conversion often does not work, and creates HUGE amounts of "Fixes" which are a bad idea, as the app will likely still run worse under the "NEW VFP" then it did as a 2.6 app. This is NOT a perception that you want.
If you understand VFP then make migration mean "Minor Re-write". I have moved heaps of my 2.6 applications to VFP with great success after spending about 3 months of really working through how to best go about it. I was also stricken with the issue that I didn't really know VFP well yet either. (This was back in version 6.0. I did not adopt VFP early). I have found the best way to do this is to create new forms for each of the old forms, NOT using "imported or converted" forms. They are an abomination of confusion. You can then take code snippets from the few "events" you had in 2.6 like the WHEN clause, and put them in the more appropriate method or event for that new object.

Once you have all that done, you will have a better "port" of your application, and doesn't really constitute a full "Rewrite". Make sure, above all, that you subclass ALL controls before you put them onto a form, and the FORM as a class as well. Otherwise, you can not take advantage of inheritance that even if it is not important to you now; will become later as you understand it. Don't worry about customizing the control, but subclass it, and put it in a library.

Now, on to your questions:

1. What are the top 5 reasons to migrate from FoxPro 2.6
1. More stable on Pentium I+ CPUs.
2. More robust environment allowing developers to be more effective, and produce working solutions faster.
3. Modern look that users have come to expect from applications.
4. 2.x is no longer supported by Microsoft, VFP is supported until at least 2014.
5. It just works better... has a much grater flexibility especially in the user interface design capabilities. (i.e. Forms with Tabs that were not possible at all in 2.x, making it easier for users to navigate and access screens easier. Floating tool bars, and a robust "Real Database" engine.

2. If we are installing more copies of FP 2.6 on developers and end-users machines, are we violating any license agreements?
When you say "Installing more copies of FP2.6 on end-users machines" I assume you suggesting that you use FP2.6 to actually run the application... In this case, yes, you are in fact violating license agreements. Installing it on developers’ machines, which then use it to develop 2.6 applications, is very much a violation of license agreements. The end-user issue can be easily fixed, as it is not necessary to have 2.6 installed on the machine if you compile the applications to .EXE, (assuming you have the distribution kit which allows you to do this). This is true of both FPD and FPW.

3. How many installations might still be there with FoxPro 2.6 ?
I really don't understand this question... do you mean, globally, how many people are using it still? I'd say there is still plenty of 2.x applications out there, especially running on lesser PCs. Interestingly, the more advanced the PCs become, the worse 2.x seems to function.

4. The potential problems we may be facing as we stick to FoxPro 2.6.
1. Loss of developers able to fix/enhance the application.
2. Loss of support from PCs for such old technology. (2.6 is 16bit based... VFP is 32bit, the modern PCs on the horizon today (and poised to consume the market entirely in the next 2 years) are 64bit.
3. No competitive edge in your marketplace, and potentially if these applications are critical to running your business, other businesses that you work with may see this as a risk to their continuation, and drop you as a vendor.
4. Professionalism in you industry (see #3, this ties in too.)
5. No longer supported by Microsoft (see item 2... they are not interested in ensuring the 64bit OS's run these antique applications or languages.)
6. Commercially available licenses are virtually non-existent. (In your best case scenario, you are buying used licenses off eBay... not a great business model.)

These are just the issues I can think of off the top of my head. I'm sure if I dug under the surface I could expose HEAPS more.
While mmerlin's suggestion for how to "Get the new hardware" and justification is one way to go about it, I think it is rather easy still to build a compelling business case, with real $$$ impact to the company based on the items above that I have mentioned. One interesting thing about being a 2.x "Pro" is that as this language dies, the number of developers decrease. If you are their only dev resource, they are in a seriously precarious position, and finding someone with the skills to maintain can suddenly cost them $150+/hr. (Its why I stay sharp on 2.x still, as there are so few people who are very skilled in this language left... I've been developing a reputation as the "Fox Doctor", in my circles...
Best of luck.


Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[nageshbv]

Scott, Merlinn, Mike

Thanks a lot for your detailed responses.
I am better prepared now for a case to migrate from FP 2.6.

I really appreciate your help.

Regards,
nagesh

 

[stesvet1]

Hi,

I recommend you to go step by step. Firstly I would say to your chiefs, that FPW2.6 is still very good for some applications but for some others should they start Visual Fox and for your company is it very needed and that the combination will bring money.