Delphi to web migration: modernize, convert or rewrite your business application

A Delphi application should move to the web when it starts holding the business back: remote access patched together with Remote Desktop, Windows machines frozen just to keep it running, components nobody updates any more, or a single developer who understands the code. You have four real options: modernize and stay on Delphi, keep Delphi on the server and add a web front end, convert the code to C# with a tool, or rebuild on open web technologies. The right one depends less on the language than on the state of your application: its version, its data layer and its business rules.

This guide is written for the executive or IT manager who has to make the call, not for the developer who will do the work. Most search results on this topic come from vendors of conversion tools, who have a product to sell. So do we, a custom rebuild, which is exactly why we spell out when a rebuild is not worth it.

Delphi is not dead, and that matters

Unlike Visual Basic 6, Delphi is still an actively developed product. Embarcadero's Delphi product page announced RAD Studio 13.2 "Florence" as available (checked on 7 November 2026). Object Pascal still compiles native Windows applications, and the vendor offers options for mobile, Linux and REST APIs.

That reframes the question. A system written in Delphi 7 twenty years ago and one kept up to date in a recent release are very different animals. The old one usually carries:

• the BDE (Borland Database Engine), the legacy data access layer, with Paradox or dBase tables on a file share;
• third-party components bought at the time, from vendors that have vanished or no longer ship compatible versions;
• non-Unicode strings, which break as soon as data includes other alphabets or travels through web services;
• a 32-bit build and old DLLs;
• remote access through Remote Desktop or Citrix, because nothing else was available.

A healthy, recent Delphi codebase can sometimes stay on Delphi and open up to the web in other ways.

Signs that a migration is justified

• People need the software away from the office: sales reps, field technicians, branch offices, remote staff. Remote Desktop works, but it costs licenses, security effort and user comfort.
• You need to open the system to the outside: a customer portal, order tracking, automated exchanges with suppliers or an ERP.
• One person holds all the knowledge, often the original author, close to retirement or stretched thin. Delphi developers exist, but the pool is far smaller than for web stacks or C#.
• Machines cannot be upgraded because of the application. Microsoft ended Windows 10 support on 14 October 2025, and a machine stuck on an old system inherits its vulnerabilities.
• Every change feels dangerous: nobody dares touch the code and requests pile up. That is the textbook symptom of technical debt.

When you should not migrate

A migration ties up your team and costs real money. It is hard to justify if your application:

• runs on a recent Delphi version, without the BDE;
• is maintained by a capable, available developer, with the source code under your control;
• serves office-based users on up-to-date machines;
• changes rarely and does not need to connect to customers or partners.

In that case, invest in resilience instead: tested backups, source code under version control, documented core rules, and a second developer who knows the project. Keep the migration for the day a real need appears.

The four paths and off-the-shelf software, compared

Modernize and stay on Delphi

The lowest short-term risk: move to a current release, replace the BDE with FireDAC, convert strings to Unicode, compile for 64-bit and replace dead components. It makes sense when the application stays a desktop tool and you have Delphi developers. It does nothing for mobility or for your dependence on a narrow talent pool.

Keep Delphi on the server and add a web front end

You pull the business logic into a server that exposes an API, then build web screens on top. Embarcadero sells RAD Server for this, and third-party frameworks even let you write the web UI in Object Pascal. It is a useful intermediate step when the business logic is clean and separated from the forms. When the logic is buried in button click handlers, which is common in older applications, extracting it costs nearly as much as a rewrite.

Convert to C# and .NET with a tool

This is the "migrate Delphi to C#" route. Several vendors sell converters that read .pas and .dfm files and emit C#. The automation rates they advertise are sales figures, to be tested on your own code. Calculation logic, classes and procedures convert well. VCL forms (an editable Windows grid is not a web page), printed reports, third-party components and DLL calls convert poorly. The output is usually a .NET desktop application unless the interface is rebuilt.

Rebuild as a web application

A browser-based application, a database such as PostgreSQL, and documented APIs. This path opens the most doors: access from a laptop, tablet or phone, customer portals, integrations and free choice of hosting. The Delphi code is not thrown away. It becomes the specification, where you read the pricing rules, validation checks and edge cases built up over two decades. For choosing the stack, see how to choose a tech stack for business software.

The data layer is the real project

Delphi applications went through several generations of data access, and yours may mix them:

• BDE with Paradox or dBase: files on a shared drive. Embarcadero's documentation describes it as deprecated, with no Unicode or 64-bit support. These files are also prone to corruption after network drops.
• InterBase or Firebird: proper server databases, fairly easy to move, but often heavy with stored procedures and triggers.
• SQL Server or Oracle through ADO, dbExpress or FireDAC: the database can sometimes stay in place during the transition, which makes running old and new side by side much simpler.

Three traps show up in almost every data migration:

• logic hidden in the database: stored procedures and triggers that compute stock levels or balances, which nobody thinks to list;
• logic hidden in the forms: checks and calculations written in event handlers, invisible from the database;
• dirty data: duplicates, dates stored as text, orphaned records, changing character encodings.

The full method, with trial migrations and business sign-off, is in our guide to legacy data migration.

What migration quotes often leave out

• Printed reports: QuickReport, FastReport, Rave Reports. An older application often has dozens, each to be rebuilt.
• Hardware: label printers, barcode scanners, scales, serial ports. Each needs a browser-based solution or a small local agent.
• File exchanges: imports and exports with accounting, banks or carriers, often in home-made formats.
• Offline use: a warehouse or workshop with poor coverage needs a degraded mode.
• Training and cutover: people who have used the same keyboard shortcuts for twenty years do not switch tools overnight.
• Source code and rights: make sure you hold the complete source, third-party components included, and the right to use it. See who owns custom software source code; rights are defined case by case in the contract.

Migrate in stages, not in one go

Replacing a core Delphi system in one weekend bets everything on a single date. The safer method builds the new application next to the old one:

1. Inventory: which forms and reports are actually used, by whom, how often. Some are dead.
2. Rule extraction: read the code and interview key users to write down what the software really does.
3. A first module chosen for its value: often what is most missing today, such as mobile access or a customer portal.
4. A prototype validated by users before any development.
5. Coexistence: the web module reads and writes the same database, or syncs with it, while Delphi handles everything else.
6. Module-by-module cutover with a rollback plan, until the Delphi application is retired.

This is the strangler approach described in our guide to legacy application modernization. It applies to other tools of the same era too: see VB6 migration and WinDev to web migration.

What a Delphi migration costs

The source language has little effect on the price. What drives it: the number of forms and reports in real use, the complexity of business rules, the state of the data, and the number of integrations and devices. What weighs most in a Delphi migration is logic scattered across forms and the database, and missing documentation. Our cost drivers and ranges are in software modernization cost.

How you pay matters as much as how much. A fixed price per module, a SaaS edition if your industry shares the same needs, or a subscription that avoids paying for development upfront: each model shares the risk differently.

Common mistakes

• Signing for an automatic conversion without a trial on your real code.
• Cloning every screen one to one instead of rethinking the workflow. A web page is not a Windows form, and twenty years of habits often hide needless detours.
• Forgetting stored procedures, then finding in acceptance testing that balances no longer add up.
• Switching everyone over on the same day, with no way back.
• Letting the original developer leave before capturing what they know.

A checklist for decision-makers

• Which Delphi version opens the source code today, and do you have it?
• Does the application still use the BDE, Paradox or dBase?
• Which third-party components are essential, and are they still maintained?
• Which forms and reports are used every week?
• What need justifies the migration: mobility, openness, key-person risk, security?
• Who on your team knows the business rules and can sign off the new system?

Where to start

Gather screenshots of the most used screens, the list of printed reports and, if possible, a copy of the database. That is enough for a first conversation to tell which path fits, including when the honest answer is to stay on Delphi.

At LPR Studio, that conversation leads to a free visual prototype of the first web module, presented on a video call within 5 business days, so your team sees its future screen before anyone commits. The approach is explained in see your software before you pay for it.