>>>We are planning to rewrite a VFP application which uses DBFs to .NET and SQL Server. The system is extremely large and is comprised of a large number of subsystems invoked from a main PRG and menu. It is not considered feasible to convert everything at once. Instead the plan is to rewrite a piece at a time as resources and budget become available. Has anyone done something like this? To me it seems like the data is going to have to reside in both VFP and SQL Server until everything is converted. Any tips on good ways to do that?
>>>
>>>Thanks in advance.
>>
>>Here's my take : migrating modules buys you nothing but chaos. The trick is to first figure out the sql schema that will handle the data you have now since you will want to move that data. Design the sql and the data conversion before you even think about writing a line of .net code. Then you are capable of writing .net modules against real data, but don't have to have end users working with a new hybrid system.
>>
>>You can run the conversion, have a sql database of current data, and start designing the .net part.
>>
>>Keep using the vfp app to maintain the data while you work on the .net stuff, but keep migrating data to sql so you know what you are writing in .net is working.
>>
>>Teaching users to use a hybrid system that is constantly changing buys you nothing, but as you create each module in .net you can have the vfp users familiar with that part of the operation test what you are doing from a usability standpoint.
>>
>>Getting the data to sql should be the first priority, and writing the conversion to get the data from vfp into sql when the final changover happens fromvfp to the new ,net app, but the most efficient way to get the .net thing written is to mirror the vfp data in sql, doing the conversion periodically to test the conversion, but don't worry about doing any actualy CRUD on the real data from .net until the .net system is finished. That way you are free to test, play with design etc while working on the .net without worrying about messing with real production data.
>
>If it were up to me that's exactly the way I would do it.

I think you need to make a strong case it is the cheapest and fastest way to accomplish what they want with the least disruption of current operations. If you create the data conversion first you can concentrate the first dot net efforts on porting over the algorithms in which they are most interested, completing proof-of-concept on that before they invest any more money in it.

They already have seen what a haphazard, unprofessional hodgepodge of command window nonsense buys them. Make the case for design and planning being the most cost-effective way to accomplish a task this complex. Hybrid systems - especially involving two data stores as different as dbfs and sql server databases are not just accidents waiting to happen but disasters that have already happened.