Old Delphi applications: upgrade, rebuild or replace?

Delphi was one of the best tools of its era for building Windows business software, which is exactly why so many Delphi applications are still running. Order processing, job management, stock systems, practice management and countless off-the-shelf packages for specific trades were built in Delphi 1 to 7 and have carried on quietly for twenty years or more.

Many of the businesses using them don’t know they’re Delphi applications at all. They just know the system is old, the supplier has gone quiet, and it needs a particular PC or a fiddly database engine to keep going.

First, find out what you have

Three questions shape everything else.

Do you have the source code? For bespoke systems, it may be on an old developer’s machine, a backup tape, or nowhere. For packaged software, it belongs to the vendor, who may or may not still be trading.

Where does the data live? Many older Delphi applications use Paradox or dBase tables through the Borland Database Engine. Others use InterBase, Firebird, SQL Server or something else. The answer affects both the risk and the options.

What does it actually do? Not just the screens, but the rules, calculations and workarounds built into it over the years.

The options

Upgrade to a current version of Delphi

Delphi is still actively developed, and older projects can be brought forward to current versions. This keeps the application recognisable to its users and can remove the dependency on BDE along the way.

It’s a good fit when the code is sound and the business wants to keep a Windows desktop application. The catches are that older third-party components may no longer exist, the move to Unicode text in later versions needs care, and you remain dependent on finding Delphi developers.

Rebuild as a web application

A rebuild in modern web technology lets you keep the business logic that matters, drop years of workarounds, and add browser, remote and mobile access. AI-assisted tools have made it much faster to analyse an old codebase and carry its logic across than it was even a year or two ago, though the results still need an experienced eye to check them.

Replace with a packaged system

If what the application does is fairly standard, such as stock, orders, accounts or CRM, a platform such as Odoo may cover most of it, with your history migrated across and the gaps built as add-ons.

Keep it running, properly

Sometimes the right answer is to stabilise: document it, fix the BDE and network settings, make sure it can be rebuilt on a new PC, and plan the bigger move for later.

Getting your data out of Paradox tables

Whatever you choose, your data needs to come out cleanly. Paradox tables come with their own traps: separate files for memos and indexes, table-level passwords, and character-set issues that can corrupt pound signs and accented letters in the same way as old DBF files. A proper extraction checks record counts and totals against the live system so nothing is lost.

If the source code has been lost

This is more common than you’d think, and it isn’t necessarily the end of the road. Decompilers can recover parts of a compiled Delphi application, such as its forms and structure, but not a clean, maintainable copy of the original code. In practice the better route is usually to treat the running application and its data as the specification: document exactly what it does, extract the data, and build the replacement from that.

Where to start

A Health Check will establish what you have, whether the source code and data are in usable shape, and what each option would realistically cost.