If there is no need at all for web solutions, target a move to either .Net or Java.
Your users will be glad no performance is lost.

Bad : Both systems are more focused on web development as target for the future.
If current system is ok with typical vfp controls for 90% of controls used, both are good enough.

If your current users are already nagging for more eye candy, .Net might be a bit better than Java, both are better than vfp.

If there is any chance for a company buyout or a long-term switch to chromebooks, Java is better positioned - or at least go with Xamarin if going for .Net, as Xamarin is multi-platform and was bought by MS. Xamarin also "safer" than WPF on .Net side ( they seem to split their efforts between backporting old Winforms and Xamarin traditional style desktop, while pushing HTML based GUI).

If there already is solid PostgreSQL knowlege in the company, go for it, use PostgreSQL backend - ***I*** found setting up "properly" the harder part there and you would be following already broken-in paths while building on existing people knowledge and at same time saving license cost for MSSQL. Also you might have someone else on site to look at a problem - often faster than posting ;-)

Supposing a LARGE system running currently (12+ man years dev time):

Step 1+2+3
When porting to [any]SQL backend. go for Cursoradapter on vfp side, but at same time extract as much as possible information into the backend via data dictionary, for instance field validation rules (not empty/null, between x/y, ...) and base current validation on data dictionary (quite a few implementation options from dedicated controls, elevated validations, convention-naming based biz middleware - without grokking current implementation hard to reccommend)


Step 4
Make all "real" GUI controls as empty as possible - every method of more than a handful of lines should be moved into biz layer - either as code or property to read out.


Step 5
Select a framework where the biz layer ORM is simple/has minimal magic and both Desktop and Web GUI can be bound to.
Aim for a GUI where at least structure (control type, containership) is in external file (XAML, XML, JSON) that can be read by a screen designer. Decide on a "lean" fwk, where 80-90% of your use cases are handled, NOT on the overarchitected one with all the whistles and bells, where you spend too much time configuring oodles of options to the needs of your use case (spring boot as bad example of too much magic and intimidating stack levels (MANY screens) if shit hits the fan). Clean up YOUR architecture and code YOUR specialities in a portable/welldesigned way, NOT the specific fwk way.

Consider using HTML GUI (not a web app!) for display only even if using desktop, but for your use case NOT via Electron (too much like web app/CPU cycles lost), but perhaps things closely related to HTML/DOM structure like JavaFX, Dukescript or new aim of Windows HTML GUI,

Step 6
a) Write a generator porting vfp screen structure to new language, bind that to vfp biz layer
or
b) replace biz layer with new Java/.Net, bind old vfp GUI to it

a) better to ***my*** personal taste, dependant on current code AND dev preferences!

Step 7
Do the rest....






>Hi all,
>
>I have been tasked with figuring out the future in regards to my main client's database. Even though everything is working fine for them in VFP, since I plan to retire in about 5 years, they want a roadmap now about "where are we going". Even though I have said that VFP could well run just fine for many years and that there are other developers around who could maintain it for them, they want to know what the alternatives are and what they should be planning for (timelines, budget etc). If they do decide to rewrite, they would rather not be up against a timeline of me retiring before they have fully migrated to a new system.
>
>Their main concerns for anything new would be "is it going to be around" and "how many developers" are there out there to continue to maintain it.
>
>Before getting in to all the possibilities (I have followed those discussions here for quite some time), I want to ask about .net specifically - of which I know next to nothing.
>
>I should say first that the company has no real need for a browser-based app per se - their staff all work in the same office and they do not have people on the road. They really only need a desktop app and they have liked VFP because of a) the responsiveness and b) the "richness" of the interface. Their current app automates a lot of their work and each staff person can probably put through twice the work than what they did say 10 years ago because of their on-going investment in it.
>
>I have suggested to them at one time to "let's first replace the backend" (from native VFP tables to SQL server or Postgres or something) and they might still be open to this but what they really want is a 5 year plan and so it must include both replacing the front end and the backend.
>
>So back to .Net - since it is MSFT and "popular", it seems like a contender in that it will not disappear soon.
>
>- is this basically for building web apps or does it also do desktop apps (I see from the MSFT site that is *says* it does - but does it really do a good job at that)?
>- are there many developers using it for desktop apps?
>- does it produce nice, responsive (i.e. quick, not responsive in a web page sense) apps?
>- is the language rich enough to do most if not all that VFP does?
>
>Any thoughts appreciated! Especially from those who use it or who have tried to use it.
>
>Thanks,
>Albert