>>>>Thank you for sharing your experience with converting VFP program to .NET.
>>>>I think (IMHO), the most challenging part of converting VFP program to .NET is the UI. And I am guessing that UI was a fairly small part of your program.
>>>>
>>>Yes, there was very little user interface involved.
>>>Yes, the UI is more difficult to convert than straight procedural code.
>>>Even more difficult are reports.
>>>SSRS is good but not as good as the VFP report writer.
>>>
>>
>>I agree 100%. As far as VFP reports to SSRS, maybe some day a tool will be developed to convert a VFP report to SSRS. But as far as the code for UI - especially if converting to a web application - will have to be done manually. And with huge knowledge base. Not me.
>
>Yes, it's daunting. I've done it a few times.
>You have an advantage though- you're an expert on the VFP app, so you'll be able to assure that the outcome is correct and that's a big deal.
>Step back and look at the UI again.
>How many types of UI are there?
>There are CRUD forms, transaction forms, search forms, inquiry forms - whatever, but the number is finite.
>Some forms use several of the basic types.
>How about knocking out a killer class for each type that you can re-use?
>We're locked down and there's snow in the forecast.
>Why not knock out some of those classes?
>
>As I said the reports are a real PITA, but with the lockdown and snow in the forecast they might be just what we need.
>
>Have you looked at VS 2019 and .NET Core?
>Exciting stuff.
>There are other good choices - PHP, Python, etc.
>Thierry's path makes sense too, for a lot of people. I admire the elegance of his solution.
>Whatever you choose, it's a great time to get moving.

I don't any more have the "drive" to learn new technologies.