dBase & Clipper Migration
for businesses in Australia, New Zealand, the UK and the US.
CA-Clipper last shipped in the mid 1990s and compiles to DOS executables. dBase applications of the same era are still running Australian businesses, usually inside a virtual machine nobody wants to touch.
- Independent No licence commission, no reseller agenda
- 18+ yrs Building business software
- Fixed Price scopes, no surprises
- AU NZ UK US Perth-based, working remotely
DOS-era software, still doing the books
These systems are older than most of the people asked to maintain them. Clipper compiled to a DOS executable, dBase applications ran from interpreted .prg files, and both stored data in .dbf tables. Many now run inside a virtual machine or a DOS emulator on a modern server, which works until it does not.
The good news is that .dbf is a documented, readable format. The data is recoverable. The application logic usually is too, if the .prg source survived.
Your dBase / Clipper project, end to end
Three stages. Scoped and fixed-price before anything starts, delivered by the founder, and your existing system stays running until cutover.
-
Week 0
Read the system as it is
We go through the existing application and record what it actually does, including the parts nobody documented. You get a written inventory and a fixed price before any build starts.
-
Weeks 1-N
Rebuild and run in parallel
The replacement runs beside the original until the numbers reconcile. The old system stays untouched and switched on the whole time.
-
Cutover
Go live and hand over
Cutover on a date you choose, then thirty days of support. Source code, documentation and credentials are handed to you, in your name.
What the work actually is
The data comes out even when the source is gone
The .dbf format is readable regardless of what happened to the source code. We extract and reconcile the data first. If the .prg files survived, they give us the business rules to rebuild against.
What you have now
- .dbf tables with .ntx or .cdx indexes
- Compiled .exe with the source possibly lost
- .prg source files if you still have them
- A DOS emulator or virtual machine
The data comes out even when the source is gone
The .dbf format is readable regardless of what happened to the source code. We extract and reconcile the data first. If the .prg files survived, they give us the business rules to rebuild against.
See how a project runsWhat you end up with
- Data extracted, reconciled and loaded into a supported database
- The business rules documented from the source where it exists
- A modern application, or at minimum a readable archive
The 5 pieces of dBase / Clipper work we are asked for
Most engagements are some combination of these, and most start with the first.
Extract the .dbf tables
Read directly with the index and memo files handled properly. This works whether or not the original source code still exists.
Recover the logic where possible
If the .prg source survived, it documents the business rules. If only the compiled executable remains, we work from the data and from your staff instead.
Reconcile before trusting
Row counts and totals matched against the original, including the date and numeric handling quirks of the era.
Rebuild the application
A web application that reproduces the workflow, generally with the same key sequences your long-serving staff already have in muscle memory.
Retire the emulator
Once the replacement reconciles, the DOS virtual machine can finally be switched off.
Where you are now
It works, and nobody will touch it
- Runs in a DOS emulator or a virtual machine that must never be restarted
- The original source code may have been lost years ago
- One retired contractor is the only support option
- No backup anyone has tested in this decade
After
Supported, documented and yours
- Data in a supported database with real backups
- Business rules written down instead of held in one person’s memory
- An application that runs on current hardware
- A readable archive of the original records
Scoped and quoted before you commit. You own the code, the documentation and the credentials at the end of it.
Get a fixed-price scopedBase / Clipper questions
We lost the source code. Is the data still recoverable?
Yes. The .dbf format is documented and readable on its own, so the data comes out regardless of what happened to the .prg files or the compiled executable. Losing the source makes rebuilding the logic harder, not the extraction.
Can you read the memo and index files too?
Yes. Memo fields and the .ntx or .cdx indexes are handled as part of the extraction. Memo fields are where partial extractions most often lose content without anyone noticing.
The system only runs in DOSBox. Can you still work with it?
That is a very common situation. We work from a copy of the data files, so we do not need to keep the emulator running to do the extraction.
Is it worth rebuilding, or just archiving?
Depends on whether the process is still live. If staff use it daily, rebuild. If it is only consulted for history, a readable archive and a reporting view is far cheaper and we will recommend that.
Nobody else would quote on this. Why will you?
Because the formats are documented and the work is methodical rather than mysterious. The main reason firms decline is that they have never seen a .dbf file, not that the job is impossible.
Sending your details…
You can stay on this page while we send it.
Tell us what you are running
What the system does, roughly how old it is, and what is forcing the question. We will come back with a straight answer and a fixed-price scope, even if the answer is to leave it alone.
Prefer a quick chat? Call 0425 531 127. We answer the phone in Perth.
