>>In our case we did the decision to move to MSSQL and kept the old code base for VFP to be able to support those clients who could not or did not yet want to upgrade
>>Then we evolved the new MsSQL Version with all new wishes and features that were in the pipeline, and the old code base we only applied bug fixes and the really necessary changes. Those bug fixes and necessary changes were on a ratio only 1% of the changes we did in the MsSQL version.
>>
>>We also wrote a conversion tool to upgrade those old clients one by one. The process took around 2 years (several hundreds of clients in different countries with different features), now we let those clients know that the old VFP application will not be supported after end of this year.
>>
>>The main reason not to keep VFP in the same code base as MsSQL was because we can do certain things now so much easier and faster, we can use stored procedures, replication, and the most important thing is we can write complex SQL Queries where we had to do DBase Data crunching before.
>>
>>The biggest headache was the conversion, because we decided not to keep the same datastructure. So that turned out to be the hard part, but after all we made it work and it converted already more than 1500 databases.
>
>Thanks, that's a really educated and thorough experience telling.
>All your arguments are well received, and worth considering.
>
>The client I have in mind receives about 10 support 'tickets' per day, 40% of which end up in an ER;
>I wonder how one could say 'no' to these people for 2 years, until the new shiny SQL version is released!

As Tore pointed out, the key to success with this type of conversion is thoughtful phasing.
Here's an extreme example - just last month I shut down the last .dbf in VFP 6 application. The conversion began around 2005!
Back then there were some new requirements that looked like a good fit for SQL Server and we started a hybrid approach with just a few SQL Server tables. As needs changed, we used SQL Server whereever possible.
For quite a while there was one big mass of VFP code involving a few key tables that no one wanted to touch, until a major change in business rules came along and we bit the bullet.

Conversion just for the sake of converting is usually not a good idea and those projects tend to have high failure rates/