Clipper & xBase migration: contain first, then move calmly
Clipper systems from the Summer '87 and 5.x era still close the books in thousands of companies. We take them off 16-bit life support with Harbour — then, when you are ready, off DBF entirely.
The Clipper predicament
Clipper applications have outlived the company that made Clipper, the operating system they were written for, and usually their authors. What remains is remarkably durable — compiled xBase code over DBF tables — trapped in a 16-bit world:
- 64-bit Windows cannot run 16-bit executables. The app survives on one old PC, a fragile VM, or an emulator someone configured years ago.
- Printing goes through LPT-port assumptions and text-mode drivers that modern Windows barely tolerates.
- NTX/CDX indexes corrupt under SMB file sharing; the fix is folklore passed between operators.
- The 80×25 screens are fine for veterans and unteachable for new hires.
- Every business rule — credit limits, discount ladders, batch numbering — lives in PRG files or, worse, only in the compiled EXE.
Step one: contain with Harbour (weeks, not months)
Harbour compiles Clipper-dialect code to native modern executables — 32- and 64-bit — against the same DBF/NTX/CDX data. We have ported production Clipper utilities this way: the immediate result is the same application, same keystrokes, same data files, running as a first-class Windows program. No DOS box, no dying hardware, no emulator.
This step alone typically solves the emergency:
- Runs on current Windows, including under 64-bit-only environments.
- Prints through Windows printing instead of LPT captures.
- Can talk to a real database server later — Harbour's driver architecture lets DBF be swapped for client/server backends per table.
- Source recovered into a maintained toolchain, compiled by anyone, versioned in git.
Cost is a fraction of a rewrite because the code mostly recompiles — the work is in the differences: hardware-specific tricks, inline assembly, third-party libraries, screen and printer handling. The assessment identifies exactly those.
Step two: migrate off xBase — parity-tested
With the platform emergency gone, the actual migration proceeds like our FoxPro engagements: a parity harness captures what the system really does (the Harbour port makes this scriptable), data moves to SQL with verified codepages and memo content, and modules are rebuilt on .NET in slices — each one cut over only when its outputs match the old system's on real data.
The methodology is described in detail in Migrating a Clipper/xBase app without losing 30 years of business rules.
Frequently asked questions
Our Clipper app is DOS-based. Can it even run on modern Windows?
16-bit Clipper executables do not run on 64-bit Windows at all — most shops survive on aging 32-bit machines, VMs or DOS emulators. The sustainable bridge is Harbour: an actively maintained open-source compiler that builds the same Clipper code as a native 32/64-bit Windows application. We routinely port production Clipper utilities to Harbour as step one, which removes the platform emergency and buys time for a calm migration.
What is Harbour, and is it safe to depend on?
Harbour is the open-source successor of the Clipper language — same PRG code, same DBF/NTX/CDX data access, compiled to native executables on modern Windows (and Linux). It shipped its first stable release in years in July 2026 and has an active community. We treat it as a containment and transition vehicle: it removes the 16-bit cliff immediately, while the long-term destination is usually .NET + SQL.
Do we have to change our NTX/CDX/DBF files to move to Harbour?
No — that is the point. Harbour reads and writes the same DBF tables and NTX/CDX indexes through replaceable database drivers, so the ported application works on the same live data as the original. Index expressions, filters and SET RELATION logic carry over. That also means the port can run side by side with the old EXE during verification.
The source code is partially lost. Is migration still possible?
Usually yes. Between surviving PRG fragments, the behavior of the running EXE, the data structures themselves, and the people who use the system daily, the rules can be reconstructed — the parity harness turns their knowledge into executable tests. Lost-source projects take longer, but "the developer left and took the code" is a situation we expect, not an exotic one.
Why not go straight from Clipper to .NET and skip Harbour?
Sometimes we do — when the codebase is small or the 16-bit risk is not acute. But a two-step path (contain on Harbour, then migrate calmly) is often cheaper in total: it removes the hardware/OS emergency in weeks instead of months, and the Harbour port doubles as a reference implementation for parity testing the eventual .NET system.
Start with a fixed-price Legacy Assessment
One to two weeks. You get a full inventory of the application and its data, a risk map (what breaks first, what is undocumented, what nobody can rebuild), a data-quality report and a migration roadmap with honest effort estimates — a document you can execute with us or with any other team. Fixed price, agreed before we start.