Modernization path

Transform a Delphi client-server application into a TypeScript web application.

Q: Is it possible to keep the desktop look even when migrating to web?

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).

Q: React or Angular for a Delphi migration?

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.

Q: How to handle Delphi authentication and roles in web?

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.

Q: Can we migrate by module to reduce risk?

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, set at scoping based on scope.

Q: How much does a Delphi to TypeScript migration cost?

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.

Q: How to handle integration with remaining Delphi applications in the enterprise?

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.

Migration of Delphi applications to a modern web architecture: TypeScript, React or Angular, REST API. ATLAS methodology.

Key figures

30 years

Delphi/Object Pascal in production since 1995

4/10

relative difficulty of a Delphi migration, versus 7/10 for COBOL

By batches

incremental delivery, duration set at scoping

ATLAS methodology applied

From scoping to deployment, five structured phases.

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.

01Phase 1
Scoping
ATLAS steps
E1 Intake · E2 Discovery · E2b Functional spec
Understand the Delphi client-server application: VCL forms, third-party components, FireDAC access, Object Pascal code. Rebuild a usable functional analysis.
Phase deliverable
Screen inventory + functional spec + pricing
02Phase 2
Capture & dependencies
ATLAS steps
E2e Capture · E3 Dependency mapping
Set the UI ground truth: screenshots, user journeys, test data. Map third-party components, embedded databases, COM/DCOM integrations.
Phase deliverable
Reference UI bench + dependency map
03Phase 3
Target architecture
ATLAS steps
E4 Target architecture · E4b Pre-migration tests
Design the target web architecture: React or Angular SPA, REST API with OpenAPI contract, PostgreSQL database. Frame the UX redesign and prepare end-to-end tests.
Phase deliverable
Signed target architecture + mockups + E2E test suite
04Phase 4
Migration & parity
ATLAS steps
E5 Migration · E6 Parity validation
Port Object Pascal → TypeScript pattern by pattern, rebuild VCL screens as React or Angular web components. Iterative migration per module, signed functional parity audit.
Phase deliverable
Web application + parity audit per module
05Phase 5
Deployment & handover
ATLAS steps
E7 Delivery
Go-live by functional batches, Delphi ↔ web dual run with pilot users, progressive cutover with training, ops handover.
Phase deliverable
Application in production + autonomous client team

See the full ATLAS methodology →

At the core of the ATLAS method

AI to understand Delphi, not to translate it.

Moving from a Delphi thick client to a web application is not a language translation but a change of execution model. A converter reproduces synchronous, locally stateful, screen-coupled logic inside an asynchronous, stateless environment. Symptoms only appear under load. 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 source code, from several angles. Here, what we read first: application state carried by VCL forms, to redistribute between client and server, and long-running operations to rethink as asynchronous calls. AI comes in as a comprehension accelerator, to decipher years 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 and drives the migration pattern by pattern, under parity audit.

This understanding still requires humans who know the source technologies. That's our edge: where Europe and North America face a retirement wave on these skills, Tunisia retains experienced Delphi developers, paired with TypeScript architects. Together they ensure continuity between the original business intent and the target system.

Who is concerned

Business context and modernization stakes.

Why move from desktop Delphi to web TypeScript

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.

Sectors concerned

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.

The TypeScript value proposition

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.

Source platform

Delphi (client-server, VCL)

Delphi↗

Target technology

TypeScript, React or Angular, Node.js, PostgreSQL

TypeScript↗PostgreSQL↗Node.js↗Angular↗React↗

Technology alternatives

Compare target trajectories.

TypeScript + React + Node.js + PostgreSQL

Default choice for a maintainable modern web application. React largely dominates the market and has the richest component ecosystem.

TypeScript + Angular + NestJS + PostgreSQL

Preference for an end-to-end structured framework, internal teams already oriented Angular or .NET. Angular is closer to the Delphi philosophy (complete framework).

TypeScript + Vue.js + Hono + PostgreSQL

Gentler learning curve, junior team, desire for a lighter framework. Suited to medium-sized applications.

.NET Core with Blazor

Microsoft ecosystem preserved, Delphi-.NET teams in transition. See Delphi to .NET Core.

Scoping reference

Typical duration and team for this path.

A Delphi to TypeScript migration is planned as a sequence of functional batches, with the cadence set at scoping based 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, front-end developers (React or Angular), 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. Composition and headcount are not fixed upfront: they are determined after the POC and scoping, once the real work has been measured.

Challenges

Transforming a client-server interface into a web SPA application without functional loss.
Migrating Pascal business logic to TypeScript.
Rebuilding interactive workflows with React or Angular patterns.

ATLAS approach

Existing-system capture and interface mapping.
Rebuilding the target architecture: front SPA, REST API, relational database.
Iterative migration with functional parity audit.

Expected outcomes

Modern, responsive, cloud-deployable web application.
Documented and tested REST API.

Identified pitfalls and ATLAS response

What we learned on this migration path.

Pitfall 01

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.

ATLAS response

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).

Pitfall 02

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.

ATLAS response

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.

Pitfall 03

Ignoring embedded Delphi databases (Paradox, dBase, Interbase, SQLite). PostgreSQL conversions have subtleties (encoding, date types, BLOBs, locking).

ATLAS response

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.

Pitfall 04

Forgetting third-party Delphi components (DevExpress, TMS, Woll2Woll) and their non-existent web equivalents. Some Delphi components have no direct web equivalent.

ATLAS response

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.

Pitfall 05

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.

ATLAS response

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.

Related expertise

Legacy to Cloud

See modules, services, and use cases.

Proprietary methodology

ATLAS methodology

10 steps, 9 principles, proven parity.

Cell composition

A specialized cell for this modernization path.

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.

Duration

Set at scoping based on the number of screens and interaction complexity

Volume

Determined after the POC and scoping

Profiles

Web architect

Target architecture design SPA + REST API + relational database, bridge between Object Pascal and the web ecosystem

TypeScript Tech Lead

TypeScript, React or Angular, API design, Delphi→web migration patterns, traceability

Front-end developers

React or Angular, rebuilding VCL screens as web components (AG Grid, Material UI)

Node.js back-end developers

REST API, porting Object Pascal business logic, JWT/RBAC authentication

UX & UI designer

Ergonomic redesign from fat client to SPA, Figma mockups, usability tests

Embedded DB → PostgreSQL DBA

Paradox, Interbase, FireDAC migration to PostgreSQL, data parity audit

QA & functional parity

End-to-end tests (Playwright, Cypress), legacy/target comparison, ATLAS audit validation

Access field experience

This path in real conditions.

Public transport — North America

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.

Audited functional parity · 3,000 requests/year

Read the full case →

Access POC — software engineering

Raptor Delphi POC 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.

difficulty 4/10 vs 7/10 COBOL

Frequently asked questions

What decision-makers ask about this path.

Is it possible to keep the desktop look even when migrating to web?+

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 or Angular for a Delphi migration?+

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.

How to handle Delphi authentication and roles in web?+

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.

Can we migrate by module to reduce risk?+

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, set at scoping based on scope.

How much does a Delphi to TypeScript migration cost?+

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.

How to handle integration with remaining Delphi applications in the enterprise?+

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.

Transforming a Delphi application into a web app?

Three concrete ways to start — from a free diagnosis to a full cell. Our Delphi → TypeScript approach rebuilds a modern web SPA with no functional loss.

Delphi audit (3-4 weeks) →Legacy to Cloud expertise →Build-Operate-Transfer model →

Case studies