Loading...
Migration of Delphi applications to a modern web architecture: TypeScript, React or Angular, REST API. ATLAS methodology.
Delphi client-server applications dominant between 1995 and 2010 have a structural flaw: they require a local Windows installation on every user workstation. This complicates deployment, prevents mobile access, and makes remote work complicated without VPN. Migrating to TypeScript plus React or Angular transforms the application into a web SPA accessible from any browser, without installation, with code maintainable by modern web teams. This is the option chosen when the application must open up to remote users or external partners.
Typical candidates for a Delphi to TypeScript migration: engineering offices and expertise firms wanting to open their tools to external clients, sectoral Delphi ERPs (logistics, transport, industry) seeking to exit the fat client, business applications developed in-house in the 2000s that must modernize their UX, software vendors repackaging their Delphi products as SaaS web. For an internal-only public that accepts Windows, look instead at Delphi to .NET Core.
TypeScript brings three decisive advantages for porting Delphi. Static typing facilitates translation from Object Pascal — Pascal types have direct equivalents in TypeScript. The npm ecosystem offers rich components that replace Delphi VCL and DevExpress (Material UI, Ant Design, AG Grid, Handsontable). Finally, development velocity and cloud operating cost allow rapid amortization of the migration investment. See the ATLAS methodology applied to these migrations.
TypeScript, React ou Angular, Node.js, PostgreSQL
Default choice for a maintainable modern web application. React largely dominates the market and has the richest component ecosystem.
Preference for an end-to-end structured framework, internal teams already oriented Angular or .NET. Angular is closer to the Delphi philosophy (complete framework).
Gentler learning curve, junior team, desire for a lighter framework. Suited to medium-sized applications.
Microsoft ecosystem preserved, Delphi-.NET teams in transition. See [Delphi to .NET Core](/parcours/delphi-to-dotnet-core).
A Delphi to TypeScript migration is planned over **eight to twenty months** depending on the number of screens and interaction complexity. The team combines a **web architect** capable of designing the target architecture (SPA plus API plus database), a **TypeScript tech lead**, two to four **front-end developers** (React or Angular), two to three **Node.js back-end developers**, a **UX designer** for the inevitable ergonomic redesign on a SPA, an end-to-end QA specialist (Playwright, Cypress), a DBA for the embedded database migration. For **fifty to two hundred thousand lines of Delphi**, plan **ten to fifteen months** with a cell of **eight to twelve people**.
Reproducing the Delphi interface pixel by pixel in web. The Delphi fat client has UX patterns that work poorly on web: nested modal windows, dense context menus, fast input dialogs.
Mandatory UX redesign on a SPA. Delphi context menus become side panels or web modals, fast dialogs become inline forms, multiple windows become tabs or views. This UX redesign is framed before the technical migration, with user validation (Figma mockups, usability tests).
Migrating without rethinking the data model. Delphi client-server often uses direct SQL access with FireDAC cursors; a well-designed REST API requires a structured data model.
REST API design upstream (or GraphQL depending on context) with formal OpenAPI definition. Delphi tables are normalized and exposed via typed DTOs. Direct client-server accesses become REST endpoints with JWT authentication, rate limiting, versioning. Non-regression tests on business behaviors.
Ignoring embedded Delphi databases (Paradox, dBase, Interbase, SQLite). PostgreSQL conversions have subtleties (encoding, date types, BLOBs, locking).
Dedicated data migration phase with specialized tools (pgloader, Azure DMS depending on source). BLOBs become PostgreSQL bytea with parity tests on size and integrity. Dates are migrated to TIMESTAMP WITH TIME ZONE with explicit time zone. Optimistic cursors become PostgreSQL RowVersion.
Forgetting third-party Delphi components (DevExpress, TMS, Woll2Woll) and their non-existent web equivalents. Some Delphi components have no direct web equivalent.
Exhaustive inventory of third-party components from Intake. Each component is qualified: React/Angular equivalent available (AG Grid replaces TDBGrid, Material UI replaces VCL), open source equivalent, or rewrite required. Proprietary publishers (DevExpress) often have their React version — license cost to anticipate.
Declaring functional parity without validating complete business workflows under real conditions. Users trained on the Delphi application have precise habits that must be reproduced or explicitly rethought.
Principle E7 — mandatory browser validation with automated end-to-end tests (Playwright) on each critical business workflow. Delphi-web dual run period of four to eight weeks with pilot users. Field feedback integrated iteratively before general cutover. See the ATLAS methodology.
Redesign of a critical Delphi application for structural analysis of bridges, ported to a modern architecture with audited functional parity. More than three thousand expertise requests processed per year.
Raptor Delphi POC: one thousand three hundred thirty-three lines of Delphi evaluated to validate relative difficulty. Delphi is estimated at **4 out of 10** versus **7 out of 10** for COBOL, notably thanks to Pascal-TypeScript/C# syntactic proximity.
Yes, via Electron or Tauri which package a web application in a desktop runtime (Windows, macOS, Linux). The user sees a desktop application, the code is web TypeScript. This approach combines the advantages: modern web code (maintenance, ecosystem) plus desktop experience (installation, shortcuts, system icons). Tauri is preferred today for its lightness vs Electron (smaller applications, faster startup).
React if your priority is velocity and ecosystem (components, libraries, recruitment). Angular if your priority is structure and proximity with the Delphi philosophy (complete framework, strong opinion, native TypeScript from the start). Both are valid, our preference leans slightly toward React for the availability of data-heavy components (AG Grid, Material UI). If your teams already have C#/Angular, stay on Angular.
Delphi roles are migrated to a JWT authentication plus RBAC (Role-Based Access Control) system. Delphi user tables become a target user base, exposed via Auth0, Keycloak, Azure AD, or Cognito depending on context. Delphi permissions (read, write, supervise) become JWT scopes verified on the API side. Parity tests on each role with reference datasets.
Yes. The ATLAS methodology applies the strangler fig pattern for Delphi too: we migrate one module at a time (for example, first user management, then data management, then business workflows), maintaining the Delphi application in production for non-migrated modules. An API gateway allows the two applications to communicate during the transition. This approach spreads risk but lengthens total duration — twelve to twenty-four months for a medium estate.
For a fifty thousand line Delphi application with forty screens in nearshore co-delivery, plan six hundred to nine hundred thousand euros including UX, development, tests, and user support. For one hundred fifty thousand lines, budget one million two hundred thousand to two million euros. Costs include the mandatory UX redesign for a good web experience. See the delivery models for contractual formats.
Remaining Delphi applications often expose services via COM, DCOM, or shared database. In web TypeScript, these integrations are encapsulated via API adapters (Azure Functions, Node.js bridges). For shared databases, ideally avoid direct access by favoring an intermediate API that serves both Delphi and web. For old COM/DCOM, encapsulate them in a server-side .NET or Node.js service that exposes REST endpoints usable from both worlds.
We frame the trajectory, the budget, and the deliverables in a first thirty-minute conversation. A short POC can be proposed before committing to the full program.
Start this path →