ORPHANWARE Why these apps refuse to die
A FoxPro or Clipper application that has run an office for decades is not still there because nobody got around to replacing it. It is still there because it works. Over years of daily use it absorbed the way the business actually runs: how invoices are numbered, which customers get which prices, how inventory is counted, how records are kept for audits and tax time. Those rules were never written down in a manual. They live in the program.
The data helps explain the loyalty. FoxPro and Clipper store data in DBF tables, a simple and durable file format that survives neglect better than most. The applications are fast, they run on modest hardware, they are already paid for, and the staff who use them know every screen. Replacing one means buying new software, retraining everyone, and risking the quiet rules that keep billing correct. Keeping it is often the rational choice, until something needs to change.
The situation most owners are in
The pattern is consistent. The business has the compiled application, usually an EXE and its support files, but not the source code. The developer who wrote it has retired, closed the business, moved away, or died, and the one copy of the source went with them. The program runs on an aging Windows PC or a DOS-era setup, sometimes kept alive under DOSBox or in a virtual machine that nobody wants to disturb. Microsoft ended mainstream support for Visual FoxPro in 2015, so there is no vendor to call. Everyone in the office knows the program matters. Nobody knows how to change it.
What typically breaks first
These applications rarely fail all at once. They erode at the edges, where the old program meets a newer world:
- A Windows update or a new PC changes something the program quietly depended on.
- A printer is replaced and the new driver cannot produce the invoices, labels, or reports the office relies on.
- Network shares, mapped drives, and file locking behave differently, and multi-user access starts to corrupt indexes or lock records.
- Data grows past limits the original design never expected, and date handling written for another era starts to misbehave.
- The one PC the program runs on fails, and there is no documented way to set it up again.
Option 1: Maintain and stabilize
The first option is to protect what you have. Image the PC the program runs on so it can be restored or moved into a virtual machine. Keep spare hardware for the parts that are hard to replace, and keep tested backups of the DBF tables and the program folder. Write down how it is installed: printer setup, drive mappings, configuration files, and the steps to start it each morning. Stabilizing buys time and reduces panic, and it is worth doing in every case. What it cannot do is restore your ability to change the logic. The next new requirement still has nowhere to go.
Option 2: Recover the source
The second option is to recover the source code from the compiled application you still have. xBase programs are workable recovery targets because so much structure survives compilation. Procedure and function boundaries, screen and report definitions, and table usage can be reconstructed into readable source that a developer can compile and change. For Visual FoxPro, forms and reports carry much of their definition in table-based files. For Clipper, the compiled EXE holds the procedure logic that drives the application.
The data side matters as much as the code. The DBF tables, index files, and memo files define what the business actually stores, and recovery documents that structure alongside the program logic. The rebuild is then checked against the running application: same records in, same invoices, totals, and reports out. Where behavior differs, the difference is investigated rather than explained away.
Orphanware Recovery is operated by Josiah Wilson, who directs every engagement and signs off on every result. The decompilation, reconstruction, and testing pipeline is carried out by AI agents under his direction. FoxPro and Clipper work is the first priority lane here, which is why this guide exists.
Option 3: Migrate on your schedule
The third option is migration, and recovered source changes what migration means. Instead of guessing what the old program does from screenshots and memory, you migrate from a specification: the recovered source and documented behavior show every field, calculation, and report the replacement has to match. Data moves out of the DBF tables in a planned export, the new system runs alongside the old one while outputs are compared, and the switch happens when the numbers agree. That is a migration on your schedule. The alternative is the same project started in a panic, the week the old PC fails.
Which option fits when
A short way to decide:
- Nothing needs to change and the program runs well: stabilize the environment now, and keep recovery as the planned next step.
- You need a fix, a changed report, a new field, or a new printer to work: recovery is usually the direct route, because the change needs source.
- The platform itself blocks you, through remote access, integrations, or staffing: recover first, then migrate from the recovered behavior instead of from guesswork.
- You are not sure which case you are in: that is what the Recon Report answers, for a fixed $45, before any larger commitment.