Hi Kevin,

>Bottom line....and I mean this literally....and I'll take on all the flaming....anyone doing "File....New Project" in VFP for client work is quite likely doing a disservice to his/her client. I don't mean that in a mean or snide way, it's just the truth.

Wether or not a platform is supported by Microsoft is a technical decision that is completely irrelevant when deciding whether or not you need to re-write or start an application in VFP. Well, not entirely, but it's just one factor among many others.

We make technical decisions, customers make business decisions. In large companies, there are many factors involved in business decisions including many political ones. Lets ignore these companies and look at the smaller ones. The smaller ones usually have a very simple criterion for making business decisions which is called money. Here are two examples:

One of my clients has got a VFP division and a larger .NET division. Because the management wanted applications to look alike we sat together to decide how to continue with the various products. The .NET group suggested to port the VFP application over to .NET. "How long will it take?" were they asked. "Well, three years", was the answer. "What about deployment?" - "No problem, we only need SQL server...". "But you have to install it? Can't you just use a database?". The discussion went on and at some point the manager in charge wanted to know how fast they could deliver an update. "We have a two week release cycle." - "But you surely can send out a hot fix immediately in like 30 minutes?" - "No. We have dependencies. Every two weeks one release. We can't get around that."

If you sell thousand of copies for something like $50 a copy, you need to avoid support cost. Assistance during installation or customers frequently calling to ask when they get the fix is just not affordable. To this day the application is written in VFP 9 and as it seems, the 16 bit version will finally not be supported after the end of this year. Some customers are already complaining, because the 16 bit version served them well and they don't want to spend money on learning a new version.

Another customer wanted a new application that should last between three and five years. Will the application be used after that period? Most likely yes. Is it possible that we ran into problems in 10 years? Who knows. At least the customer is in charge of picking hardware and operating systems to meet the applications criteria. Is the customer willing to pay more for an application that might serve him longer than the estimated three to five years? Absolutely not. They don't know what their business will actually look like by then.

The only important question is: How much does it cost to solve the business problems?