Port a Delphi application to Java and expose its data to cloud workflows.

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.

Three variables drive the cost of a Delphi to Java migration. The share of business logic buried in VCL events, which must be extracted before any porting. The number of third-party components with no Java equivalent, to be reimplemented one by one. And the target UI choice: separate web frontend or JavaFX rich client. Intake measures all three before quoting. Free initial scoping call, 30 minutes to 2 hours.

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.