>
>I'm pretty sure we'll want the .NET modules to work directly with SQL Server from the start. What we will need is a way to mirror those data changes back to DBFs which are still in use on the unconverted VFP side.
>
>I don't know if modifying "unconverted" VFP modules to use remove views of SQL Server is going to fly. The recoding to RVs and regression testing would not be trivial. I don't sense any enthusiasm for doing further work on the VFP code other than keeping it running until they can take it out back and bury it.
If the plan is to just put the VFP version in minor maintenance mode (famous last words <g>) then why bother replacing a module at a time with the .NET version? Just do a rewrite. I know rewriting a module at a time and dropping it into the existing app. sounds appealing, but the reality is tracing down what gets changed at each branch of the application is really tedious, error-prone work (especially if they are free tables since you can't just attach triggers to log them). Then those changes need to be coded (if it's a linked server that means lots of T-SQL scripts) and tested. You can easily expect it to take 3X longer (and I'm being generous) than the rewrite.
One major assumption - you have people on staff that REALLY understand the current application and the business. If you don't (in either case, a rewrite or module-by-module) then things just got WAY more difficult.
(I understand this isn't really a decision you probably have much of a voice in, just giving my $.02)