Still running Paradox? Here is your exit plan
Paradox has not been meaningfully developed in well over a decade: the DOS line ended in the 1990s, and the Windows line, owned by Corel since 1996, survives only as a passenger in WordPerfect Office. The failure points are architectural: ISAM tables on a file share, locks coordinated through PDOXUSRS.NET, indexes that corrupt on unclean shutdowns. The reliable part is extraction, because .db tables are well understood. Your three exits: contain the risk, lift the data to SQL behind a thin front end, or rebuild as a web application with the old system running in parallel.
Somewhere on a shared drive there is a folder of .db files running your business, and nobody in the building will quite admit it. If the file name PDOXUSRS.NET produces a small involuntary sigh, this note is for you. Here is where Paradox actually stands in 2026, and the exit plan in the order we would run it.
The answer in one paragraph
Paradox is functionally abandoned. Ansa Software released it in 1985, Borland acquired it in 1987, and the Windows line passed to Corel in 1996 as part of WordPerfect Office, where it still nominally ships but has seen no meaningful development in well over a decade; the DOS line ended in the 1990s. The jeopardy is not the ageing forms and reports but the data layer: ISAM tables on a file share, no server, no transactions worth the name. The dependable good news is that .db tables are well understood, so extraction is the reliable part of any migration. Your exits: contain the risk, lift the data into SQL behind a thin front end, or rebuild as a web application with parallel running.
Forty years in one table
| Year | What happened | Where that leaves you in 2026 |
|---|---|---|
| 1985 | Ansa Software releases Paradox | Genuinely good software of its era, now past its fortieth birthday |
| 1987 | Borland acquires it | The Borland years supply the plumbing your system still depends on, including the Borland Database Engine |
| 1990s | The DOS line ends | Character-mode Paradox has been out of development since the last century |
| 1996 | The Windows line passes to Corel with WordPerfect Office | Where it still nominally ships. No meaningful development in well over a decade |
| 2026 | Nominal availability, no real development | Practical support is whoever still knows your system, for as long as the BDE tolerates your Windows |
The pattern to notice: at no point in four decades did anyone stand up and declare Paradox dead. It was handed along, deprioritised and left running. That is why so many businesses still sit on it; there was never a press release to force the decision.
The pains you already recognise
Nobody needs to tell a Paradox owner the failure modes; you have already named them. The PDOXUSRS.NET errors that appear when the lock file on the shared drive is missing, locked, or configured differently on one workstation than on the rest. The index corruption after an unclean shutdown, when a PC loses power mid-write and the tables no longer agree with their own indexes. The Borland Database Engine registry gymnastics required to keep everything standing on Windows 10 and 11. And the ritual: everyone out of the system, please, so we can reindex; observed at half past five with more discipline than the fire drill.
None of these are quirks to be patched around. They are the architecture showing through, and the architecture is the thing to worry about.
The real jeopardy is the data layer
Paradox tables are ISAM files on a file share. There is no database server: every workstation opens the table files directly and writes to them across the network, with locking coordinated through files rather than a server process; that is what PDOXUSRS.NET is. And there are no transactions worth the name: a crash mid-write simply leaves whatever half-written state it happens to leave.
Which means the integrity of your business data is maintained by folklore. The unwritten rules about who may be in which screen at which time; the reindex ritual; the knowledge that the import must finish before invoicing starts. Every additional concurrent writer shortens the odds on the next corruption. The application may be old and stable; the data layer fails suddenly, not gradually.
The good news: extraction is the reliable part
Here is the sentence Paradox owners least expect to hear: getting the data out is the dependable bit. The .db table format is decades old and thoroughly understood, and lifting tables into a modern SQL database is repeatable, verifiable work: row counts checked, totals reconciled, the extraction run as many times as it takes. We treat it as the start of the job, not the risk in it.
The real work is everything around the tables. The forms, the reports, the validation, and the business logic that lives half in the application and half in staff habit all have to be rebuilt against a database with real transactions, referential integrity and backups. That rebuild is the project. The data comes along quietly.
Three exits, honestly compared
| Exit | What it involves | When it is the right call |
|---|---|---|
| Contain | Backups proven by actually restoring one; fewer machines with write access; the BDE configuration written down while someone still knows it | You are not ready to move, or the system is shrinking in importance. Sensible as a deliberate holding position with an end date; corrosive as a default |
| Lift the data to SQL | Tables migrated into a modern database, with a thin front end preserving the familiar screens | The data risk is the urgent problem and the application around it is modest. Ends the corruption lottery without funding a full rebuild |
| Rebuild as a web application | Data extracted, behaviour rebuilt on a mainstream stack, old and new running side by side until the numbers match | The system is core to the business and will keep needing change. Costs the most once; the only option that ends the conversation entirely |
Containing is sometimes the right answer, and we say so when it is. But contain is a verb that needs an end date attached; as a permanent strategy it merely leaves the failure date to chance.
What to do, calmly
Three unglamorous moves this week. Restore a backup onto another machine and confirm the system actually runs from it. Count the workstations with write access to the tables and remove any that do not need it. Write down the BDE configuration and where PDOXUSRS.NET lives, while the person who set it up can still be asked.
Then compare the exits against your actual system rather than in the abstract. The Paradox migration page sets out how we lift .db tables into a modern database and rebuild around them; migration without downtime explains the parallel running that makes cutover uneventful; and the true cost of keeping a DOS-era system alive is the ledger to read when the budget conversation needs starting. The free Legacy Risk Audit applies all of this to your specific system: a 30-minute call and a one-page written risk summary.
The tables have run the business for decades and may run it a while yet. The point of a plan is that “a while yet” becomes a date you chose, rather than one you find out about.