Paradox Database Migration
for businesses in Australia, New Zealand, the UK and the US.
Paradox stopped being a serious product in the early 2000s and survives bundled with WordPerfect Office. If your business still runs on .db tables, you are almost certainly maintaining it alone.
- 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
Genuinely orphaned, and still holding real data
Paradox was a serious competitor to dBase and Access through the 1990s. It has no real successor and no migration path that anyone maintains. The applications that remain are typically membership registers, client records or job books that were built once and never revisited.
The blocker is almost never the application. It is getting the data out of .db tables cleanly, with the indexes, the memo fields and the date handling intact.
Your Paradox 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
Get the data out first, decide about the application second
The urgent part is the data. We extract every table including memo fields, reconcile it, and land it in a real database. Whether the application gets rebuilt is a separate decision you can take afterwards without pressure.
What you have now
- .db tables and .px indexes
- Memo fields in .mb files
- ObjectPAL scripts
- Forms and reports
Get the data out first, decide about the application second
The urgent part is the data. We extract every table including memo fields, reconcile it, and land it in a real database. Whether the application gets rebuilt is a separate decision you can take afterwards without pressure.
See how a project runsWhat you end up with
- Every table in SQL Server or PostgreSQL, reconciled row by row
- Memo and blob fields extracted rather than silently truncated
- A working application, or a clean database you can build on later
The 5 pieces of Paradox work we are asked for
Most engagements are some combination of these, and most start with the first.
Extract the tables
Every .db table read directly, including memo fields held in separate .mb files, which is where most partial extractions lose data.
Reconcile it
Row counts and control totals checked against the original before anything is trusted. Date and numeric handling in Paradox has enough quirks to be worth verifying.
Land it somewhere supported
SQL Server or PostgreSQL, with the relationships rebuilt and documented.
Rebuild the application if you want one
ObjectPAL logic and the forms translated into a web application. Some clients stop at the data and are content.
Keep an archive that opens
A readable archive of the original, so historical records remain accessible even if the application goes.
Where you are now
It works, and nobody will touch it
- No supported version and no vendor to call
- Data locked in .db and .mb files that modern tools do not read
- Runs on one ageing machine that nobody is allowed to turn off
- Every firm you have asked has declined the job
After
Supported, documented and yours
- Data in a current database, backed up like everything else
- Historical records readable without the original software
- The option to rebuild the application, on your timing
- One less machine nobody is allowed to touch
Scoped and quoted before you commit. You own the code, the documentation and the credentials at the end of it.
Get a fixed-price scopeParadox questions
Can Paradox data actually be recovered?
Yes. The .db format is well understood, and the memo fields in the paired .mb files are the part that partial extractions usually lose. We read both and reconcile the result against the original.
We only want the data, not a new application. Is that a job you take?
Yes, and it is often the sensible first step. Getting the data somewhere safe and readable removes the urgency, and you can decide about the application later without a deadline over you.
The only machine that runs it is very old. Does that matter?
It is the usual situation and it is a good reason to start now rather than later. We can work from a copy of the files; we do not need to keep that machine alive to do the extraction.
What about the ObjectPAL scripts?
They hold business rules worth keeping, so we read them as documentation even when the application is being rebuilt from scratch. They are often the only written record of how the process works.
How do we know nothing was lost?
Reconciliation. Row counts, control totals and spot checks on the awkward fields, given to you in writing before anything is switched off.
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.
