We''ve done a few of these. I'm up to my neck in one now.
There are really two conversions - one to SQL server and one to .NET
We use a table by table approach to the SQL Server conversion and use SQL passthru with stored procedures at every step.
That allows you to use those same STP's with .NET later.
Changing VFP's apps to use SQL tables instead of DBF's isn't as daunting a task as it seems, if you plan it judiciously.
There will be a period - as long or as short as you want it to be, while your VFP app uses both DBF's and SQL Server tables.

The Upsizing tool sucks, so I've written some VFP tools that facilitate moving the data from DBF's to SQL Server.

Naomi pointed me to a great tool that generates Insert, Update and Query STP's for a SQL Server table and that tool cuts days off the task of creating the STP's.
I'm forever in debt to Naomi and the author of that tool. It's a lifesaver!!!!!

Once the data has been converted to SQL Server, we've used a module by module approach to moving from VFP to .NET code, working with the client to chose the functions that would benefit most from .NET features or which need updates for other reasons.
The client considers things like the personnel involved, the location of the users, etc and we contribute the technical information about which modules can be most readily developed.
In some cases, the client was so anxious to move a function to .NET that we used VFP and SQL data in the .NET app because the VFP data wasn't slated for conversion to SQL Server for a long time and the client needed the new functionality in a hurry.

I wrote a .NET code generator that generates and passes parameters to the STP's and that cuts even more days off, because writing the .NET code yourself can be verbose and it's error prone.

Typically it's taken over a year to get a decent-sized app moved over.

Planning it out carefully with the client and developing some tools to handle the mechanical tasks can make this a lot simpler than it seems.








.