>>>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 would definitely include that comment in your presentation. Of course, including it will bring many questions: how much longer before we have converted working modules in .net? can it be done using existing resources? etc. Still, whether or not they think that is an option, it should be included in your recommendation, and then present both options and then options within both on how it could be done and estimated time frames, usability in the meantime, rolling out the changes along the way to customers, etc ....