>>>>Since they don't plan to roll this out anywhere else until the .net thing is done I don't see what it buys you to have any real data CRUD being done in .net while it is still under development. Leave the VFP app as it is, run your conversion regularly to sql, develop .net against that As you find it a good idea to adjust the schema in sql, adjust the conversion program to suit. When .net is finished, you run the conversion a final time and shut down the vfp (though you could even run them parallel for a month or so to doublecheck the results)
>>>
>>>Exactly - there isn't any benefit to trying to have the .NET try to read/write from the VFP data in that case. Just treat it like a new app where you'll migrate the old data forward. Now it's safe to redesign the database as well.
>>
>>I think we all pretty much agreed that the 'gradual migration' that Mike is faced with is *not* a good idea - they will end up spending more time fire-fighting than developing. But, given that his 'powers that be' won't go for a clean rewrite, then AFAICS the options are to:
>>(a) rewrite the VFP code so that it will *temporarily* run against SQL or
>>(b) write a .NET DAL that will *temporarily* run against the VFP data.
>>
>>So, given that both of these efforts will eventually be discarded, it's a question of which is the best option. I favoured the latter on the grounds that it avoids the almost inevitable disruptions that messing with the VFP code can cause. Whilst not pushing it out to other sites it should be possible to work with a hybrid solution on the development site if that's what they want?
>
>But in my experience when "the powers that be" are telling you *how* to accomplish their goal it is only because in the past they have dealt with clowns and shoemakers like the original developers and feel that they need to take some control of a process. This is where I think "client wrangling" is the most needed skill-set (and what separates a software designer from a programmer)
>
>The powers that be need to understand what is going on, and be approached in terms they understand - time and money. I have people coming to me saying they want to put their app "on the web" when what they are asking for is deploying upgrades automatically or being able to access an app from the field. I've got a client now who thinks he wants one big server for a situation that would mimic a nationwide chain of grocery stores having every swipe of a scanner on a can of peas hit the home office server, so that at the end of the month they can run company wide reports about how many cans of peas were sold. They can't imagine any other way to do it, so they are convinced they know *how* to get that report.
>
>If you go to your doctor with leukemia and tell him he has to fix it with surgery ...
>
>We owe it to clients to make the best possible case for doing it the right way - and then to bill them ruthlessly if they insist on chewing up thousands of hours doing something stupid.

I agree with all of that.

The only problem is you are responding as though it was you bidding on a rewrite/conversion project to a prospective client. That is not the situation I am in. They are paying me a nice hourly rate to keep the leaky VFP ship afloat and (so they say) participate in the .NET rewrite. I am not involved in strategic direction setting. Those people are not even in the state of Illinois. All they have asked me for is my thoughts on data handling during the gradual migration they already decided on. Hmmm, what do you know, that's how I titled this thread <g>.

What I say to them will include the directional skepticism expressed well here by you and others. That's a reasonable thing for me to do. What I am not going to do is act like I am starting with a clean sheet of paper, because I'm not.