>>Suppose a company has to decide THIS YEAR to either modernize its in-house-built VFP7 application that handles complex rules, or to choose for replacement with a standard application that only claims it can handle those complex rules...
>>
>>What do you think will be the influence of the announcement made this week?
>>
>>And how do you think developers and decision makers will currently feel if they had that decision to make LAST YEAR and chose to continue using VFP?
>
>Complex applications don't get migrated overnight. Any project manager with a slight idea of what she is doing will prepare an evolutive path. Whenever you want to switch platform in a huge application, you first prepare a clear interoperability strategy, and then you start doing an incremental shift.

And if it's a HE? :)

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.


>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. :)


>Of course tons non-critical, legacy applications are still running on FPD and older technology, but this is a completely different story.