Clipper and dBase systems: the migration playbook
Clipper and dBase systems migrate reliably because the part that looks hardest is not the risk: DBF is one of the best-understood file formats in computing, so extracting the data safely is the dependable part of the job. The platform is another matter. dBASE II popularised the desktop database in the early 1980s, Borland bought Ashton-Tate in 1991, CA-Clipper last shipped in May 1997, and its 16-bit executables cannot run natively on 64-bit Windows. The playbook: image the machine, secure any source code, extract and verify the DBF data, rebuild as a web application, run in parallel, retire the DOS box deliberately.
Clipper and dBase systems are the compiled survivors of the DOS desktop-database boom: bespoke stock control, job costing and membership systems built as standalone .EXE files and quietly indispensable ever since. Migrating one in 2026 is more routine than owners expect, because the part that looks hardest, the data, is the most dependable part of the job.
The answer in one paragraph
The playbook has six steps: inventory and image the machine, secure whatever source code exists, extract and verify the data from the DBF tables, rebuild the workflows as a web application, run old and new in parallel until they agree every day, then retire the DOS box deliberately. The platform itself has been finished for a generation. CA-Clipper last shipped in May 1997, and the 16-bit executables it produced cannot run natively on any 64-bit Windows, which is why these systems live out their days on elderly PCs and emulators. The data is the genuinely good news: DBF is one of the best-understood file formats in computing, and getting the records out safely is the reliable part of the work, not the gamble.
A short history, for orientation
Most owners inherited these systems without the paperwork, so here is the family tree.
| When | What happened | Where that leaves you in 2026 |
|---|---|---|
| Early 1980s | dBASE II from Ashton-Tate popularises the desktop database | The DBF table format your system still writes traces straight back here |
| Mid-1980s | Clipper arrives: a compiler that turns dBase-dialect code into standalone DOS executables | No interpreter needed at runtime; this is why your system is an .EXE |
| 1991 | Borland acquires Ashton-Tate | The dBase product line changes hands at the height of the era |
| May 1997 | CA-Clipper 5.3 ships, the final release | The toolchain behind every production Clipper system has not moved since |
| Today | The open-source Harbour project keeps Clipper code compiling | Containment, not a cure; more below |
The last new Clipper arrived the month Tony Blair first walked into Downing Street. Nothing about that fact stops the software working; everything about it explains why the tools, machines and people around the software keep disappearing.
Harbour deserves an honest paragraph, because it is genuinely good work: an open-source compiler that will build most Clipper code today for modern platforms, so recompiling under it can lift a system off 16-bit life support. For a frozen system that nobody needs to change, that is a reasonable containment posture, and we say so. What it does not change is the language, the vanishing pool of people who write it, or the distance between a character-mode application and everything the business now needs it to talk to. Containment buys time. It is not the exit.
The 16-bit reality
64-bit Windows cannot run 16-bit DOS programs natively; there is no setting to flip and no update to buy. So these systems survive in one of three living arrangements: an elderly PC that must never be switched off, an emulator someone configured years ago and nobody dares touch, or that one Windows XP machine in the corner, kept off the network and asked to do a single job forever.
Each arrangement works until its single point of failure fails. The full ledger of what that life support costs, in hardware, compliance, insurance and people, is itemised in the true cost of keeping a DOS-era system alive.
The good news about the data
A DBF file is a header describing the fields, followed by fixed-length records; free text lives in companion memo files, and index files can simply be regenerated rather than migrated. The format has been read, documented and reimplemented for four decades, which is what makes it one of the best-understood file formats in computing. Whatever else is uncertain about a Clipper or dBase system, the records themselves can come out intact, and provably so.
The care goes where it always goes with DOS-era data: OEM code pages that mangle pound signs and accented names if read naively, two-digit years exactly where you would dread them, and fields long ago pressed into second jobs that no manual mentions. These are known problems with known answers, and every one of them is caught by verification rather than optimism.
The playbook, step by step
- Inventory and image the machine. Before anything is changed, list what runs, where the tables live and what gets printed, then take a full disk image and prove it boots somewhere else. This one afternoon converts a potential extinction event into an inconvenience.
- Secure the source code, if it exists. The .prg files may be on the machine, on a retired developer’s laptop or in a drawer of floppies; find them and copy them somewhere safe. If only the compiled .EXE survives, the rescue still works: the data cannot hide, and the behaviour can be mapped screen by screen with the people who use it. Slower, not doomed.
- Extract and verify the DBF data. Extraction is scripted and repeatable, never a one-off export. Every table is round-tripped: record counts and checksums on the way out, reconciliation against totals the live system itself reports, memo files matched back to their parent records. The final run before cutover has to be boring.
- Rebuild the workflows as a web application. What gets ported is the behaviour, not the code: the screens people actually use and the rules the business actually relies on, on a boring mainstream stack any developer can maintain, with keyboard-first entry kept where speed matters. The method is the same one we document for DataFlex to PHP and MySQL; the platform differs, the discipline does not.
- Run old and new in parallel until they agree. The old system stays live and primary while the new one processes the same reality, and the two are reconciled daily in writing. Cutover happens when the comparison has been boring for long enough, and the business decides when that is: how parallel running works covers the method in full.
- Retire the DOS box with ceremony. Keep the disk image and a read-only archive of the raw data, hand its duties over formally, and switch it off on a chosen day rather than an unlucky one. Software that carried a business for thirty years should leave by the front door.
What to do this week
If the system is behaving, nothing here is urgent today; the point is to stop the timetable belonging to the hardware. This week: image the machine, hunt down the .prg files and table definitions, and test one restore from backup. Then map the options honestly. Staying contained, recompiling under Harbour and rebuilding for the web are compared plainly on the Clipper and dBase migration page, and the free Legacy Risk Audit makes that comparison for your specific system: a 30-minute call producing a one-page written risk summary, so the exit happens on a date you choose rather than one the hardware chooses.