>>>>Which arguments do you have to not move fully to SQL Server and abandon VFP Tables?
>>>
>>>Some arguments were given earlier in this thread:
>>>1- support clients who can't afford or don't want a SQL database
>>>2- be able to migrate clients one by one without supporting 2 code bases
>>
>>OK, that said, the SQL Express version supports 10 GB of data, so it will depend on the size of the database if they need to purchase SQL Server.
>>
>>Regarding migration, I would imagine that if the data structure stays mostly the same, it would not be a real big problem to convert existing clients.
>>
>>So my conclusion is, check if old clients can use SQL Express with the 10 GB limit, and check if an automatic data conversion is possible. If both are possible, supporting VFP tables is not important and only creates additional work.
>
>Hi Christian
>
>Looks easy on the paper, not from my experienced POV.
>
>Once you migrate as you propose, how do you manage evolutions in the software? do you duplicate your code, one for DBF that evolves, one for SQL where evolutions are postponed later? Or do you apply evolutions to both 'versions'?
>
>Did you experience this overnight, all-client-at-a-time migration?

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.