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 dictionary 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 dictionary. 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 dictionary'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 dictionary |
| 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.