I am in the process of working on a similar project. It involves redesigning and practically rewriting the entire application. The only thing remains the same is the UI part. What I decided to do is to rewrite my application into a 3-tier design using VFP database. Then I added SQL Server option to the DA tier. So now, while I am testing parts of the application, I can swith from VFP database to SQL Server (and hopefully to Oracle in the future) with a change of one global variable (plSqlServer - .T. or .F.). I agree with others, this is a huge task (I have been working 10-12 hours 7 days a week that past 8 weeks). But in the process of resigning I found so many places that I was doing redundant code requiring unnecessary maintenance. Therefore when I am finished, I will have better application, not only in terms of backend but a better designed and maintainable.

>We are considering a conversion of a large VFP 8 application from native VFP databases to use an SQL server based back-end.
>
>The application opens tables via USE and via form data environment. It uses SEEKS, LOCATES, REPLACES, etc. on the tables and TABLEUPDATE to update the tables.
>
>We would have to move the data structures over to a SQL backend, then update the code to access the new database. There is a lot of business logic in the vfp source code (do whiles with replaces, etc.)
>
>I realize there are books from Hentzenwerke that discuss using MySQL with VFP, and we will be looking at them. We also have West-wind and their business objects, which look good. However, to use them requires your app be designed up-front for them. Or re-written to use them.
>
>1. Has anyone actually performed such a conversion on a large VFP application? (606 forms, 296 prgs, 178 report files) I'd like to talk to you if you have.
>
>2. Are there any drop-in replacements for USE/SEEK/REPLACE, that translate them to SQL on the backend. It seems technically possible to create a USEsql(), SEEKsql(), etc. that you could use in place of the native function calls that would get to 80% of the way to an SQL backend without having to refactor all your business logic. Has anyone seen anything like this?
>
>Thanks for your help,
>Chris