Move Delphi client-server estates to a metadata-driven runtime.
The two-tier Delphi applications that still drive operations — with their VCL forms, Pascal business logic and direct database connectivity — refactored so the rules return to the data tier, the screens become metadata, and the application surface is delivered through a modern browser runtime. The data model survives intact.
The data model is the asset
Most Delphi estates rest on a robust relational model that has accumulated decades of fit with the business. The schema is imported as-is; the data continues to do the work.
Business rules move to the database
Pascal business logic embedded in the Delphi client is extracted, normalised and moved into the database tier as stored procedures and triggers — where the platform expects business logic to live. The rules become a native asset, governed by transactions.
No more thick-client deployment
The thick-client deployment model — installation, version management, network shares, BDE / ADO / FireDAC drivers, per-workstation configuration — is replaced by browser delivery on the platform's supervised runtime.
DataModule logic becomes server-side
Delphi DataModules — the central organisational unit for data access and shared business logic — are translated into a combination of metadata repository metadata (for query and view definitions) and server-side JavaScript handlers (for what metadata cannot express).
The five-layer methodology, applied to Delphi
From the database outward. Each layer is independently deliverable.
1 · Schema
The relational schema underneath the Delphi estate — whether Interbase / Firebird, SQL Server, Oracle or Informix — is imported into the metadata repository. Tables, indexes, sequences, constraints become rows the platform can recompile, against the same target engine if appropriate.
2 · Database business logic
Stored procedures and triggers that already live in the database stay. Business logic embedded in the Delphi client — Pascal code in DataModules and forms — is extracted, normalised, and moved into the database tier. The platform helps automate this extraction where the Delphi code follows recognisable patterns.
3 · DataModules and forms become metadata
Delphi DataModules — TQuery, TDataSet, TDataSource definitions — are reified as metadata rows. VCL forms — TForm definitions, TDBEdit / TDBGrid bindings, field validations, event handlers — are imported and translated into the metadata repository's UI model.
4 · Batch and middle tier
Server-side JavaScript on the platform handles what Delphi clients (or scheduled Delphi executables) once handled — integration, file handling, document generation, scheduled processing, external API calls.
5 · UI
Generated from the metadata, on Vue 3.5 / Vuetify 4. The VCL forms become responsive browser UI. The thick-client install-and-maintain model is replaced by browser delivery. Mobile delivery and role-aware rendering are properties of the runtime.
What changes for the operator
The customer's investment in the data model is preserved entirely. The Pascal client tier and the per-workstation deployment model — which most operators have come to regard as the harder operational problem than the application logic itself — are replaced by a supervised JVM-class runtime serving browser clients. The business rules return to the database tier where they can be transactional and where the platform's runtime reasons about them natively.
The team that delivers this is a database engineer, a Delphi- fluent analyst who can read the existing DataModules, and a business analyst who knows what the business expects of the system. The work is methodical extraction, not creative redesign.
A typical Delphi migration vs an Airtool migration
| A typical migration | An Airtool migration | |
|---|---|---|
| Approach | Re-write in C# / Java / web framework | ✓ Move logic to the data tier; generate the UI from metadata |
| Schema | Re-modelled to fit the target framework | ✓ Imported as-is into the metadata repository |
| Pascal logic | Translated into the target language, with the usual translation losses | ✓ Extracted into stored procedures and triggers (where it belongs) |
| VCL forms | Re-written by hand, one at a time | ✓ Imported as metadata; UI is generated at runtime |
| DataModules | Lost as a structural concept; rebuilt as repository / service layer | ✓ Reified as query / view metadata |
| Customer-side team | Full-stack developers, Delphi domain experts as advisors | ✓ Database engineer + Delphi-fluent analyst + our team |
| Cut-over | Big-bang at the end of an extended project | ✓ Incremental, module by module, parallel run |
Why Delphi estates are different
Delphi estates are different from Forms or 4GL estates because so much of the business logic lives in the client tier. The canonical pattern — DataModules that combine data access, basic validation and "shared business logic" — sits exactly where business logic should not be: outside the transactional perimeter, distributed across versioned client binaries, and opaque to anything that reads the database.
The migration is, fundamentally, a refactor: moving rules from the client tier into the data tier where they belong, and letting the platform generate the surface above. The result is an estate that runs in a browser, scales with the runtime, and enforces its own business rules transactionally regardless of what the application tier above does.
What Delphi shops ask before they engage.
Does the modernisation force a database change?
No. The relational schema underneath the Delphi estate — Interbase / Firebird, SQL Server, Oracle, Informix or another supported engine — is imported as-is into the metadata repository. The same target engine continues to do the work if the existing operational depth justifies it ; if a future re-platform makes sense, the metadata repository recompiles against the new target.
What happens to the Pascal business logic in DataModules and forms?
Pascal logic embedded in the Delphi client is extracted, normalised and moved into the database tier as stored procedures and triggers — where the platform expects business logic to live, where transactions can enforce it, and where the platform's runtime reasons about it natively. The platform helps automate the extraction where the Delphi code follows recognisable patterns.
How do DataModules port?
DataModules — TQuery, TDataSet, TDataSource definitions — are reified as query and view metadata rows in the metadata repository. The structural concept survives the migration : the central organisational unit for shared data access becomes repository metadata that the runtime materialises, not a repository / service layer that has to be rebuilt by hand.
What happens to VCL forms and the DBNavigator pattern?
VCL forms — TForm definitions, TDBEdit / TDBGrid bindings, field validations, event handlers — are imported and translated into the metadata repository's UI model. The classic DBNavigator record-by-record pattern becomes platform-standard grid and edit-form components, generated by the runtime on Vue 3.5 / Vuetify 4. The behaviour is preserved ; the rendering is modernised.
What about thick-client deployment, BDE / ADO / FireDAC and per-workstation versions?
All of it is replaced. The thick-client install-and-maintain model — workstation installs, version management, network shares, driver maintenance, per-workstation configuration — disappears at cut-over. Delivery is via browser on the platform's supervised runtime. The operational overhead of the Delphi client model — which most operators regard as the harder problem than the application logic itself — is no longer present.
Does the platform support Interbase or Firebird directly?
Interbase and Firebird are not first-class OLTP targets in the platform's seven-engine matrix. The supported migration path is to import the schema and re-platform onto one of the supported engines (PostgreSQL is the typical recommendation for Interbase / Firebird estates), with the database business logic ported as part of the same engagement. Customers with an operational reason to remain on Interbase or Firebird should raise it on the discovery call.
Related modernisation stacks
The five-layer methodology is the same across source stacks. The port-mapping detail is what differs.
From Informix 4GL & Genero
Schema imports as-is, SPL stays in the database tier, 4GL forms and menus reify as repository metadata. Informix stays as the OLTP target — or lifts to PostgreSQL when the workload calls for it.
From Oracle Forms
PL/SQL stays in the database tier, Forms triggers reify as repository metadata, the Forms Server and Application Server licences go away. The Oracle database stays — or lifts to PostgreSQL.
From PowerBuilder
DataWindows preserved as metadata, PowerScript moves to the database tier and to server-side JavaScript on the platform runtime, EAServer and two-tier deployment removed.
From custom J2EE
Bespoke Spring / EJB / Struts / JSF frameworks replaced by the metadata-driven runtime. Hand-written SQL, integration contracts and audit history are preserved.
From IBM i (AS/400)
DB2 for i schema imports through native DB2 connectivity, RPG and DDS reify as repository metadata, the 5250 green-screen surface becomes a browser. Stays on DB2 for i — or lifts to PostgreSQL.