Delphi application modernisation

Alive, and owned by Embarcadero, who release a new version most years and support upgrading a project from any earlier one. That's the difference from VB6 or FoxPro. A Delphi application isn't stranded by its language.

It's stranded by what surrounds it. Most old Delphi business systems use the Borland Database Engine for data access, and the BDE was deprecated around 2000, has had no security updates since 2002, and hasn't been part of the Delphi installer since XE8. Applications from before Delphi 2009 aren't Unicode, which matters the moment a customer's name has an accent in it. Third-party VCL components from the era often have no current version, or no findable licence. And the developers who wrote Object Pascal for a living are, like VB6 developers, retiring.

So a Delphi system usually runs fine and can't be built, or can be built and can't be changed safely, or can be changed and only by one person.

Readable code. Object Pascal ages well. The forms are in DFM files that describe every control, the logic is in units that can be followed, and the business rules are usually where you'd expect them.

The problems are underneath: BDE aliases pointing at Paradox tables or an old SQL Server driver, string handling from before Unicode, components that only compile on a Delphi version nobody has installed, and a build that lives on one machine.

Stay, and modernise in Delphi. Move the project to a current Delphi version. Replace the BDE with FireDAC, Embarcadero's current data access layer, and move Paradox or dBase tables to SQL Server. Convert to Unicode. Replace or update the third-party components. The application keeps its shape and its screens, and it's supportable again. This is the right answer when the application does its job, the business wants it as it is, and someone can be found to maintain Delphi.

Leave, in stages. Modern screens over the same data, one process at a time, in .NET or on the web, with the Delphi application still running against the same SQL Server database until the last process has moved. The right answer when the business needs the system outside the office, when the Delphi developer pool is the risk, or when the application's shape no longer fits.

Both, in that order. Often the best path: stabilise in Delphi first (FireDAC, SQL Server, a build that works), which makes the data shareable, then migrate processes out over time. The stabilised Delphi application becomes the fallback rather than the problem.

The assessment reads the code and prices each path as a fixed number.

The stage almost every old Delphi system needs first, whichever path follows.

1. Inventory the data access. Every BDE component, every alias, every Paradox or dBase table, every SQL statement.
2. Move the tables to SQL Server where they're still in Paradox or dBase, with the data reconciled.
3. Replace the BDE components with FireDAC, with tooling doing the mechanical part and a person doing the rest.
4. Convert to Unicode at the same time if the project predates Delphi 2009, because string handling changes anyway.
5. Test against a copy, then run in staging alongside the old build on the same data before switching.

At the end the application looks the same to its users and no longer depends on a component deprecated two decades ago.

If it's in SQL Server already, it stays there and both old and new can share it. If it's in Paradox or dBase tables, it moves once, to SQL Server, as the first stage. Either way it never meets a change until the change has proven itself somewhere else: tested on a copy in a test environment, then run in staging with the data reconciled, before anything connects to live.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a Delphi system it establishes the Delphi version, the data layer, the components and whether the project builds, then prices staying and leaving as fixed numbers. What drives the price and the payment terms each have a page.

The BDE, mostly. A data layer unpatched since 2002 on a network is a risk that doesn't announce itself. After that, the usual ones: a build that only works on one machine, components whose licence can't be found, and a developer pool that shrinks each year. None of them has a date. All of them get worse.

Stabilise the data layer first, then decide the rest on evidence. Marc Allington has worked in Delphi and in the .NET and web stacks it usually moves to, so both sides of the decision are familiar. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment.