>>The choice was to either modernize or to switch. The choice is no longer available. The manager, whether a he or a she, is forced to switch. Or are you seriously suggesting that companies should consider the option of incrementally shifting in 8 years? I tell you, that's not what will gonna be decided a lot.
>
>What I say is that a projects that completely rewrite a complex application and then have an old-app-off -> new-app-on day are almost always a very bad decision. I know because I've been there many times. But having 8 year of product support ahead (if this is poses a deadline due to corporate standards) gives you a lot of time to start an incremental migration. If this is properly handled, it can probably get you to a new platform faster than a complete rewrite, which has a lot of validation problems.

Ah, okay, as I read it, you propose that management should consider the scenario of replacing a complex system piece by piece, instead of following a Big Bang scenario. Well, that may be a viable option, under circumstances. I see (for now) 2 possibilities:

1) The GUI has a menu that calls modules. In a complete VFP application it calls APPs. Over time, more and more of those called modules will gonna be e.g. VB.NET modules. The last step is the replacement of the main application that ultimately only still handled the menu.

2) The application is n-tier and each such piece is replaced in a timeframe.

Both routes ideally require LINQ, right?

Well, this path is a serious consideration for companies that decide to keep development in-house or under own control. But there is a trend to try to use standard software where ever possible, even for complex jobs. Management is often convinced by the account manager of the standard package that "there will be no problems, believe me, we can handle all your requirements". And the route is then often towards Big Bang. Until recently, we could try to prevent such a scenario by telling management that modernizing is also an option. I guess we could now try to convince that a piece by piece replacement may be wiser.



>>>Over the last two versions VFP added a lot of interoperability features to let you play with .NET, Java or most any other modern platform, so this shouldn't be a problem.
>>>
>>>Also, notice that you are talking about an presumably well-managed company which have a complex application still running in VFP 7, which is an obsolete product since a lot of time. That doesn't sounds smart enough.
>>
>>VFP7 still gets some support by MS. http://support.microsoft.com/lifecycle/?p1=3018
>>Having said that, a simple rebuild in vfp9 often suffices. Talking about modernizing. :)
>
>That's why I'm saying an important application still running on VFP 9 doesn't make much sense.