How Do You Migrate a dBase or Clipper Application Still Running in 2026?

Is dBase or Clipper safe to keep running in 2026?

The application still runs, which is exactly what makes the question easy to postpone. The risk is in what sits underneath it. Both tools are frozen in a DOS-era design, and the vendors moved on long ago.

Clipper is the clearer case. The last commercial release, CA-Clipper 5.3b, shipped in 1997 and runs on DOS¹. Almost no new commercial Clipper applications were written after 1995, and the language never made the jump from DOS to Windows under its original owner¹. dBase has a longer tail: the product line is now owned by dBase LLC, which still sells current dBASE versions, but the dBASE III, IV, and 5 applications that businesses actually run in production date from the 1980s and 1990s, and The Register reported that the dBase website ceased operating in 2026². Either way, the people who wrote these systems are retiring, and the pool of developers who can read the code keeps shrinking.

What is xBase, and why does it matter for the migration?

dBase, Clipper, and FoxPro are not three unrelated products. They are members of one family, informally called xBase, that grew out of the dBase language and file format of the 1980s³. dBase came first, from Ashton-Tate, and its data file format, the .dbf, was already described as a de facto standard by 1985⁴. The others adopted that same format.

That shared lineage is not trivia. It is the single fact that makes a dBase or Clipper migration predictable, because it decides how the hardest part, the data, comes across.

Does it matter whether you are on dBase, Clipper, or FoxPro?

For the part that scares people most, the data, the answer is no. For the part they underestimate, the application, the answer is yes. Splitting the project along that line is what keeps it sane.

FoxPro is the sibling PCG writes about most, because Microsoft grew it into a full development platform before ending it. If your system is specifically a FoxPro one, the dedicated guide is migrating Visual FoxPro in 2026. For dBase and Clipper, the data story is identical and the application story is simpler, because neither carries FoxPro's heavier runtime.

Where does the data go?

SQL Server is the standard target, and the move is well understood. The .dbf tables are read, along with their index files and any memo files holding longer text, and loaded into SQL Server. The schema is redesigned rather than copied, because xBase tables were often flattened for speed on 1990s hardware and use field types that do not map one to one onto a modern database.

The ownership question matters here, so it is worth stating plainly. The records belong to the business. After the migration they sit in a database the business controls, with backups, history, and real multi-user access, instead of in .dbf files on a shared drive. The same data move, applied to a Microsoft Access database, is walked through in moving Access to SQL Server.

What about the application written in dBase or Clipper code?

This is the part that gets rebuilt. The data came across cleanly because of the shared format, but the program logic is tied to its tool, and there is no automatic converter that turns decades-old xBase code into a modern application worth maintaining.

The default rebuild target is C# .NET with SQL Server behind it, with a desktop or web front end depending on how the system is used. Business rules that still match how the company operates are carried over. Logic that only existed to work around a 1992 limitation is left behind. There is a middle option for Clipper specifically: the open-source compilers Harbour and xHarbour are close to fully compatible with old Clipper code and can recompile it for current systems⁵. That can keep a Clipper application alive while a real migration is planned. It is a bridge, not a destination, because the application is still xBase underneath and the developer pool is still shrinking.

What if no one still understands the dBase or Clipper code?

This is how most of these projects begin. The person who wrote the system retired years ago, the documentation is thin or missing, and nobody on staff can explain how a particular calculation works. It feels like a dead end. It is not.

A dBase or Clipper application can be reconstructed by reading it. The source code, the compiled program, and the .dbf data together describe what the system does, and that reading produces a written account the business can confirm before any rebuild starts. The same approach, for the broader case of a vanished developer, is in what to do when your developer disappears. Waiting does not make the code easier to read. It only raises the odds that the move happens under pressure, after a failure, instead of on a schedule the business chooses.

Frequently Asked Questions