Mark,

As you've noted, these sorts of decisions depend a lot on circumstance. I googled the company in your sig and can see that you specialize in bespoke software for corporations, with your "niche" being excellent design skills and business understanding. This makes a difference, because (as you note) your customers are more concerned about your specialist skills rather than the software tool you happen to have chosen.

Can I also ask for a few specifics about the app... is it to oversee a proprietary process, or specialized accounting, or stock, or ... ??? Will it be a fat client or a browser app?

Since you're using SQL Server the decisions are a bit easier. You should be able to compile a library of SPT and/or Stored Procedures that hold true whatever tool you decide to use.

My experience with dotNET starting in 2002 is that it wasn't as tough as people like to say. There is a difference for people who have only ever done "use mytable, scan for..." in VFP, but that's a learning process moving to C/S whatever tool they choose.

There's a dismayingly large galaxy of options in dotNET but there is a huge amount in MS Word as well and you aren't obliged to use or know it all. In our case, starting in 2002 we had little choice but to carve everything ourselves but there are plenty of frameworks these days. Which is a point in itself: dotNET keeps changing, and once you have a large library of code you can't always afford to keep re-doing it every time a new iteration appears. One of the benefits of VFP, despite the doom and gloom we hear so often, is that code changes have been minimal for a decade and this rate of change is set to slow even more. ;-) Whereas C# code we wrote in 2002 and essentially rewrote in 2003 is already profoundly obsolete and difficult to maintain, because anybody we try to hire isn't familiar with our old-fashioned work and wants to re-do it again the proper modern way.

I completely agree with the principle you raise - STAY PRODUCTIVE. What you could do is develop the app in VFP as per usual, but also experiment doing parts of it in C#, or ASP.NET which is fairly straight-forward. You'll soon get a good idea how feasible it is to convert this particular app in 2006. You might also take a tiered or SP approach, doing all the data crunching in something familiar while experimenting with options for the front end.