About your bullet points:
1. In the web the number one server OS is Linux, many things run cross platform, JSP, PHP, even ASP.NET Core now also runs on Linux, but MS is not a bad server system. MS Azure is a main cloud platform aside of Amazon AWS and Googles cloud, and even a classical Windows Server running an ASP.NET web application could work out. In relation to bullet point 4 no web technology would be your goal, but I'll address what you got wrong with that there.
2. OK, yes, your experience with anything makes it a faster alternative than needing to learn new things. If you dust off knowledge about VB, though, I would say the effort to go for VB.NET or C# is quite similar.
3. Surely a dedicated server or even colocation always is faster than VM, a VM can already have big advantages in comparison to the classical hosting web space you get, VMs are not bad in themselves. Any normal account no matter if you get hands on the VM or not, typically runs on a VM. Any decent hoster with an own data center will run VMs on the bare metal, todays servers are mostly only hosts to guest OS VMs, even when you buy dedicated server. The VMs specs count in the same manner as if a server was its own real system. If you really want control about what hardware runs, you may use colocation and bring in your own hardware, but virtualisation also has benefits, eg your VM can move to another host when necessary, hardware crashes and defects don't harm you, as a VM can be started on the next intact host machine. And this is all automatic, your hosters job, not yours. The more you buy, the more hands on you have. AWS allows you to create VMs and run many of them. That's not the problem with VMs.
What not to do with VMs is giving users VM sessions for running a desktop app remotely. It's not what you can do in most cases anyway, you'd not only give access to your app, but your whole hosting system, if you let users login to your VM, but if you theoretically could, running a desktop app each user needs much more RAM than a webserver handling all user requests of many more users. Simply think about what needs to run server side in each scenario. Running a desktop app in a VM everything runs server side, needing the same amount of resources as a LAN client needs. While an app might only need 1% cpu, peak usage is seldom at the same time with other users, a server CPU, even just a VM cpu, can serve
many users, but RAM is a bottle neck, every session will have it's own VFP runtime for example, when you would run your VFP app on a Windows Server VM.
Running a web app, all RAM usage for display, forms, input of data, etc. all run client side, your server just needs fractions of RAM to prepare the HTML it sends out and process the HTML form submission and other http protocol communication in case of attaching a webservice, Rest API, and/or Ajax usage.
But no, VMs are not a no go in themselves, you might use them even without knowing anyway. It's just not the platform the end user should ever see, unless money plays no role to you and you rent big hosting space for each 10 concurrent users or so. It has a big money advantage, you could host your VFP app as usual, no new implementation, but it has running costs and security riscs. You would at least need a hoster offering VMs for this end user scenario without them getting hands on the whole system.
4. I said desktops are dead for home end users, but business app users - at least in my opinion and when I talk about myself - will run a desktop and I count notebooks into this. If you want to serve home end users on tablets , then not only desktop, but also web apps are a no go, then you'd need to go for native apps for Android and iOS or a cross platform app with Xamarin or Cordova and the like, but native apps are still kicking HTML5. Nobody uses a browser on a tablet to use a web app, even if you don't need GPS or device orientation or other native device APIs. The native app is the next desktop thing, but mostly only for software not needing keyboard input. Also not those keyboards with MS surface or Apple iPads. It's ok to work in a train, but not in your office and that will stay. Human hands won't shrink for easier tablet usage and tablets won't grow to not contradict their size for mobility. So a very essential thing I already said above is, business apps with their typical need for keyboard input rather stay desktop. What's bad in my situation is, deciders for budget are not the main users, they may only use a dashboard to display KPIs and other statistics to them and a tablet may be sufficient to them, but their employees enter much more text in many business applications than they and need the best input for that: keyboards. It's still that way and stays that way. Even considering swipe, word suggestions, auto correction on the virtual keyboards of smartphones/tablets, once you learned typing, a real keyboard is your input device of choice. Employees don't attach to a 9" display, they use a 14" notebook at least or larger with multiple displays in a docking station or a classical desktop, maybe not the big tower case anymore, but the size isn't making it a desktop machine. So back to what I said under bullet point 1, desktop may die out, but never in your domain of business apps (I assume you don't talk of game development, do you?), so the sales of desktop vs tablets vs smartphones don't matter much to you/us. Only in the sense of the additional app for on the go features.
5. If you want to move from the desktop overall, yes. If you only want to use the browser on the client, then it's a natural thing, too, that the data is server side. It's more what you wanted, you don't want the end user to have the database installed locally, didn't you made that a requirement. I'm totally fond of desktop apps still with just data rerplication, the cloud mainly is the transport of data needing to sync between sites in this scenario, but of course that means a on premise database at the customer per site. You are the one wanting to move to SaaS, that in itself is meaning data is not local, how could it be? The main poiint I stressed out many times is not separating a frontend and backend, if you can. With a webapp you can't keep these two together, by definition the frontend is separated to backend. It's the hardest thing to reimplemnt that, if your VFP desktop application does not already have a client/server architecture. And having DBFs on a file share is not having client/server architecture in itself.
I see a webapp still as nearer to the concept of a remotely running application, as you don't develop a frontend as rich in it's own functionality than a typical VFP form is. The typical VFP form rather is self contained, pulls data at init maybe also while using it, then saving at end of it's use and then finishes. Every interaction on it, very high level workflows are done in form methods. If you want that in the web you mainly need to use JS and that's the most unfortunate language to program with in my experience. JS once was built in 10 days and it's only intention back then was providing some simple client side features, not a desktop form feeling.
With a web app, you rather split a complex Winform into many steps in simpler HTML forms with submits to server at more times than you'd need save/close button usage on a winform. Just seeing you also have textboxesd, comboboxes and grids in HTML controls doesn't make it the same interface. You don't usually have formsets open in parallel, drag&drop from form to form and many more things you can rather easily do in the desktop, besides enabling such things in JS it's not the interface users are used to in browser, a browser canvas is not a desktop, each tab is one form. Users use the browser as multi desktop with maximized forms only. I do, nothing else makes real sense in browser usage. You know the web, you use the internet, don't you? You know it's giving you another experience as desktop apps. How often do you save files or open files from a browser? Very rarely. The whole experience is totally different as the outset differs very much.
6. For native apps: Java for Android, Objective C for iOS, C# for Windows mobile apps or with less needs some cross platform thing like Xamarin (C#,CSS,HTML,JS) or Cordova (JS, HTML, CSS plus API usage).
For web apps: JS, CSS&HTML client side, PHP or Ruby or Python or JSP or ASP/ASP.NET server side, MySQL or MSSQL and sql queries (no more workareas, cursors)
Cloud apps are rather like web apps, you have more API usage, but your end users still sit in browsers, nothing more native.
7. Yes, I already removed VFP from 6, it makes no sense to continue VFP on the web, native or in the cloud. There is the FoxWeb, FoxIS in foxpro sample, there is ActiveVFP and AFP as classical scripting server side VFP solutions, but they still have the HTML frontend and change or architectural principles and when going that route, don't stay foxpro.
Besides all that you can look at FoxInCloud, that's keeping your VFP app mainly as is. You forget one thought, if you lay weight on your own knowledge, though: What will be after your retirement, will no one inherit your business? Even if your business then simply ends. What do your customers do then?
Bye, Olaf.
