>I used to get this a lot. Consultants are very good at wrapping multiple concepts into a single scary picture and providing easily digestable slogans that allow less technically aware decisionmakers to believe they are being rational. I found a good solution was to assist decisionmakers to distinguish between data/backend and the proposed development tool.
>
>If scalability is an issue, the data needs to be in SQL Server or similar, and it needs to be stored on a dedicated server.
>
>Once the data is in SQL Server on a decent server, one can safely select various development tools to perform various functions against the data. Almost any modern tool can "scale" in this environment.
>
>The proposal that only one development tool is suitable and that others are "not scalable", becomes very transparent once the above is made clear. Tool selection needs to focus on particular advantages of various products, not "scalability" which is a red-herring.
>
>Whether dotNET is a smarter technical or political choice does depend on exact need, also on when it is intended to go live and with what user base. But in 2004, better "scalability" for dotNET is not a claim that is easily substantiated, even if the dotNET implementation is to an in-house audience who will receive near-new computers. If the intended audience is external, dotNET has significant scalability risks in 2004.

This is all good. I will also forward that to the lead of development.

Yes, we have .NET as the first layer on the server to respond to the Web Service. Then, it passes the request to VFP/WWC which goes into VFP data to get the data. But, that part could be updated to SQL Server. As you said, keep a specific development environment, in such design, shouldn't be that much of a factor.