Clipper Modernization:
Keep it in Harbour, or move it to .NET.

CA-Clipper programs are DOS applications, and 64-bit Windows has no 16-bit subsystem to run them. Two paths work. Harbour is a free, Clipper-compatible compiler that released version 3.2.0 in July 2026. A rewrite on .NET suits teams that need web access or a different skill set. The assessment decides which fits your source.

Book a free 1-hour consultation →

At a glance

Legacy sources: CA-Clipper 5.x · xBase and dBase III/IV code · DBF, NTX, and CDX files · Memo files · Get/Read screens · Memvars and arrays · Third-party Clipper libraries
Modern targets: Harbour · xHarbour · C# on .NET 10 · SQL Server · PostgreSQL · Windows desktop UI · ASP.NET Core web UI
First step: Free 1-hour consultation, then a fixed-scope assessment
U.S. delivery: 100% U.S. citizen workforce, U.S.-soil delivery

What to know before you modernize

What Clipper is and who still runs it

Clipper started as a compiler for the dBase language and became the standard way to build fast, multi-user DOS database applications. A Clipper program is a set of .PRG source files compiled and linked into a DOS executable. It reads .DBF tables through index files, usually .NTX, draws full-screen forms with @ SAY and GET commands, and holds working state in memory variables called memvars. Applications of this kind still run in distribution, point of sale, utilities, municipal offices, medical practices, and small manufacturers, usually because they were tuned for one business over many years. The code is compact and the data format is simple. The risks are practical: the build depends on a compiler and libraries that must be found and kept, the executable depends on a DOS environment, and fewer people can read the language.

Which Clipper you have, and what it implies

Most surviving Clipper code was built with CA-Clipper 5.x. The Harbour project tests its own compatibility against CA-Clipper 5.2e and 5.3b, and the xHarbour project describes itself as compatible with 5.2e and 5.3c, so those are the versions that matter in practice. Earlier Clipper releases and dBase III code exist, but they are rarer. The version shows up in the build files, in the replaceable database drivers (RDDs) the code selects, and in the linker and library set. RDDs matter because they decide which index format is in use. Code that sets the default to DBFNTX uses .NTX indexes; code that links a DBFCDX driver uses .CDX. We also look for the third-party libraries and assembly or C extensions linked in, because those decide whether a source-level move works on its own or needs replacement code for each library.

MS-DOS modernization →

Where Clipper stands today: Harbour and xHarbour

Harbour is the usual continuation path. Its README describes it as a free software implementation of a multi-platform, multi-threading, object-oriented, scriptable language that is backward compatible with Clipper and xBase. Version 3.2.0 was published on GitHub on July 7, 2026, and the repository took commits as recently as October 24, 2026, so the project is active. It builds for Windows, Linux, macOS, and other systems, including 64-bit Windows on x86-64 and ARM64. Its library code is under the GPL with an exception that says linking the libraries into an executable does not by itself bring that executable under the GPL; read the license file against your own situation. xHarbour is a related project, based on Harbour, that states it is practically 100 percent backward compatible with Clipper and lists a GPL-2.0 license. Its differences from Harbour are documented, so choose it only for a specific reason, such as a codebase already written for it.

The 16-bit problem on 64-bit Windows

The blocking issue for CA-Clipper output is the executable format. Microsoft's Win32 documentation says 64-bit Windows does not support running 16-bit Windows-based applications, and Microsoft's troubleshooting documentation says x64 Windows does not support 16-bit programs, and suggests 32-bit Windows in a virtual machine instead. Windows 11 requires a 64-bit processor, so on a current PC a DOS Clipper executable has no native home. People work around it with DOS emulators such as DOSBox, with third-party 16-bit compatibility layers, or with a virtual machine that runs an older 32-bit Windows. Those are bridges, not fixes. Printing, network file locking, serial devices, and shared files each need testing in the emulated environment, and the executable still cannot be rebuilt or extended. Our virtualization work can keep an emulated environment stable while the real move is planned, and we say so when that is all you need.

Virtualization →

DBF data, NTX and CDX indexes, and RDDs

The data is the asset, and it is in good shape more often than people expect. Tables are .DBF files with .DBT or .FPT memo files, and indexes are separate files that can be rebuilt from the key expressions in the code. Harbour reads and writes this data through its own RDDs, including DBFNTX, DBFCDX, and DBFNSX, so an in-place move to Harbour can keep the files you have. Harbour's documentation notes that a standard NTX file is capped at 4 GiB by its internal structure. The harder questions are in the details: code pages for accented characters, deleted-but-not-packed records, index key expressions that encode business rules, and multi-user locking on a network share. A move to SQL Server or PostgreSQL turns those implicit rules into explicit constraints, and it needs a rehearsed, repeatable load script and a reconciliation of counts and totals before cutover.

Screens, memvars, and reports

A Clipper user interface is code, not a designer file. Get and Read statements describe the fields, validation, and keystroke behavior line by line, and memvars carry state across routines. That makes the screens easy to read and hard to convert mechanically, because behavior such as when a field validates, how the Escape key unwinds, and how function keys work lives in the flow of the program. Operators who have used the screens for decades value the speed of keyboard-driven entry, so a replacement that forces mouse use can slow them down. Reports are usually hand-coded print routines that format text for a printer, with page breaks and totals in the code. We inventory each screen and report by purpose and usage, keep the dense keyboard workflow where it earns its place, and replace text printing with PDF and a supported reporting engine.

When Harbour is the right call

Move to Harbour when the source is complete, the logic is sound, the users are happy with the screens, and the main problem is the DOS executable. In that case the work is mostly a rebuild: compile the PRG files with Harbour's hbmk2 build tool, replace the third-party libraries or find Harbour equivalents, adjust any DOS-specific calls, and test printing and file locking on Windows. Harbour's contrib directory includes Clipper-tools-style (hbct) and Nanforum toolkit (hbnf) libraries, and ones for ODBC, PostgreSQL, MySQL, Firebird, and SQLite. The result is a 64-bit Windows program, or a Linux one, with the same code and the same skills. The cost of this path is that you stay on a niche language, with a small hiring pool, and you depend on a community-run compiler. That trade is reasonable for a stable internal tool whose owner knows the code. It is a poor trade if you need a web UI or integration with modern services.

Rewrite vs strangler fig →

When .NET is the right call

Move to C# on .NET 10 when the goals go beyond keeping the program alive: web or mobile access, integration with other systems, a database that other tools can query, audit requirements, or a team that does not want to maintain xBase. The usual design moves the data to SQL Server or PostgreSQL, puts the rules from the PRG files into a testable domain layer, and builds a desktop or web interface against it. It costs more than a Harbour rebuild, because the logic has to be read, specified, and re-implemented. The risk is losing rules that exist only in the code, so we extract behavior from the running system and from the source, then compare outputs side by side. A phased approach lets the Clipper application remain the system of record during the move. A bridge can expose the DBF data to new components while screens are replaced module by module.

Event sourcing and CQRS book →

When to stay put, and keeping it running meanwhile

Some Clipper applications should be left alone. If the program is stable, used by a few people, running in a well-managed emulator or virtual machine, and the data is backed up and the source is safe, the cost of a move may exceed the risk, and a short virtualization project is the right scope. Protect the things that cannot be replaced: copy the source, the compiler, the linker, and every library to safe storage, document how to build, and record how printing and the data share are set up. Moving becomes necessary when the hardware is failing, the business needs data sharing or web access, compliance needs audit trails, or the last person who understands the code is leaving. During any move the Clipper program stays in production, we compare results in parallel, and cutover happens in windows you choose.

When not to modernize →

Start with an assessment for a Clipper codebase

For a Clipper codebase the read-only assessment inventories the PRG files and any CH header files, the build and link scripts, the compiler version where it can be determined, third-party and in-house libraries with source status, the RDDs and index formats in use, every DBF and memo file with sizes and record counts, index key expressions, screens and reports with usage evidence, DOS-specific calls, printer and serial dependencies, and the file-sharing setup. Nothing is run against production and nothing is changed. The result is a written recommendation among stay in an emulator, rebuild on Harbour, and migrate to .NET, with a data-migration approach and a phased plan. The assessment fee is quoted after the free 1-hour consultation and is creditable toward a later modernization project.

About the assessment →

Deliverables

  • Written recommendation: stay, rebuild on Harbour, or migrate to .NET, with reasons
  • Source and library inventory with a keep, replace, or retire call for each
  • Data migration plan and rehearsed load scripts for DBF to SQL Server or PostgreSQL
  • Screen and report inventory with the keyboard workflows worth preserving
  • Harbour build plan, or a .NET 10 target architecture with phased delivery
  • Parity test plan and cutover and rollback runbook

Common questions

Can Clipper programs run on Windows 11?

Not natively. CA-Clipper builds DOS executables, and Microsoft documents that 64-bit Windows does not support 16-bit applications; Windows 11 itself requires a 64-bit processor. They can run in a DOS emulator or in a virtual machine with an older 32-bit Windows. The durable fix is to rebuild the same source with Harbour or to migrate the application.

Is Harbour still maintained?

Yes, by the evidence in its public repository. Harbour 3.2.0 was published on GitHub on July 7, 2026, and the source tree received commits as recently as October 24, 2026. It is community-run rather than vendor-backed, so check the release cadence again before you commit, and keep your own copy of the compiler and libraries.

Should we move Clipper to Harbour or to .NET?

Choose Harbour when the code is sound, the screens suit users, and the problem is the DOS executable. Choose .NET when you need web access, integrations, a modern database, audit trails, or a team that does not write xBase. Harbour is faster and cheaper to reach. .NET reaches further. The assessment recommends one in writing for your source.

How compatible is Harbour with CA-Clipper code?

Harbour describes itself as backward compatible with Clipper and xBase and tests its legacy language behavior against CA-Clipper 5.2e and 5.3b. In practice most PRG code compiles with small changes. The work is in the edges: third-party and assembly libraries, DOS-specific calls, printing, and file locking on a Windows share.

Can we keep running the Clipper application during migration?

Yes. The Clipper program stays in production while the new system is built and compared against it, using the same data or a copy. Cutover is module by module in windows you choose, with a rollback to the Clipper program until the new path has run clean through a full business cycle.

Do we have to rewrite everything?

No. Rebuilding the same source with Harbour is not a rewrite, and the DBF data can move to SQL Server or PostgreSQL on its own while screens are replaced in stages. Some screens and reports can simply be retired. The assessment lists what to keep, rebuild, or drop.

How long does a Clipper migration take and what does it cost?

It depends on scope. Site-wide, project work ranges from a few weeks (virtualization) to several months (re-architecture). Price and schedule are fixed only after the fixed-scope Legacy Software Assessment, which follows a free 1-hour consultation. The assessment fee is creditable toward a later modernization project.

What if we lost the source code or a library?

Say so at the start. Without source there is no rebuild, so the options narrow to keeping the executable alive in a virtual machine while the behavior is documented from the running system, and then building a replacement against that record. A missing library with source available is an easier case: it is replaced or recreated function by function.

Sources

Not sure where to start?

Start with a fixed-scope Legacy Software Assessment: a read-only review of your application’s source, database, configuration, logs, and architecture, ending in findings with evidence and a written recommendation. Quoted after the free 1-hour consultation; creditable toward a subsequent modernization project.