Even if VFP does not wind up being your "main production tool", it would still be great for your own personal "toolkit": doing many (data) conversion type projects or "one-time" projects.

I still think VFP is more RAD than most; for situations where "time is of the essence", knowing VFP "well" can be to your advantage.

Even though you may wind up doing VB development, do you really want to forego VFP's string handling, local DDL/DML, Command Window, etc. as a "tool" to help get your "other Apps" out the door ?

Using Remote Automation, VB or VC can automate "VFP"; put a VB or VC "face" on your VFP processes via automation .... or use VB/VC with ODBC to drive your VFP DBC's .... if that's what it takes.

Or, write it in VFP, add a minor VB DLL, and tell them "Yes, it's written in VB (and VFP)".