>As you akready write about evident options to clean up code in vfp version but politics preventing that:
>In your estimate, to get in vfp code to a speedup of total time of less than 20 minutes at what percentage of concerting cost?
Probably half.
>What was percentage of getting new specs identifying not.needed-any-more functionality ?
>
It was more identifying things that had become inefficient because of changes in business volumes. Something that worked with 10 rows might not work with 1,000 rows. That used up a lot of testing time, so it was significant.

>
>>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.