Gerard,
>See responses to this thread for Microsoft site , which does indeed say VFP 8 is supported until 2010
Actually, it's 2013 for VFP8 and will be end of 2014 for VFP9. Here is a link to Ken Levy's June 2004 letter, which stated the change to Microsoft's Lifecycle plan that extends support to 10 years, increasing VFP8's expiration of support to 2013.
http://msdn.microsoft.com/vfoxpro/letters/06032004/default.aspxThe Lifecycle page that some people provided to you has not been updated with that later information, which was just announced in the past few months.
The question of planning your company's development for the next five years is not just a simple "keep it in VFP" or "rewrite it completely in .NET". There are many shades of grey in between those absolutes, including reuse of existing VFP code in many cases -- such as lengthy and complex calculation routines.
I'm currently working on a project (and did a session on it tonight at the Chicago user group) that involves the potential reuse of over 50,000 lines of intensive data manipulation code by encapsulating it in a COM object and interfacing with it via XML from both VFP desktop apps and also from ASP.NET web pages.
The legacy code that contains the core calculation engine is a valuable business asset and has been in production for years and is well-debugged. It is needed right away for use in generating the same calculations from an ASP.NET user interface.
In this case, it makes much more sense to encapsulate the existing VFP code and get it working with the ASP.NET application right away instead of taking a year or more to completely rewrite that logic in .NET code. By doing so, the company will get to market quickly for a new set of clients who wanted the web capability now.
We already have a proof-of-concept project well underway, with a subset of the large code block, and the performance even calling the VFP COM object through COM Interop from the ASP.NET page is measured in just hundredths of a second.
Not every project will fit this profile for reuse of VFP code, and some legacy apps can still run for years with a bit of maintenance, not justifying a complete rewrite. Other apps or some new development might be better done in .NET or in VFP, depending on a number of factors.
So, bottom line is that there is no "one-size-fits-all" or "one-answer-fits-all." It depends very much on the exact circumstances of your business. In strategy discussions such as you are describing, it often helps to keep business needs and actual use cases in mind to weigh against the costs of rewrites.
Microsoft's long-term support of VFP is likely not a problem in a 5-year plan.
