"Can we move our FoxPro app to the cloud?" is one of the most common questions we hear, and it hides a fork in the road. There are two very different things people mean by it, and choosing the wrong one costs money while solving almost nothing. The distinction is between hosting the old application somewhere new and actually modernizing it.
Both are called "moving to the cloud." Only one of them is modernization.
Option one: lift and shift onto a cloud desktop
The fastest path is to run the exact same Visual FoxPro application on a cloud virtual machine and reach it over Remote Desktop or Citrix. Nothing about the app changes. Users connect to a Windows session in a data center instead of a PC in the office.
This has a narrow, real benefit: it gets the app off failing local hardware and can make it reachable from more places. But be clear about what it does not do:
- It is still FoxPro. The same unsupported, end-of-life runtime, now with a monthly cloud bill attached.
- It is not really "web." Users need a remote-desktop client and a solid connection. It is a desktop app piped through a wire, not a browser application.
- It adds cost without removing risk. You now pay for VM hosting and remote-access licensing on top of every risk you already had.
- The clock keeps ticking. DBF limits, the talent shortage, and the security exposure are all exactly where they were.
The honest framing: lift-and-shift to a cloud VM can be a reasonable short-term bridge to get off dying hardware. It is not modernization, and treating it as the destination just relocates the problem.
Option two: actually move to the cloud
Real cloud modernization means the application becomes a browser-based web application with its data in a managed cloud database. There is no FoxPro runtime to install, no remote-desktop client, and no per-seat desktop to maintain. Users open a URL. That is the version of "in the cloud" that delivers what people actually picture when they ask the question:
- Access from anywhere, on any device with a browser, with no client to install.
- A supported, patched stack, so security updates are a normal part of life again.
- Real multi-user data in PostgreSQL or SQL Server, past the DBF ceilings for good.
- Room to grow, with modern integrations and analytics that DBF files never allowed.
Preserve the logic, do not rewrite it blind
The fear with option two is always the same: "we cannot afford to rebuild twenty years of business rules from scratch." You should not have to. The right approach reads and preserves the existing logic during the move, rather than re-specifying it from interviews and guesswork. That is what keeps a web migration from becoming a risky ground-up rewrite, and it is covered in our look at automated tools versus professional migration.
How to choose between them
Use the lift-and-shift only as a deliberate, temporary bridge, for example to escape failing hardware while a real migration is planned. If the goal is to stop paying the FoxPro tax, remove the risk, and give the business a platform with a future, the web migration is the move. One relocates the problem. The other retires it.
Bottom line: "FoxPro in the cloud" can mean the same old app on a rented desktop, or a genuine web application your team opens in a browser. Only the second one actually solves anything. Decide which you are buying before you pay for it.
Not sure which path fits your situation and budget? A free assessment lays out both options against your actual application, with no obligation.