Paradox Database Migration in 2026: Why It Is a Liability and How to Migrate Without Breaking the Business

Is Corel Paradox really still in maintenance mode in 2026?

Yes, and the timeline is longer than most buyers realize. Corel Paradox was last updated in any meaningful way with the Hot Fix 1 for X4 release in 2009. Every subsequent Paradox release bundled with WordPerfect Office, including the X5, X6, X7, X8, X9, and 2020 editions, ships with the same internal build number 11.0.0.676¹. The product is still sold. It just has not been developed for over fifteen years.

Why does Corel keep selling it? Because there is a long tail of customers who built business applications on Paradox in the 1990s and need access to their data. Keeping the product available is cheaper than supporting the migration. The result is that buyers paying for WordPerfect Office Professional 2020 are running the same Paradox engine that shipped in 2009.

Software does not stop working on the day development halts. The risk profile changes that day, and it keeps changing every year afterward.

What is the Borland Database Engine and why does Paradox depend on it?

The Borland Database Engine, known as BDE, is the runtime layer that every Paradox application uses to read and write .DB files. It was originally built by Borland in the early 1990s as a unified interface for desktop databases, then carried forward through Inprise and Embarcadero ownership of the Delphi and C++Builder tools that depended on it.

In 2014, Embarcadero removed the BDE installer from RAD Studio XE7 and reclassified it as a separate legacy download to make clear that the engine had been deprecated². The official guidance was to move to FireDAC for new development. BDE was not killed outright, because too many production Paradox applications still depended on it, but it stopped receiving any meaningful updates.

Three properties of BDE matter for buyers thinking about migration:

• 32-bit only. BDE was designed for a 32-bit world and cannot be extended to 64-bit³. Modern Windows runs 32-bit applications through the WOW64 compatibility layer, which is functional but not native.
• No Unicode support. BDE predates the Unicode shift in Windows. Applications that need to handle non-ASCII characters in modern business contexts hit hard limits.
• Concurrent user ceiling. Paradox tables accessed through BDE support a maximum of 255 concurrent users per table³. A growing business eventually hits that ceiling.

What actually breaks first when you stay on Paradox?

Three failure modes show up in the field, in roughly this order. None of them announce themselves before they happen.

How big is the Paradox installed base in 2026?

There is no clean public count of Paradox installations the way there is for newer platforms, partly because Paradox is bundled with WordPerfect Office and many customers do not separate the two when they report what they use. What is documented is the pattern of buyers actively planning to leave it.

A useful public data point: in 2016, the Queensland Government issued a public tender for Paradox support services covering 12 production databases, with the explicit goal of maintaining them while progressing a program of work to decommission or replace each one⁵. Public-sector procurement is years behind private-sector pain, which means buyers in industry have been quietly running the same decision tree, just without a public tender to make it visible.

The pattern PCG sees when buyers reach out matches this. A Paradox application built in 1997 or 1998 by one developer is now running a 30-person specialty manufacturer or a 25-person environmental services firm. The application works. Nobody has touched the ObjectPAL code in over a decade. The Windows server it runs on is older than several of the employees who use it daily.

Migrate, integrate, or replace: which path fits your application?

There is no single right answer. The three real options each fit a different situation, and the wrong choice wastes time, budget, and team capacity that the business needs elsewhere.

A third path, integration, is sometimes the realistic short-term move. Wrap the Paradox system in a modern API layer so new applications can read and write its data without depending on the BDE runtime directly. This buys time but does not retire the risk. It is a bridge, not a destination.

What does a real Paradox to SQL Server migration look like?

PCG has been running custom software projects since 1995. The migration pattern we use on Paradox work has been refined across a long list of legacy rescues. Its shape is consistent across projects. How long each phase takes depends entirely on the application being migrated.

Phase 1: Discovery

Read the .DB files. Read the ObjectPAL scripts. Read the BDE configuration. Inventory every form, report, query, secondary index, referential integrity rule, and external integration. The deliverable is a written inventory of what the application actually does, not what it was supposed to do. This is also where undocumented business rules surface, because they show up in the ObjectPAL code.

Phase 2: Architecture and quote

Decide the target stack, the SQL Server schema redesign, the integration points, the reporting tool, and the cutover sequence. PCG quotes a fixed price on the migration scope at this point. Not time and materials. Fixed scope, fixed price, with explicit assumptions documented.

Phase 3: Build in parallel

The new .NET application is built alongside the running Paradox system. Data flows are mirrored through BDE so the new system can be validated against current production results. Users are not asked to test anything until the team can stand behind the numbers.

Phase 4: Module-by-module cutover

Each functional area moves to the new application with a documented rollback path. Reports run in both systems for a defined period and outputs are compared. The Paradox application stays live until every module has cleared its checkpoint.

Phase 5: Decommission

Final data export, archive of the .DB files and the IDAPI32.cfg configuration for compliance retention, retirement of the BDE runtime. The decommission step is where compliance officers want documentation, and where the migration provides it.

What gets migrated and what gets rebuilt from scratch?

Not every piece of a Paradox application deserves to move. A careful migration is honest about which parts of the legacy system reflect business value and which parts reflect 1998 workarounds.

What if the original Paradox developer is gone?

Most Paradox migrations PCG quotes start exactly this way. The original ObjectPAL developer retired, moved on, or passed away years before anyone thought to capture what they knew about the system. Source files live on a network share that nobody has touched since the last meaningful change, which is usually dated somewhere between 2008 and 2015. Nobody currently on staff can answer a real question about how a particular calculation works.

This is a discovery problem, and it is solved by reading rather than interviewing. The .DB files, the ObjectPAL scripts, the BDE configuration, and the production data together describe what the application does. PCG works through this systematically during Phase 1 and produces a written inventory that the business can sign off on before any rewrite begins. The buyer ends Phase 1 knowing what they own, regardless of whether the migration moves forward.

What drives the scope of a Paradox migration?

Every migration timeline and quote depends on the specific application. Generic answers do not exist in this work, and any quote given before a discovery phase is a guess. Five measurable inputs determine the actual scope of the project.

• Table count and schema complexity: A 15-table Paradox schema with light referential integrity is a different project from a 90-table schema with extensive secondary indexes and validity checks.
• ObjectPAL line count: Total scripting size across all forms, reports, and library files. Some Paradox applications carry thousands of lines of ObjectPAL, others almost none.
• Report count and complexity: Each Paradox report is a small project of its own. Forty reports take longer than ten.
• Integration count: Each external system the application talks to (accounting, payroll, EDI, hardware, file imports) adds discovery and rebuild time.
• BDE deployment footprint: Whether the application runs single-user on one machine or multi-user across a shared NetFile drives both the migration scope and the cutover plan.

PCG runs a fixed-fee discovery phase before quoting the migration itself. The deliverable from discovery is a written inventory of what the application does, the migration approach, and a fixed scope and timeline based on real numbers from the codebase and the BDE configuration. Buyers who go through discovery keep the deliverable whether or not they proceed to migration.

How do you avoid breaking the business during the migration?

Parallel operation is non-negotiable. The Paradox system stays in production while the new SQL Server application is built and validated. Data is synchronized between the two systems during the build phase so the new application can be tested against current production results, not stale snapshots.

Cutover happens module by module. Each module clears a defined checkpoint before the next one moves. A documented rollback path exists at every step. If something fails in the new system, the team rolls back to Paradox in minutes, not in a weekend war room. Big-bang cutover, where a business migrates everything in one weekend, fails often enough that PCG no longer offers it as an option.

31 years of running custom software projects has taught us one thing about legacy migrations: the technical risk is manageable, and the business continuity risk is what actually sinks projects.

Frequently Asked Questions