>>
>>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)

The only two people who understand the application from a technical POV are the guys who developed it over a period of many years. They left in the aftermath of the acquisition, under such poor circumstances that they did no turnover at all. Part of the mystery is how many things they did to keep the system running from command windows. We know it's a lot but are only gradually learning what these things were. From the way users come into my office and state variations on "X isn't working, please fix it for me fast" you can tell that is what they are accustomed to -- the developers doing end runs around the EXE by zapping the database. Terrific, huh? I am the one who is supposed to figure out how it all works. It's huge and so far I have only scratched the surface.

Some may be wondering why this seems appealing to me. The oldest reason in the world.... ;-)