Service · Software development

Modernise your Delphi application.

A grey Windows application that has been around for years, built in Delphi with Object Pascal and a Visual Component Library interface that nobody dares touch any more. The database underneath is a Paradox file, an InterBase server or a Firebird installation that has never been updated. We build a modern, web-based layer alongside it, in phases and without daily operations grinding to a halt.

Arrange an introductory call See our work

↻

A Delphi application is not ordinary legacy software.

Delphi applications are recognisable by a consistent set of traits. A locally installed .exe on each workstation, a typical grey VCL interface with square buttons, and a database that is almost never a modern relational server but a Paradox file, a dBase table, or an InterBase or Firebird installation accessed through the Borland Database Engine. There is no web access and no mobile version, and the application is often tied to one specific version of Windows, because drivers or the BDE configuration stop working on newer versions.

This makes replacing a Delphi application in practice often more urgent than an average legacy replacement, as we describe on replacing legacy software. The number of developers still actively working with Object Pascal and the Visual Component Library has shrunk considerably, and the application usually runs on a single machine or one specific Windows version rather than on redundant infrastructure. If that one machine fails, an entire business process often stops: administration, scheduling, stock or production.

This page is a deeper look at our wider approach to modernising legacy software, specifically tailored to what makes Delphi applications difficult: the closed VCL architecture, the lack of integration options, and a database layer that is rarely accessible in a modern way. Our approach starts with understanding exactly what the application does, before we decide how and in what order to replace it.

How we approach Delphi projects.

Strangler-first

A new web/API layer alongside the existing Delphi app, taking over functionality one feature at a time

Discovery phase

Screens, business rules and database structure mapped out before we build

Data ownership

Full migration out of Paradox, InterBase or Firebird with validation and a rollback path

Build or buy

Each module assessed individually, with custom development where it genuinely differentiates

Three ways to modernise a Delphi application.

The right route depends on the size of the application, the number of screens, the state of the underlying database and the number of external systems it talks to. The three approaches below together cover the vast majority of the Delphi projects we get involved in.

Approach 01

Strangler pattern: new web/API layer alongside the Delphi app

The standard route for Delphi projects

We build a new web and API layer that runs alongside the existing Delphi application and exposes the same underlying data and business rules. Feature by feature, usually starting with the simplest screens, we redirect users to the new layer. The Delphi application remains active in the meantime for anything not yet migrated, and is only switched off once the last feature has been moved over.

For your team, this means there is never a moment when everything changes at once. No weekend in which administration, planning or production grinds to a halt, no all-or-nothing risk, and room to get used to the new screens while the familiar application continues to run in the background for whatever is not yet ready.

Web/API layerModule-by-moduleParallel runningAnti-corruption layerFeature parity firstPhased rollout

Approach 02

Data migration from Paradox, InterBase or Firebird

The core of every Delphi project

Most Delphi applications run on a Borland Database Engine connection to Paradox tables or dBase files, or on an InterBase server. Firebird is the open source fork that emerged from InterBase in the early 2000s and is often found in practice as a later replacement, sometimes in a version that has not been updated for years. We start with a data audit: how many tables and records there are, which fields are missing or inconsistent, and which business rules exist only implicitly in the Delphi code and not in the database itself.

On that basis we build a migration path to a modern relational database, with a validation suite that compares every migration run against the original on record counts, key fields and referential integrity. We keep the old Paradox, InterBase or Firebird environment available read-only as an archive until well after the cut-over, so a rollback path always remains open.

Data auditParadox/dBase exportInterBase/Firebird migrationValidation suiteReferential integrityArchive copy

Approach 03

Lift and shift: API layer around the existing Delphi logic

When the Delphi app can partly stay

Not every part of a Delphi application needs to be replaced straight away. Sometimes it is enough to build an API layer around the existing logic and database, so that other systems and a new web interface can communicate with it through a clean interface without the underlying application being rebuilt immediately. The Delphi application then keeps running in the background, often on virtualised or isolated infrastructure so that dependence on a single physical machine is removed.

We make the build-versus-buy decision module by module. For a standard process such as accounting there is often no reason to build custom software, as a suitable package exists. For the part that was originally built in Delphi precisely because it makes your way of working unique, we deliberately build a modern replacement.

API wrapperVirtualisationBuild vs buyHybrid landscapeIntegration layerCustom add-on

What you have at the end.

A web-based application that no longer depends on the goodwill of a single workstation, a single Windows version and a single developer who still understands the Delphi code.

Production + staging

Two environments, in your own cloud or hosted by us, your choice.

Codebase + architecture documentation

Full source code, build instructions and an overview of all decisions made.

Migration report

Which data from Paradox, InterBase or Firebird has been migrated, and which validations have been carried out.

Decommissioning plan

How and when the Delphi application is switched off, and which read-only archive remains behind.

Managed service (optional)

Monitoring, backups, security patches and ongoing development under a maintenance contract.

What makes a Delphi application recognisable.

Four characteristics that make Delphi applications a little more urgent to replace than the average legacy system, and where we are usually first invited to an introductory conversation before anything concrete is planned.

Platform

One version of Windows, often one machine

The application is built on the Visual Component Library and runs best, or sometimes only, on a specific version of Windows with matching drivers and the Borland Database Engine configured. An operating system upgrade is a risk in itself. If the machine fails, an entire process often grinds to a halt.

Skills

Almost no Delphi developers left to hire

Object Pascal and the VCL are no longer an active choice for new projects, so the pool of developers who still know the language and framework well has shrunk considerably. Bringing a new developer up to speed on an old Delphi codebase takes more time and effort than building afresh on a modern stack.

Database

A Paradox file or an old InterBase or Firebird server

The data often sits in local Paradox tables or dBase files accessed through the Borland Database Engine, or in an InterBase or Firebird server that has not been updated for years. Backups, replication and security patches are usually minimal at these database layers.

Integrations

Hardly integrable with modern systems

There is no REST or JSON API, only file exports, shared folders or manual re-keying into other systems. Reporting often runs through QuickReport or Crystal Reports, for which we have a separate deep dive on replacing Crystal Reports. Every integration that exists today is a manual process that will need to be redesigned during replacement.

Risks we address explicitly.

Modernising a Delphi application is not a purely technical project; it is a change that affects your operations. Four risk categories we place at the top of every engagement.

Data

Data loss during migration from Paradox or Firebird

Old Paradox tables and InterBase or Firebird databases often contain duplicate records, missing references and characters that the old system silently tolerated. We carry out a data audit upfront, build a validation suite that compares each migration run against the original, and keep a rollback path open well beyond the cut-over.

Functionality

Erosion of functionality and forgotten screens

The Delphi application often still does things nobody is aware of any longer: a nightly export, a specific report for the management board, a correction screen opened only once a quarter. We conduct stakeholder interviews per user group and run shadow tests in which the old and new systems process the same input in parallel.

Continuity

Business disruption during cut-over

Because Delphi applications often run on a single machine, the risk of a disrupted transition is greater than in a distributed, redundant environment. We phase each transition so that one sub-process moves over at a time, schedule cut-overs for quiet periods and keep a rollback script ready.

Adoption

User resistance from people used to the old screens

People who have worked for years with the same VCL screens often find a web interface unfamiliar at first, even when it is objectively faster and more accessible. We involve key users from the outset, build workflows that respect the old shortcuts and sequence, and organise training so that the transition does not feel like a loss.

How a Delphi modernisation project runs.

01Introduction→ 02Discovery→ 03Build & migration→ 04Cut-over & support

Step 01

Introduction

We look at which Delphi application you run, how old the code is, which database sits underneath, and which pain points are most urgent. A no-obligation conversation with your IT team and the departments that use the application every day.

Step 02

Discovery and architecture

We document the existing screens and business rules, interview end users, carry out a data audit on Paradox, InterBase or Firebird, and choose per module between a strangler approach, lift-and-shift or a full rewrite.

Step 03

Build & data migration

Working modules delivered in sprints, running in parallel with the existing Delphi application, a validation suite for the data migration, and regular shadow tests on real input.

Step 04

Cut-over & decommissioning

A phased handover per business process, with a rollback path ready, emptying the Delphi application and eventually switching it off. A read-only archive of the old database remains available.

From Delphi, Paradox and Firebird to a modern stack.

Delphi is a development platform originally from Borland, later Embarcadero, based on the Object Pascal programming language with the Visual Component Library as its GUI framework. Database access traditionally ran through the Borland Database Engine to Paradox and dBase files, or to InterBase, of which Firebird is the open source fork. We carry out similar projects for other stacks from the same era, such as replacing FoxPro applications. See also the broader overview under software development as a starting point.

The Delphi stack we encounter

Delphi / Object PascalVCLBorland Database EngineParadoxdBaseInterBaseFirebirdQuickReport / Crystal ReportsRAD Studio

Target stack, frontend and backend

Next.jsAstroReactNode.jsPython.NET 8PostgreSQLRedis

Migration, infrastructure & integration

Strangler routingETL pipelinesAPI layerAuth0Azure ADGCP/AWSDockerAnti-corruption layer

Frequently asked questions.

How do I tell whether our application is a Delphi application?

A few signs almost always recur: a grey Windows interface with square buttons and a typical VCL look, an .exe installed locally on every workstation, error messages that refer to the Borland Database Engine or a BDE alias, and a database made up of Paradox tables, dBase files, or an InterBase or Firebird server. Often the application has been running for many years without any significant architectural changes. If this sounds familiar, there is a good chance you are dealing with Delphi.

Why is replacing a Delphi application often more urgent than with a more modern stack?

A Delphi application is typically tied more tightly to one specific version of Windows, one set of drivers, and sometimes even one physical machine than an average web application. The number of developers still actively working with Object Pascal and the Visual Component Library has shrunk considerably in recent years, making it increasingly difficult to replace staff or extend functionality. In addition, a Delphi application rarely offers web access or a mobile variant, while the rest of your software landscape has moved in that direction. The combination of scarce expertise, a fragile platform and missing accessibility makes postponing riskier than with newer systems.

Can we carry on working with the existing Delphi application during the modernisation?

Yes. We almost always work according to a strangler pattern: a new web and API layer is built alongside the existing Delphi application, and functionality is redirected to the new layer feature by feature as each one is ready. Meanwhile, the old application keeps running as normal for the parts not yet migrated. Your team therefore never works with a system that switches over all at once, and there is no moment when the entire operation depends on a single cut-over.

What happens to our data in Paradox, InterBase or Firebird?

We start with a data audit: how many tables and records there are, which fields are missing or corrupted, and which business rules are implicitly embedded in the Delphi code rather than in the database itself. Based on that, we build a migration path to a modern relational database, with a validation suite that compares every migration run against the original on record counts, key fields and referential integrity. We keep the old Paradox, InterBase or Firebird database available as a read-only archive until well after the cut-over.

Is it possible to add just a web interface without replacing the entire Delphi application?

Yes, that is exactly what a lift-and-shift approach involves. We build an API layer around the existing Delphi logic and database, so that other systems and a new web interface can communicate with it through a clean interface, without the underlying application being rebuilt straight away. This is a sensible intermediate step when certain parts of the Delphi application can keep running for a while, or when external accessibility is the immediate problem.

What if the original Delphi developer can no longer be found?

With Delphi projects, this is more often the rule than the exception, and it is not a blocker. In the discovery phase, we reverse-engineer the existing application: analysing the Object Pascal source code where it is available, interviewing end users about their actual workflows, and analysing the database structure to reconstruct business rules that are nowhere documented. Where the source code itself is missing, we reconstruct the behaviour from the database and observed usage, and set up shadow tests to make any deviations visible before the cut-over.

What determines the approach and scope of a Delphi modernisation project?

The main factors are the size of the application, the number of screens and reports, the state of the underlying database, the number of integrations with other systems, and how well the source code and business rules can still be understood. A compact Delphi application with a straightforward Paradox or Firebird database is a different project from a large production system with dozens of screens and integrations to accounting, scheduling and inventory. After the discovery phase, we give you an honest estimate of the approach and phasing, rather than one upfront.

Do we retain ownership of the new software and data?

Yes, fully. The code, infrastructure, documentation and credentials are registered in your name, in a repository that you manage or that is handed over to you at the end of the project. The migrated data also remains entirely yours, with a documented export format for any future migrations. If you opt for our management service after handover, all code and infrastructure still remains yours. Management is a service, not vendor lock-in.

Talk to us about your Delphi application.

An introductory, no-obligation conversation. We listen to what is currently running, which database sits underneath, where it hurts, and what has prompted you to look at it now, even if it turns out that replacement is not the right route at this stage.

Schedule an introductory call Email fabian.vandijk@appfront.nl