>>Since they don't plan to roll this out anywhere else until the .net thing is done I don't see what it buys you to have any real data CRUD being done in .net while it is still under development. Leave the VFP app as it is, run your conversion regularly to sql, develop .net against that As you find it a good idea to adjust the schema in sql, adjust the conversion program to suit. When .net is finished, you run the conversion a final time and shut down the vfp (though you could even run them parallel for a month or so to doublecheck the results)
>
>Exactly - there isn't any benefit to trying to have the .NET try to read/write from the VFP data in that case. Just treat it like a new app where you'll migrate the old data forward. Now it's safe to redesign the database as well.

I think we all pretty much agreed that the 'gradual migration' that Mike is faced with is *not* a good idea - they will end up spending more time fire-fighting than developing. But, given that his 'powers that be' won't go for a clean rewrite, then AFAICS the options are to:
(a) rewrite the VFP code so that it will *temporarily* run against SQL or
(b) write a .NET DAL that will *temporarily* run against the VFP data.

So, given that both of these efforts will eventually be discarded, it's a question of which is the best option. I favoured the latter on the grounds that it avoids the almost inevitable disruptions that messing with the VFP code can cause. Whilst not pushing it out to other sites it should be possible to work with a hybrid solution on the development site if that's what they want?