Delphi in 2026: modernise, upgrade or migrate?

“Is Delphi dead?” is the question owners ask; “which Delphi are we on?” is the one that matters. Here is the honest picture as of August 2026, era by era, and the four realistic ways forward.

The answer in one paragraph

Delphi the product is alive. It was born at Borland in 1995, passed through the CodeGear spin-off, and has been owned and actively developed by Embarcadero since 2008; new releases still ship in the RAD Studio line. Delphi the system in your back office is another matter. The classic era peaked with Delphi 7 in 2002, and that is the version a striking number of UK businesses still run, usually on top of the Borland Database Engine: a data layer deprecated around 2000 and never properly at home on any modern Windows. So the real question is not whether the vendor survives. It is whether a Delphi 7 application on the BDE can keep being changed safely, and by whom.

Every era, every date

Three facts fall out of that table.

First, if your system is on Delphi 7, the gap between your version and the current product is more than two decades of releases. The language survived; your dialect of it did not stay current, and everything the vendor has built since has moved the platform on from what your application is written in.

Second, the vendor being healthy does not help you. Ownership changed twice and development never stopped, which makes “Delphi is dead” comfortably wrong; but no release Embarcadero ships will modernise an application that nobody opens in an IDE any more.

Third, the vendor’s path leads to current Delphi, not away from it. Upgrading is their business, quite reasonably. If what you actually want is an exit to an open stack, that is a different trade, and it is the one we do.

The real problem is the BDE

Most classic-era Delphi systems do not store their data in anything a modern tool can read directly. They use the Borland Database Engine: Paradox or dBASE tables on a file share, coordinated through a shared locking file on the network. Borland deprecated the BDE around 2000, when most UK offices were still on dial-up, and no Windows since has properly supported it.

In practice that means failure modes practitioners know by heart: registry settings that must be coaxed into place on every new Windows 10 or 11 machine, permissions contortions because the engine assumes it can write where modern Windows says it cannot, and network locking quirks that can corrupt table indexes when a workstation drops off mid-write. Your application code may be perfectly sound. The floor it stands on was condemned a quarter of a century ago, and every new PC in the office makes the tenancy more awkward.

Four ways forward, honestly compared

Stay and contain. Legitimate if the system is stable and change requests are rare. Do the containment properly: image the machine that can still build the application, get the source code into version control, secure installers and licence keys, and write down the folklore. This costs days, not months, and it buys time; it changes nothing about the direction of travel.

Upgrade within Delphi. Move the code to a current release and replace the BDE with the modern data-access layers current Delphi provides, against a proper SQL database. Embarcadero supports this path; it is their business. It is genuine modernisation with one structural catch: you finish it still needing a Delphi developer permanently, and recruiting one in the UK is the very constraint that put you here. Sensible if you already employ one who is staying for years.

Replace the data layer only. Keep the Delphi front end and move the Paradox or dBASE tables into a modern SQL database. This removes the sharpest risks, corruption and locking, without touching most of the application. It is a half-step: the code, the platform and the skills question all remain. Sometimes a half-step is exactly what a business needs while it plans properly.

Rebuild as a web application. Rebuild the system’s actual behaviour on a modern stack, with the old system live in parallel until the new one has proven itself record for record. Highest up-front cost, and the only option that ends the platform question rather than deferring it. The general framework for choosing between these paths is written up in rewrite, refactor or replace.

The developer question decides it

Notice what actually separates the four options: not licensing, not technology, but people. Every option except the rebuild assumes a Delphi developer will exist in your orbit for years to come. Try advertising for one in the UK, with BDE experience, at a salary a small business can carry, and see what comes back.

Most classic-era Delphi systems we see are maintained by one person, often the original author, often within sight of retirement. If that person has already gone, the survival plan in “our software developer retired” applies word for word; only the platform differs. The deadline on your system is not printed on any vendor page. It is the working life of the last person who can safely change it.

What to do about it, calmly

A Delphi 7 system that has run for twenty years will probably run this quarter too; the point is to stop betting the business on that sentence staying true. Secure the source code, image the build machine, test a restore from your backups, and then pick a path with the facts in front of you rather than under pressure.

We compare staying, upgrading, the data-layer half-step and the full rebuild honestly on the Delphi modernisation page, and the same comparison for your specific system is what a free Legacy Risk Audit produces: a 30 minute call and a one-page written risk summary you can hand to whoever owns the decision.