>Thank you for sharing your experience with converting VFP program to .NET.
>I think (IMHO), the most challenging part of converting VFP program to .NET is the UI. And I am guessing that UI was a fairly small part of your program.
>
Yes, there was very little user interface involved.
Yes, the UI is more difficult to convert than straight procedural code.
Even more difficult are reports.
SSRS is good but not as good as the VFP report writer.

>>Occasionally we see some informed discourse here about the desirability of converting a VFP program to another platform.
>>I did just that recently with some surprising results.
>>They're probably unique, but I thought they're worth sharing.
>>The VFP source is an essential (aka mission critical) program that has been running monthly for almost 20 years.
>>The volume and complexity have grown steadily over that period. Three months rarely pass without some change to that program.
>>The rest of this user’s system run on .NET and I’m trying to pass this system over to some younger .NET programmers, so the client asked me to convert it.
>>When it was first written the VFP program ran under 10 minutes
>>It's about 1,000 lines of VFP code in about 15 methods, all involving complex calculations and data analysis.
>>All the data resides in SQL Server tables.
>>When I converted it to .NET I learned that the VFP version was running over 90 minutes. The user would start it up when leaving for the day and find the results the next day.
>>The user never complained and my stripped-down test data ran just a few minutes when I was testing.
>>The converted .NET program runs 8 to 9 minutes. It’s been running for a few months and all is well.
>>There were no changes to the way data is stored. The outputs of the old and new system are identical.
>>I discovered a few things during the conversion:
>>A. My first approach was to do an almost line-by-line conversion. There was a slight improvement in running time, but nothing noteworthy.
>>B. Over time, business changes had made assumptions that were true when the program was written obsolete. Changing the .NET program to deal with the new business realities took off some hefty slices of running time.
>>C. .NET - or more precisely Windows - times out any .NET program running over a specified time with “Not Responding”. Creating a background threading scheme to deal with that sped things up some more.
>>
>>A rewrite of the VFP system would probably have gotten a good chunk of that time saving but it probably would never have happened.