>>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 as it is only technical and I speccing is resolved by soliloquizing, which is esp. cost effective when done over lunch ;-))

Bestsellers in literature or 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 principle applies to my way to work.