Delphi ↔ Java architect
Bridge between Object Pascal/VCL and the modern Java ecosystem, able to map Delphi patterns and define Java equivalents
Loading...
Loading...
Migration of Delphi applications (Object Pascal, VCL, FireDAC) to Java 21 and Spring Boot, under the ATLAS methodology. Legacy capture, characterization tests, pattern-by-pattern migration, parity audit, REST API exposure for cloud integration and agentic workflows.
Each phase aggregates one or more of the ten ATLAS steps. No phase starts until the previous one has delivered its validated artefact. The ATLAS methodology makes AS/400 migration predictable and auditable.
Understand the Delphi estate: projects, DFM forms, DataModule, BPL, third-party components, native Windows integrations. Rebuild a functional analysis from the code. Define scope, constraints, success criteria, target architecture choice (web SPA, Vaadin, JavaFX).
Set the ground truth: captured VCL screens, datasets, printed reports, key transactions. Map subsystems, third-party components (DevExpress, TMS, FastReport) and their Java equivalents, FireDAC or dbExpress schemas, Windows COM/OLE integrations to replace.
Design the target Java architecture: Spring Boot, JPA, managed PostgreSQL, Docker containerization, OpenAPI-documented REST API exposure, separate SPA frontend or Vaadin. Define cloud strategy (Azure App Service, AWS Elastic Beanstalk, GCP Cloud Run, self-managed Kubernetes) and observability. Prepare characterization tests.
Translate Pascal → Java pattern by pattern: properties → Lombok getter/setter, FireDAC → Spring Data JPA, VCL Form → REST endpoint + frontend component, TObject lifecycle → Java garbage collection. Incremental subsystem migration, parallel runs, internal parity audit per batch. Boundary tests (overflow, nullity, encoding) added to characterization suite.
Progressive go-live with Delphi ↔ Java coexistence during transition (duration set at scoping based on risk profile), batched transactional cutover, REST API exposure to cloud workflows and third-party integrations, ops handover to client team with documentation and pair-programming.
Automatic legacy-code conversion tools produce code that compiles but stays unreadable and unmaintainable: original patterns are copied as-is, without idiomatization, with dependencies on a proprietary runtime. Pushed to production without full re-characterization, this code is neither reliable nor scalable. End-to-end automatic translation isn't a modernization method — it's a debt transfer.
Our approach is the opposite. ATLAS relies on multiple readings of the legacy code, from several angles: data flows, business rules, dependencies, edge cases. AI comes in as a comprehension accelerator — to decipher decades of accumulated business logic, reverse-document uncommented branches, surface the intent behind the code. It doesn't decide and it doesn't translate: it informs the architect's work, who then designs the target architecture (cloud, database, services) and drives the migration pattern by pattern, under parity audit.
This understanding still requires humans who know legacy languages. That's our edge: where Europe and North America face a retirement wave among mainframe and legacy developers, Tunisia retains a pool of experienced developers (COBOL, Delphi, PowerBuilder, RPG…). Paired with modern architects and developers trained in the ATLAS method, they ensure continuity between the original business intent and the target system.
Delphi (Object Pascal on VCL, then FireMonkey) remains present in industrial SMEs, regional and mutualist banks, insurers, and business software vendors (sectoral ERPs, management applications, scientific and technical software) developed between 1995 and 2015. Its historical strength: RAD productivity (Rapid Application Development) — a single developer could deliver a full desktop application with embedded database, rich forms, and printed reports in a few weeks. Its weakness today: inactive Embarcadero vendor, rapidly thinning Delphi developer pool, client-server architecture incompatible with mobile, modern web, and cloud-native. Adjacent 4GL family: PowerBuilder follows the same migration patterns.
Three forces drive migration. First, the gradual disappearance of Delphi developers: profiles trained in the 2000s are retiring or reconverting, with almost no new graduates. Second, the accumulated technical debt on third-party components (DevExpress, TMS, FastReport) whose older versions are no longer supported and prevent Windows OS upgrades. Third, and often the trigger, the impossibility of opening the application to modern channels: mobile, web, third-party APIs, cloud workflows, AI agents. Our ATLAS methodology frames this transition predictably, without service disruption.
Java as a Delphi target makes sense when the target IT ecosystem is Java-dominated (integration with existing Spring applications, Java ERP, Java EE middleware), when the organization has strong internal Java expertise but no C# expertise, or when multi-OS portability is required (Linux server preferred). But the real gain goes beyond a code-for-code port: Spring Boot natively exposes business logic as REST APIs, which transforms a closed desktop application into composable services consumable by cloud workflows (Azure Logic Apps, AWS Step Functions, n8n, Power Automate, Make), AI agents, and third-party integrations. Data trapped in a Paradox database becomes a governed, observable, monetizable API source. If Microsoft dominates the IT, see Delphi to .NET Core. If the goal is true cloud-native web modernization, see Delphi to TypeScript.
Delphi (Object Pascal, VCL, FireDAC, dbExpress, third-party components)
Java 21, Spring Boot, JPA, PostgreSQL, REST API, SPA or JavaFX frontend
Default choice: web modernization, native REST API exposure, integration with cloud workflows and AI agents. Separate React or Angular frontend for true modern UX.
Confirmed desktop need (offline mode, hardware integration, native performance, internal Windows user constraints). JavaFX only if Java is imposed by the target IT — otherwise .NET Core WinForms is simpler.
Backend-heavy Java team without SPA frontend expertise, low-traffic internal applications, time-to-market over UX. Vaadin hides the frontend but limits interactive richness.
Microsoft ecosystem → Delphi to .NET Core (Pascal-C# syntactic proximity). Pure cloud-native web modernization → Delphi to TypeScript (larger rewrite effort but most open target).
A Delphi to Java migration is planned as a sequence of functional batches, with the cadence set at scoping based on volume, the number of VCL screens, and the target interface (SPA web, Vaadin, or JavaFX desktop). The typical cell combines a Delphi-Java architect, a senior Java tech lead, Java developers (ideally with Pascal or C++ background to understand strict typing and object model), a senior Delphi developer for business knowledge (essential early in the program), a UX designer if web redesign, a QA specialized in characterization tests, and a DBA for embedded database migration. Composition and headcount are not fixed upfront: they are determined after the POC and scoping, once the real work has been measured. Pascal-Java syntactic distance is more pronounced than Pascal-C#: plan deep Java training for transitioning Delphi developers.
Underestimating the Pascal-Java syntactic distance. Unlike C#, Java has no native properties, no delegates, no records before Java 16, automatic memory management via GC (vs explicit TObject lifecycle in Delphi), no native set type, no variants.
Documented and tested translation patterns: Pascal properties → Java getter/setter with Lombok or Java records, delegates → Java 8+ functional interfaces, Pascal sets → Java EnumSet, variants → generic Object or Java 21 sealed classes. Unit parity tests on each pattern. Principle P1 — tests first, migration second systematically applied.
Choosing JavaFX desktop by default without re-evaluating the business need. JavaFX is less maintained than Swing, much less rich than React/Angular for web, and requires the end user to install the Java runtime. For most Delphi applications, it is a false continuity choice.
Systematic re-evaluation of desktop vs web need during phase E4 Target architecture. If users are internal on Windows, .NET Core WinForms may be simpler. If true modernization is desired, separate SPA frontend (React, Angular) with Spring Boot backend. JavaFX only if Java is imposed and offline need is proven.
Not anticipating the handling of Delphi third-party components (DevExpress VCL, TMS, FastReport, EhLib). These components have no direct Java equivalent — concerned screens often have to be rewritten using native target framework primitives (AG Grid for grids, JasperReports or Apache POI for reports, ApexCharts for charts).
Exhaustive mapping of third-party components from phase E2 Discovery. For each identified component, explicit mapping to its modern Java equivalent and estimation of rewrite effort. Include this effort in the initial scoping — it typically represents 30% to 50% of the total UI effort on a mature Delphi application.
Migrating code-for-code without rethinking business-logic exposure. This misses the opportunity to transform the desktop application into services consumable by cloud workflows, AI agents, or third-party integrations — delivering a modern Java that is just as closed as the original Delphi.
REST-API-oriented target architecture from phase E4: Spring Boot exposes business logic as documented REST endpoints (OpenAPI), with standard authentication (OAuth2, JWT), versioning, observability (Micrometer + Prometheus). The UI consumes the API like any other client — cloud workflow, n8n, Power Automate, AI agent. This is what justifies the migration beyond mere technical debt.
Declaring the migration complete after code conversion, without validating real user workflows or functional parity on the client's datasets. Screens may compile and display correctly while breaking a business calculation inherited from a specific Delphi RTL.
Principle E7 — browser and business workflow validation mandatory before delivery. Parallel runs Delphi / Java on key transactions, automated comparison of results, parity audit with an internal classified discrepancy registry following a CRITICAL / ADAPTATION / COSMETIC grid. No cutover without proven parity on critical workflows.
Several distinct profiles, mobilized over the full program duration. Reproducing this cell internally is rarely realistic — the legacy skills shortage and ATLAS expertise depth make outsourcing structurally faster and less risky.
Bridge between Object Pascal/VCL and the modern Java ecosystem, able to map Delphi patterns and define Java equivalents
Java 21, Spring Boot, JPA, REST API design, Pascal→Java migration patterns, line-by-line traceability
Ideally with Pascal or C++ background to understand strict typing and object model; dedicated Java training for transitioning Delphi developers
Accumulated business knowledge, legacy code reading, resolving interpretation ambiguities early in the program (essential)
Web ergonomic redesign (React, Angular, or Vaadin), responsive, accessibility — only if web target (not required for JavaFX)
Migration of embedded databases (Paradox, Firebird, dBase, local SQL Server) or historical DBMS to PostgreSQL, data parity audit
Characterization test bench, legacy/target comparison, ATLAS audit validation
Three cases justify Java: (1) target IT dominated by Java (Spring, JEE, existing integrations), (2) organization with strong internal Java expertise without C# expertise, (3) multi-OS portability required with Linux server preferred. Otherwise, .NET Core is more natural (Pascal-C# syntactic proximity) or TypeScript if the goal is pure cloud-native web. The ATLAS methodology applies to all three targets with the same rigor.
This is the most underestimated opportunity of this modernization. Data historically trapped in embedded databases (Paradox, Firebird, dBase, local SQL Server) is migrated to managed PostgreSQL (Azure Database for PostgreSQL, AWS RDS, GCP Cloud SQL, or on-premise per strategy). Business logic is exposed as OpenAPI-documented REST APIs by Spring Boot. Concretely, this enables: (1) consumption by cloud workflows (Azure Logic Apps, n8n, Power Automate, Make, AWS Step Functions), (2) integration with AI agents that can query or feed the system, (3) opening to modern channels (mobile, customer portal, partner integrations) without additional redesign. The application leaves the desktop to become a composable service.
These components have no direct Java equivalent — concerned screens have to be rewritten using native target framework primitives. Typical mapping: DevExpress grids → AG Grid (web side) or JavaFX TableView (desktop side); TMS Aurelius → Spring Data JPA; FastReport → JasperReports, Apache POI, or Stimulsoft Java; EhLib → web spreadsheet components (Handsontable, SpreadJS) or extended JavaFX TableView. This rewrite effort typically represents 30% to 50% of the total UI effort on a mature Delphi application — it must be included in initial scoping, not discovered mid-program.
Separate SPA (React or Angular): default choice for any true web modernization. Modern UX, mobile-friendly, maximum cloud opening, large talent pool. More initial effort but durable investment. Server-side Vaadin: for backend-heavy Java teams without frontend skills, low-traffic internal applications, time-to-market priority. Limits interactive richness. JavaFX desktop: only if desktop need is confirmed (offline mode, hardware integration, native performance) AND if Java is imposed by the target IT. Otherwise, .NET Core WinForms is simpler for staying Windows desktop. The decision is taken in phase E4 Target architecture, not by default.
For a Delphi application of 50 to 100 thousand lines in nearshore co-delivery with web frontend target, plan €600k to €1M including UX, development, tests, parity audit, and documentation. For larger applications (200k+ lines, multi-module, many third-party components), plan €1.2M to €2M over 12 to 18 months. Equivalent cost to .NET Core on comparable volumes, slightly higher if deep Java training for the transitioning Delphi team. We frame pricing during the Intake phase with an explicit range. See delivery models.
Yes, but not on its own. AI accelerates two things: reading Delphi code (mapping DFM form intent, extracting business logic from VCL events, identifying dead code) and writing target Java code pattern by pattern with traceability. We measure 2x to 3x throughput on legacy migration projects when AI is paired with a structured methodology and systematic human review. What AI does not replace: the Discovery phase (understanding third-party components used, native Windows integrations, specific RTLs), characterization tests written before any target code is touched, and parity audit on real datasets. Our position: AI is the default operating mode (vibe coding) inside the ATLAS methodology — never a replacement for it.
Yes, during the Delphi/Java coexistence phase. These profiles remain valuable for two reasons: resolving interpretation ambiguities on business rules undocumented in the original Delphi code, and supporting parity tests on edge cases rarely covered by documentation. Once this business knowledge has been sufficiently absorbed on the Java side, these profiles evolve into architecture, governance, or a new scope. Keeping a senior Delphi developer during the Delphi/Java coexistence phase is non-negotiable — it is the safety net that prevents silent regressions.
It depends on volume, number of VCL screens, and modernization ambition. ATLAS delivers in successive functional batches rather than on a monolithic plan: each batch is defined with you at scoping, delivered with validated parity, then the next one starts. The variable that weighs most is not volume — it is the legacy state (obsolete third-party components, native Windows dependencies, accumulated debt) and the target interface choice (web redesign = additional UX effort). A 4 to 6 week POC on the client's actual code measures real productivity and prices the full program reliably.
Four combined disciplines. (1) Upstream characterization tests on the Delphi legacy: the suite characterizes behavior before any Java code is touched. (2) Pattern-by-pattern migration with line-by-line traceability — each Pascal→Java transformation is documented and unit-tested. (3) Parallel runs Delphi / Java on client datasets with automated result comparison — target > 99% equivalence on critical paths before cutover. (4) Signed discrepancy registry by the program committee: every identified gap is documented, weighted, arbitrated between Access and the client, and signed as a contractual deliverable. This is what makes the deliverable enforceable: Access does not self-validate. See the full ATLAS methodology.
Three concrete ways to start — from a short diagnosis to a full cell. Our Delphi → Java 21 approach is documented, priced, and applicable from the first meeting, with a 4 to 6 week POC to measure real productivity on your code.