Modernization path

Port a Delphi application to .NET Core 8 with UI parity.

Migration of Delphi Object Pascal applications to .NET Core 8 and C#, rebuilding native interfaces, porting embedded databases. ATLAS methodology.

Key figures

30 years

Delphi/Object Pascal in production since 1995

5:1

rewrite ratio from Delphi VCL to .NET Core

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 application: VCL forms, third-party components, BDE/FireDAC, Object Pascal code. Rebuild a usable functional analysis.
Phase deliverable
Form 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, DLL/COM dependencies.
Phase deliverable
Reference UI bench + dependency map
03Phase 3
Target architecture
ATLAS steps
E4 Target architecture · E4b Pre-migration tests
Design the target .NET Core architecture: WinForms (visual parity), Blazor (modern web), or WPF (rich desktop). Target database choice. UI characterization tests.
Phase deliverable
Signed target architecture + UI test suite
04Phase 4
Migration & parity
ATLAS steps
E5 Migration · E6 Parity validation
Port Object Pascal → C# pattern by pattern, rebuild VCL visual components in WinForms or Blazor. Incremental migration per form, signed UI parity audit.
Phase deliverable
.NET code + UI parity audit per form
05Phase 5
Deployment & handover
ATLAS steps
E7 Delivery
Go-live by functional batches, Delphi ↔ .NET coexistence whose duration is set at scoping based on risk profile, progressive user 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.

The apparent closeness between Object Pascal and C# makes automatic conversion tempting and misleading. Syntax translates well; the VCL component model, published properties, and third-party components (grids, editors, reporting) have no direct equivalent and get replaced by approximations. 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: the real split between VCL interface and business logic, and third-party component dependencies that determine porting feasibility. 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 .NET architects. Together they ensure continuity between the original business intent and the target system.

Who is concerned

Business context and modernization stakes.

Where Delphi is still found

Delphi applications are massively present in engineering trades, design offices, expertise firms, sectoral ERPs, logistics, manufacturing, and certain specialized administration functions. Delphi dominated Windows business application development between 1995 and 2010, and many of these applications still run today without modernization — working perfectly but locking the IT roadmap.

The signals that trigger migration

Typical reasons to migrate a Delphi: the vendor has stopped delivering major updates on the version in use, third-party VCL components are no longer maintained, the application only works as a Windows fat client while users demand web or mobile, or the code has become hard to evolve because of unavailable Delphi expertise. Our ATLAS methodology frames this transition with proven functional parity on each migrated screen.

Why .NET Core as target

.NET Core as a target makes sense in three situations. When the company is already in the Microsoft ecosystem (Azure, Dynamics 365, Power Platform, SQL Server dominant). When the application must continue to exist as a Windows desktop for business reasons (offline operation, hardware integration, native performance). When in-house teams know C# better than Java — Pascal syntax translates almost word-for-word to C#. If your target is rather cloud-native web, look at Delphi to TypeScript. If your target IT is dominated by Java (Spring, JEE, existing Java integrations), look at Delphi to Java instead.

Source platform

Delphi (Object Pascal, VCL, FireDAC)

Object Pascal↗Delphi↗

Target technology

.NET Core 8, C#, WinForms or Avalonia, SQL Server

.NET Core 8↗SQL Server↗Avalonia↗C#↗

Technology alternatives

Compare target trajectories.

.NET Core 8 + C# + WinForms or Avalonia

Keep a native desktop application with Windows-Linux-macOS portability if Avalonia is chosen. Suited to trades that need a high-performance fat client or offline operation.

.NET Core 8 + Blazor Server/WebAssembly

Move from a fat client to a web application while staying in the .NET ecosystem. Good compromise when business users want browser access without reinstallation.

TypeScript + React + Node.js

Fully modernize toward a cloud-native web architecture. See the Delphi to TypeScript path. Suited when the company is migrating its IT to web standards.

Java + Spring Boot + PostgreSQL

Java target ecosystem already dominant in the IT. Requires a complete rewrite, since Pascal and Java syntax are less close than Pascal and C#. See the dedicated Delphi to Java journey.

Scoping reference

Typical duration and team for this path.

A Delphi to .NET Core migration is planned as a sequence of functional batches, with the cadence set at scoping based on screen volume and integration complexity. The typical team combines a Delphi-.NET architect able to bridge the two ecosystems, a .NET tech lead, developers proficient in C# and ideally with a Pascal background, a UI-specialized QA, and a UX designer for ergonomic redesign if desired. Composition and headcount are not fixed upfront: they are determined after the POC and scoping, once the real work has been measured.

Challenges

Rebuilding native Windows Delphi interfaces in .NET without degrading ergonomics.
Migrating proprietary third-party components (DevExpress, TMS) to their .NET equivalents.
Porting embedded databases (Paradox, Interbase) to SQL Server or PostgreSQL.

ATLAS approach

Existing-system capture: screens, workflows, local databases, integrations.
Rebuilding the target architecture with choice between .NET + WinForms or Avalonia for cross-platform.
Pattern-by-pattern migration with UI parity audit.

Expected outcomes

Maintainable, testable, deployable .NET Core 8 application.
UI parity audited on a screen reference set.
Signed discrepancy registry.

Identified pitfalls and ATLAS response

What we learned on this migration path.

Pitfall 01

Considering Delphi migration as simpler than COBOL and underestimating the pitfalls. Pascal syntax is close to C#, but VCL components, manual memory management, and third-party DLLs hide surprises.

ATLAS response

Exhaustive inventory of third-party components from the Intake phase. Each non-standard VCL component is qualified: .NET equivalent available, open source equivalent, or rewrite required. Delphi applications generally have ten to thirty percent of their code in third-party components — that's where delays hide.

Pitfall 02

Migrating the user interface pixel by pixel without seizing the opportunity to modernize ergonomics. The result is a .NET application that looks like 2005 Delphi.

ATLAS response

Explicit separation between technical migration (functional parity) and ergonomic redesign (distinct phase). On our experience redesigning Delphi structural analysis applications to .NET Core, the ergonomic phase was framed after the functional cutover to avoid mixing the two streams.

Pitfall 03

Ignoring Pascal specifics — string handling (AnsiString vs UnicodeString), managed vs unmanaged types, record vs class, property vs field.

ATLAS response

Systematic mapping of Pascal types to .NET documented in the discrepancy registry. AnsiStrings become .NET strings with explicit encoding. Pascal records become C# structs to preserve value semantics. Each case is tracked.

Pitfall 04

Forgetting embedded databases (Paradox, dBase, Interbase) and their specifics (bidirectional cursors, BLOBs, optimistic locking).

ATLAS response

Progressive porting to SQL Server or PostgreSQL with a compatibility layer for cases where semantics are too close to the original engine. Delphi BLOBs are migrated to varbinary(max) or bytea depending on target engine, with parity tests on size and integrity.

Pitfall 05

Declaring UI parity based solely on static screenshots. Complete workflows under real conditions always reserve surprises.

ATLAS response

Principle E7 — browser and workflow validation mandatory before delivery. Each business workflow is replayed under real conditions, with real datasets, and compared to the Delphi application in parallel. See the full 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 application size and UI complexity

Volume

Determined after the POC and scoping

Profiles

Delphi ↔ .NET architect

Bridge between Object Pascal/VCL and the .NET Core / WinForms or Blazor ecosystem

.NET Tech Lead

.NET Core 8, C#, Delphi-to-C# pattern refactoring, third-party component handling

Developers

Ideally with Delphi or C# background to port code and visual components

Embedded DB → SQL Server/PostgreSQL DBA

Paradox, BDE, FireDAC migration to SQL Server, data parity audit

UX & UI

Delphi VCL screen redesign to WinForms or Blazor, audited ergonomic parity

QA & functional parity

UI test bench, 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 for oversized vehicles. Migration to .NET Core 8 + PostgreSQL with audited functional parity. More than three thousand structural expertise requests processed each year.

.NET Core 8 · audited functional parity · 3,000 requests/year

Read the full case →

Access POC — software engineering

Raptor Delphi POC converted to validate the relative difficulty compared to a COBOL migration. Difficulty estimated at four out of ten for Delphi versus seven out of ten for COBOL.

difficulty 4/10 vs 7/10 COBOL

Frequently asked questions

What decision-makers ask about this path.

Is Delphi still supported by Embarcadero?+

Yes, Embarcadero continues to deliver major Delphi versions (latest version 12 Athens in 2024) with an active ecosystem. Migration is therefore not an absolute technical necessity. It becomes relevant when the application is hard to evolve due to lack of expertise, when the third-party components used are no longer maintained, or when the company standardizes its IT on another stack. The timetable is rarely dictated by the vendor.

Can we migrate progressively or must everything be redone at once?+

Migration can be progressive if the application is modular. The ATLAS methodology applies the strangler fig pattern — we migrate one module at a time, maintaining integration between existing Delphi code and new .NET code via a service layer. This approach is particularly suited to Delphi applications structured in business modules. For monolithic applications with very tightly coupled code, a single-shot redesign is sometimes more realistic.

Will end users notice the migration?+

It depends on the target choice. If you migrate to .NET WinForms with pixel-by-pixel UI parity, users trained on the old application find their bearings immediately. If you move to Blazor or a web application, an indispensable accompaniment phase is needed. We recommend clear upstream communication on the deliberate changes (added features, modernized ergonomics) and strict parity on preserved elements.

How are Delphi printouts and reports (QuickReport, FastReport) handled?+

QuickReport or FastReport reports are migrated to .NET components like DevExpress Reports, FastReport .NET, Stimulsoft, or to web solutions like Crystal Reports or on-the-fly PDF generators. The choice depends on report volume, layout complexity, and consumption mode (paper printing, PDF, Excel export). For an estate of several dozen reports, we set up a migration template applied report by report with visual validation.

What to do with third-party VCL components whose licenses have expired or whose vendor has disappeared?+

Frequent case on old Delphi applications. Three options: replace with an equivalent .NET component (best option if available), rewrite the component in .NET with functional parity (moderate to significant effort), or externalize the functionality in a separate service called by the application. The choice is made case by case based on component criticality, engineering time required, and new licenses considered.

How long does it take to train a Delphi team in .NET Core?+

An experienced Delphi developer masters the essentials of C# and .NET Core in two to four weeks, thanks to Pascal-C# syntactic proximity. Best practice is to build the migration team by mixing two to three senior .NET developers with two to three Delphi developers progressively trained on the target stack. This mix allows Delphi developers to carry the business knowledge and .NET developers to bring target framework best practices.

Is Delphi outdated?+

Delphi is not technically outdated — Embarcadero ships RAD Studio updates regularly and Delphi 12 was released in 2023 with modern compiler improvements. The real issue is ecosystem and talent: the developer pool is shrinking, third-party component vendors (DevExpress, TMS) are slowly de-prioritizing Delphi, and integration with cloud, AI, and modern web stacks requires increasing workarounds. For applications that still run profitably and don't need significant evolution, keeping Delphi is rational. For applications that need API-first architecture, mobile clients, or AI integration, modernization to .NET Core, TypeScript, or Java is the path. The ATLAS methodology handles this with proven functional parity. See the Delphi to .NET Core journey.

Modernizing a Delphi application?

Three concrete ways to start — from a free diagnosis to a full cell. Our Delphi → .NET Core 8 approach preserves both functional and screen ergonomic parity.

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

Case studies