Web architect
Target architecture design SPA + REST API + relational database, bridge between Object Pascal and the web ecosystem
Loading...
Loading...
Migration of Delphi applications to a modern web architecture: TypeScript, React or Angular, REST API. ATLAS methodology.
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 client-server application: VCL forms, third-party components, FireDAC access, Object Pascal code. Rebuild a usable functional analysis.
Set the UI ground truth: screenshots, user journeys, test data. Map third-party components, embedded databases, COM/DCOM integrations.
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.
Port Object Pascal → TypeScript pattern by pattern, rebuild VCL screens as React or Angular web components. Iterative migration per module, signed functional parity audit.
Go-live by functional batches, Delphi ↔ web dual run with pilot users, progressive cutover with training, ops handover.
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 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 or 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.
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.
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.
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.
Target architecture design SPA + REST API + relational database, bridge between Object Pascal and the web ecosystem
TypeScript, React or Angular, API design, Delphi→web migration patterns, traceability
React or Angular, rebuilding VCL screens as web components (AG Grid, Material UI)
REST API, porting Object Pascal business logic, JWT/RBAC authentication
Ergonomic redesign from fat client to SPA, Figma mockups, usability tests
Paradox, Interbase, FireDAC migration to PostgreSQL, data parity audit
End-to-end tests (Playwright, Cypress), legacy/target comparison, ATLAS audit validation
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 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, set at scoping based on scope.
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.
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.