>>Well then, perhaps you can sketch a piece-by-piece replacement scheme.
>>
>>Suppose it's a 1-tier application, using DBFs. A module is replaced by a module built with VB.NET. How does that module manipulate the DBFs, efficiently and with rushmore-like speeds?
>>
>>Suppose it's n-tier. Wouldn't piece-by-piece imply n Big Bangs?
>
>Assuming we are still talking about a faily complex application:
>
>- If it is a single-tier application, these guys are in deep trouble. In any case, if the app is actually working and providing mission-critical services, it could be done. The usual process involves isolating business logic first, so we can start writing unit tests as soon as possible. There are several possible paths from there which can be taken in different order: isolating database access, cross-cutting concern as security, auditing, exception handling, etc.
>
>- Once you turn it into at least 3 tiers, you can start replacing parts of the UI or the business logic, separating them across platforms.
>
>And no, in any case you don't have a Bing Bang, because you don't turn off the old application, and in most releases you can go back if something didn't work. Of course, if you advance in small steps it is far easier to check whether some of the new implementation is working properly or not.
>
>Best luck, Peter.

Martin, the 1-tier application I was describing here isn't (necessarilly) mine. It is a hypothetical (or not) application. But I'm sure many 1-tier apps exist in the world. So, I guess there are many companies out there who are, as you call it, in deep trouble.

I really had some hope that you would gonna sketch a simple way of dealing with such apps. But your proposed way of dealing with them is far more sophisticated. I understand the advice, but the sophisticated path is in this case not a simple path. It is an endeavour. Developers and companies should be aware of that. Serious consequences indeed.