Delphi ↔ .NET architect
1Bridge between Object Pascal/VCL and the .NET Core / WinForms or Blazor ecosystem
Loading...
Loading...
Migration of Delphi Object Pascal applications to .NET Core 8, rebuilding native interfaces, porting embedded databases. 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 application: VCL forms, third-party components, BDE/FireDAC, Object Pascal code. Rebuild a usable functional analysis.
Set the UI ground truth: screenshots, user journeys, test data. Map third-party components, embedded databases, DLL/COM dependencies.
Design the target .NET Core architecture: WinForms (visual parity), Blazor (modern web), or WPF (rich desktop). Target database choice. UI characterization tests.
Port Object Pascal → C# pattern by pattern, rebuild VCL visual components in WinForms or Blazor. Incremental migration per form, signed UI parity audit.
Go-live by functional batches, Delphi ↔ .NET coexistence for 3 to 12 months, progressive user cutover with training, ops handover.
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.
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.
.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.
.NET Core 8, C#, WinForms ou Avalonia, SQL Server
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.
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.
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 target ecosystem already dominant in the IT. Requires a complete rewrite, since Pascal and Java syntax are less close than Pascal and C#.
A Delphi to .NET Core migration is typically planned over six to eighteen months depending on screen volume and integration complexity. The typical team combines a Delphi-.NET architect able to bridge the two ecosystems, a .NET tech lead, three to six developers proficient in C# and ideally with a Pascal background, a UI-specialized QA, and a UX designer for ergonomic redesign if desired. Applications under fifty thousand lines of Delphi migrate in six to nine months with a cell of four to five people. Applications of one hundred thousand to three hundred thousand lines mobilize ten to fifteen people over twelve to eighteen months.
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.
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.
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.
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.
Ignoring Pascal specifics — string handling (AnsiString vs UnicodeString), managed vs unmanaged types, record vs class, property vs field.
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.
Forgetting embedded databases (Paradox, dBase, Interbase) and their specifics (bidirectional cursors, BLOBs, optimistic locking).
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.
Declaring UI parity based solely on static screenshots. Complete workflows under real conditions always reserve surprises.
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.
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.
Bridge between Object Pascal/VCL and the .NET Core / WinForms or Blazor ecosystem
.NET Core 8, C#, Delphi-to-C# pattern refactoring, third-party component handling
Ideally with Delphi or C# background to port code and visual components
Paradox, BDE, FireDAC migration to SQL Server, data parity audit
Delphi VCL screen redesign to WinForms or Blazor, audited ergonomic parity
UI test bench, legacy/target comparison, ATLAS audit validation
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.
Raptor Delphi POC: one thousand three hundred thirty-three lines of Delphi converted to .NET 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.
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.
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.
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.
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.
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.
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.
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.