At a glance
Legacy sources: Delphi 1–7 · Delphi 2005–2010 · XE–XE8 · RAD Studio 10.x–12 · VCL · FireMonkey · BDE · dbExpress · FireDAC · Object Pascal
Modern targets: Delphi 13 · C# .NET 10 · Go · Rust · Win64 · web · iOS/Android
Typical timeline: 4 weeks to 8 months depending on scope
Project range: $10,000–$200,000
U.S. delivery: 100% U.S. citizen workforce, U.S.-soil delivery
What to know before you modernize
Why Delphi applications are still running
Delphi shipped in 1995 and, for the next decade, was one of the fastest ways to build a Windows application with a database behind it. The compiler produced a single native executable, the VCL wrapped the Windows API in components that were pleasant to work with, and the data-access layer connected to almost anything. Applications built that way run for a very long time because nothing in them expires on its own: no runtime to license, no framework to patch, no interpreter to upgrade. That durability is why so many are still in production, and it is also why they are now hard to change. Developers retire, component vendors change hands or close, and the operating system underneath moves from 32-bit to 64-bit. The code still compiles. The platform around it is what needs attention.
Which Delphi you have, and what it implies
The version number tells us most of what the first phase of work looks like. Delphi 1 is 16-bit and needs a full port before anything else. Delphi 2 through 7 are Win32 VCL applications from the BDE era, and Delphi 7 is the release that stayed in service the longest. Delphi 8 and the 2005–2007 releases added a .NET detour that was later abandoned, so code from that period can carry dead branches. Delphi 2009 switched the string type to Unicode, which is the largest single source break on the upgrade path. XE2 brought the 64-bit Windows compiler and FireMonkey, with FireDAC as the bundled data layer from XE3 onward. RAD Studio 10.x, 11 Alexandria, and 12 Athens are modern toolchains, and 13 Florence is the current target for an upgrade in place.
Three paths: upgrade in place, bridge, or migrate
Upgrade in place keeps the application in Delphi and moves it to Delphi 13: Unicode fixes, component replacements, a 64-bit build, and a supported toolchain, with the code and the team’s knowledge intact. It is the shortest path when the application is sound and Delphi skills are available to maintain it. Bridge, the strangler-fig pattern, puts a service boundary around the existing application and moves capabilities out one at a time while the original keeps running; the Delphi executable shrinks over months rather than being replaced in one cutover. Migrate rewrites the application in C# .NET, Go, or Rust around the business domain, with CQRS and event sourcing where the domain warrants them, and is the right choice when the goal is cross-platform, cloud, or a team that does not write Object Pascal. The assessment recommends one path in writing.
VCL, FireMonkey, and third-party components
Every Delphi application depends on components, and the component inventory decides how hard an upgrade is. The VCL itself carries forward cleanly, and FireMonkey applications move onto the current FireMonkey framework. Third-party components fall into three groups. Still-sold or still-shipped libraries, among them DevExpress, TMS, TeeChart, FastReport, ReportBuilder, and the Raize/Konopka controls, have current releases for Delphi 13, so the work is a license renewal and an API pass. Libraries with source but no vendor, including abandoned commercial packages and the open-source JEDI and Indy families, can be carried forward and patched for Unicode and 64-bit. Compiled-only components with no source and no vendor are the hard case: each one is replaced, wrapped behind an interface, or rewritten, and that decision is made per component before the schedule is set.
Data layers: BDE, Paradox, dBASE, dbExpress, ADO, IBX, FireDAC
The data layer is the part of a Delphi application most likely to block an upgrade on its own. The Borland Database Engine was deprecated in 2001 and does not ship with current Delphi; applications on BDE, and especially on Paradox or dBASE tables, need a new data layer and a real database before anything else moves. dbExpress still ships but is no longer the recommended layer, ADO works on Windows only, and IBX is tied to InterBase. FireDAC is the supported path: one component set that talks to SQL Server, PostgreSQL, InterBase, Firebird, and most other databases from the same code. Moving to it means replacing dataset components, rewriting queries that relied on local-table semantics, and migrating the data with a repeatable script. That is its own phase, with the schema documented and the migration rehearsed before cutover.
32-bit-only builds, Windows 11, and 64-bit
A 32-bit Delphi executable still runs on Windows 11 through the WOW64 compatibility layer, and that is what keeps many applications alive past the end of their toolchain. The limits are real: a capped address space, 32-bit drivers and COM servers that no longer install, and Office and database client libraries that have gone 64-bit on the same machines. Delphi 7 through 2010 have no 64-bit compiler at all; the XE series and everything after it do. Getting to a 64-bit build is mostly a question of pointer-size assumptions, inline assembler, packed record layouts, and third-party components without a 64-bit version. We inventory those up front, because they set the order of work: components and data layer first, then the compiler switch, then the platform change.
Delphi in operational and hardware-facing software
Delphi is also common in long-running operational software: laboratory, instrument, logistics, and plant applications that talk to hardware over serial or vendor protocols. Those need a modernization plan that respects uptime windows and the hardware boundary, which is usually a hybrid design: the hardware-facing piece stays where it is, and everything around it moves.
Start with an assessment
For a Delphi codebase the assessment inventories the things that decide the path: units and forms, compiler version and directives, the component list with each library’s license and source status, data-access usage by component family, 32-bit-only dependencies, COM and ActiveX interfaces in both directions, reporting engines, the database schema, the deployment shape, and whatever automated test coverage exists. Everything is read from source, project files, and configuration; nothing is run and nothing in production is touched. The result is a written recommendation for one of the three paths, with the component replacement plan and the data-layer path attached. The fee is quoted after the free 1-hour consultation and creditable toward a subsequent modernization project.
Deliverables
- Written upgrade, bridge, or migrate recommendation with the reasons
- In-place upgrade to Delphi 13: Unicode, 64-bit, supported toolchain
- Component replacement plan: keep, upgrade, wrap, or replace, per library
- Data-layer migration off BDE and Paradox to FireDAC on SQL Server, PostgreSQL, InterBase, or Firebird
- Cross-platform target in C# .NET 10, Go, or Rust around the domain (CQRS, event sourcing)
- Mobile and macOS via FireMonkey or native targets
Common questions
Which Delphi versions can you modernize?
All of them: Delphi 1–7, Delphi 2005–2010, XE through XE8, and RAD Studio 10.x through 12, VCL or FireMonkey, on BDE, dbExpress, or FireDAC. Each is taken down one of the three paths: upgrade in place to Delphi 13, bridge behind a service boundary, or migrate to C# .NET, Go, or Rust.
Does Delphi 7 still run on Windows 11?
Yes. A 32-bit Delphi 7 executable runs on 64-bit Windows 11 through the WOW64 compatibility layer. What stops working is the environment around it: the BDE installation, 32-bit database and printer drivers, and COM components that no longer register. Running is not the same as supported, and that gap is what the upgrade closes.
Should we upgrade to Delphi 13 or migrate to .NET?
Upgrade when the application is sound, the team can maintain Object Pascal, and the goal is a supported Windows toolchain. Migrate when the goal is cross-platform, cloud, or a team that works in C#, Go, or Rust, or when the component and data-layer work is large enough that a rewrite costs about the same as fixing it. The assessment answers this in writing for your codebase rather than in general.
Can you modernize a Delphi application without a full rewrite?
Yes. An in-place upgrade to Delphi 13 keeps the codebase and replaces only what broke: Unicode strings, the data layer, and unsupported components. The bridge path goes further without a rewrite: a service boundary around the existing application lets new capabilities be built outside it while the Delphi executable keeps running and shrinks over time.
What happens to our BDE, Paradox, or InterBase data?
It moves to a supported database through FireDAC. Paradox and dBASE tables are migrated to SQL Server, PostgreSQL, InterBase, or Firebird with a repeatable script and a parallel run before cutover. InterBase databases can stay in place, with IBX or BDE replaced by FireDAC in the application. Nothing is migrated until the schema is documented and the migration has been rehearsed.
We depend on DevExpress or TMS components. Is that a problem?
No. Both vendors ship current releases for Delphi 13, so the upgrade is a license renewal and an API pass over the forms that use them. The harder cases are compiled-only components from vendors that no longer exist; each is replaced, wrapped behind an interface, or rewritten, and the component plan lists which is which before the schedule is set.
How long does a Delphi modernization take, and what does it cost?
The bands on this page apply: 4 weeks to 8 months depending on scope, and $10,000–$200,000. An in-place upgrade sits at the low end and a full migration at the high end. The price and schedule are fixed after the Legacy Software Assessment, whose fee is quoted after the free 1-hour consultation and creditable toward a subsequent modernization project.
Can you modernize a Delphi application that runs a production process without downtime?
Usually, with a phased plan, a parallel run, and cutover windows you choose.
Not sure where to start?
Start with a fixed-scope Legacy Software Assessment: a read-only review of your application’s source, database, configuration, logs, and architecture, ending in findings with evidence and a written recommendation. Quoted after the free 1-hour consultation; creditable toward a subsequent modernization project.