>>>Just out of curiosity - why? It rarely makes sense to convert a VFP application to .Net.
>>>
>>
>>Why do you say that?
>
>You know I am usually on the side of at least partial conversion, if the vfp app is technologically sound. The way the above is formulated, that is correct - if conversion is only to have it under another runtime, it is most likely a waste of money. If the application still does nearly everything that is needed and only some minimal additional capabilities are needed, often it is more economical to add an API for COM, File, Record or ObjLink communication capability or even something like FoxInCloud alternative GUI layer to existing vfp exe.
>
> Exchanging some layers - starting with the data store - often makes sense. A lot of dev time is needed to get the spec sheet into something workable and keeping that investment is IMO often crucial to the ability to stay within the projected budget, also not having to test and resolve remaining bugs and spec interpretability.
>
>But a full automatic conversion- esp. of an old single layer app - would run against the mind set / architecture of .Net, probably creating something more ugly and less performant than the predecessor, which Craig mentioned.
>
>But to keep the spec communication chaos down, after porting to some SQL back end the next step WITH A VFP APP PROPERLY SEGMENTED into different layers I'd either replace a middle layer / rules engine part of add other GUI. For a first draft of a desktop version I'd read out the vcx/scx info and pipe that into the data structure used by the new GUI, arguing that for first step no retraining of users is needed and cost is minimized. After getting the kinks out of version 1.0 new changes in new environment.
>
>Perhaps this is something in line with my usual cost distribution: my percentage of total project cost to check the specs and resolve inconsistencies is MUCH higher than that of other devs. The % time spent coding is smaller but the real savings come in testing: I usually have much less errors in new dev than coworkers, and in the time frame that must be set aside for testing (as my guesses in line with real need are "corrected" by managment) can fix up the bug list previous maintainance workers created and were unable to solve. If fixing theses old issues goes with refactoring, I get no flak, as long as everything still works ;-))
>
>As my total typical cost is lower and bug list of projects under my wing shortens, those pecularities are no problem - even if I sometimes explode the time estimates of the guys in charge of the spec sheets and am quite blunt doing it - when they realize, that this is set off by not having to write bug reports in testing some ask for me to be in charge of new projects or heavy change requirements.
>
>If you apply that pattern to a porting job, most of the cost - speccing and reviewing specs - is already done and paid for. If there are some archtectural reorderings necessary, I can ususually implement and (minimally/marginally, to be honest) document that very fast ;-))
>
>Bestsellers in literature ore movies (having proven at least economic worth) usally are only translated, not written from zero or filmed with the same script but other actors again (except for the hope of drawing in a bigger audience by the more known american actors) - similar priciple applies to my way to work.

I agree with most of what you said, Thomas, especially the notion of getting the data store moved first and spending more time planning than coding.
The payoff vs cost ratio for the back end step is probably the highest ratio of all the steps in the process, and it paves the way for future steps.

I work in the small business market, where the money being spent is not coming out of a budget, but out of the owner's children's tuition money, so cost is a big deal.

About 10 years ago, I discussed .NET with several owners and we came up with this strategy:
After converting the back ends, any large new projects would be done in .NET.
Even with the back ends, we initially left some tables in .dbf's for a variety of reasons- mostly cost vs benefit.
Over time, the percentage of VFP code being used in production has dwindled and continues to dwindle as have the number of .dbf's in use.

A few clients are 100% .NET and SQL Server, but most are hybrids and will remain hybrids till some business event occurs that requires the VFP code to change.
The pace of change in the small business world is surprisingly high- so it's likely that sooner of later, those hybrids will move toward 100%.

A rewrite for the sake of rewriting would be out of the question in this market.