>>>>>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?
>>>>>
>>>>>Rewriting a piece at a time can be difficult, if the existing application is also evolving.
>>>>>
>>>>>Has the team defined segments/timelines for each piece and what will be included? What kind of timeline are you talking about?
>>>>>
>>>>>Do you have a dedicated QA team? They can be a big help during the transition phase... (just a more general question, what's the size of the team)
>>>>
>>>>Thanks for the advice. Most of that is not within my control. For at least a couple of reasons the decision was made (above my level) that we can only do it a piece at a time. I have been asked for advice on the data migration strategy so that is what I am concerned with.
>>>
>>>My advice : resign now. If the aim is to migrate piecemeal from a purely VFP app to a .NET/SQL implementation then all you end up with (if you are lucky) is a pigs-ear .NET application emulating how it was done in VFP. Even without knowing the ins-and-outs of the application involved I'm sure that, in the end, it would be far more efficient (and result in a better application) to start the .NET effort from scratch.
>>>My 2c
>>
>>The sub-applications correspond pretty well to the business activities that are performed here, so in that sense a modular conversion makes sense. The objective is not to change the functionality, it's to get away from VFP and DBFs. The backdrop is that I was brought in as a contractor at a small local company that was acquired by a very large company in May. One of the main reasons they bought the company is they believe the acquired company had some sophisticated software algorithms that will provide a cost advantage against competitors. They have similar operations around the country and want the rewrite here to be rolled out to other locations, maybe all of them. They just don't have any intention of rolling a VFP/DBF application around the country.
>>
>>I don't think anyone has a line by line translation in mind. There are always things that can be done better the second time.
>
>Looking through other posts on this thread it seems to me that pretty much everyone thinks a re-write without touching the existing VFP would be the most effiicent and least disruptive option. If that is not a choice there's one other possible approach:
>
>Rather than initially converting the existing VFP application to run against a SQL back end write a .NET DAL that will run against the existing VFP DBC/DBF's. That way there should be no (or very little) possibility of disrupting the existing VFP operation whereas there would be a very real chance of that happening in the course of converting VFP to use a SQL back end.
>
>Develop the SQL Database structure and the .NET SQL DAL at the same time. Optimize everything for SQL even if that means more work on the VFP DAL. When the code conversion is complete migrate the data from VFP to SQL and turn of the VFP app.
>
>Of course the downside of this is that you're stuck with VFP as the prime datasource until the conversion is completed.
>
>I assume that, IAC, they are not intending to roll this out to other sites until the VFP application is completely redundant ?

No one has said that explicitly to me but that's certainly the way it looks.

This .NET SQL DAL -- how does that work? I did not know .NET could access VFP data. OLEDB?