• Blog
  • Migration of Delphi to .NET

Migration of Delphi to .NET

When it can be reasonable to migrate from Delphi to .NET

Publish date:
Discover more of what matters to you


First of all, each migration should have its own roadmap and sense. Before migration from one technology to another one we should have a clear understanding of migration reasons, pros and cons, benefits of the technology for migration, migration pitfalls and risks.

This is why, before any migration we suggest performing a 40-80 hour business analysis. It helps us to understand the feasibility of migration from the legacy version of technology to an up-to-date or totally different one. And only after getting a clear understanding that it has real sense not only “because I just want to do it” – after we finding a lot of facts and reasons – we can move further.

Business analysis should give us answers to the following questions:

  • What is a pessimistic and optimistic evaluation of migration (time and cost)?
  • ROI (return of investments) – will we reach our goals? When? How?

The ROI parameter is a very important one. But it is something that developers don’t like too much. ROI should provide us with an answer on when and how a business or company will return money which was spent on migration. Even if you haven’t estimated ROI for your current migration – you have to calculate it.

Check out our article: Why do you need IT business analysis services?

When it can be reasonable to migrate from Delphi to .NET

  • If you want to change your app architecture totally. For instance, to move your app from the desktop philosophy and to have a web application instead (and if Delphi web solutions are not suitable for you);
  • If you cannot buy necessary commercial licenses and you don’t fit the Community license conditions;

When we don’t recommend to migrate from Delphi to .NET

  • When it is just the migration of a desktop VCL or FMX application to .NET WinForms or WPF application with the same functionality without any re-engineering, especially when performance is matter;
  • When it is just the migration from Delphi to Electron (this solution has its own pros and cons);
  • When you just want to migrate your software because you don’t have Delphi developers. To solve this problem you can hire an outsourcing company. You can find a lot of experienced Delphi developers on the market;
  • When you are not ready to go through all bug fixing process from scratch;
  • If you think that Delphi is not a trendy technology;
  • If you don’t have ROI or you cannot calculate your it;
  • When risks are too high.

How we can help

Finally, if you have made a decision to migrate, we are here to help you and are ready to:

  • Create a new architecture;
  • Select an appropriate technology (WinForms, WPF, ASP.NET, ASP.NET Core, etc.);
  • Rewrite the entire business logic from scratch;
  • Design and develop the entire UI from scratch;

Unfortunately, usually we don’t have possibilities to reuse Delphi code for a future .NET application. Sometimes we can use Delphi compiled dynamic libraries (if your software were divided into different modules beforehand) and attach them as an unmanaged code (this is not recommended by Microsoft, and you cannot use this trick for any .NET technology and version). But, unfortunately, in real life we just don’t have such possibilities.

Get a free expert consultation about migration of Delphi to .NET

Creation of a new architecture

If we speak about .NET and other Microsoft technologies, we have different types of software, which can be united based on common classes of .NET Framework and the same programming language – C#. If we are going from a regular desktop application, which was built 10-15 years ago – it has sense to totally review the architecture. For instance, you can create a multi-tier architecture and divide a desktop application with direct DB access into the thin client for UI, REST API server, based on Azure serverless computing and cloud database (e.g. Azure SQL). Of course, each software has its own case.

Selection of an appropriate technology and a sub framework

It seems that Microsoft invents new revolutionary technologies each 3-5 years. Nowadays for desktop or web development we have different sub frameworks inside .NET Framework. Some of them are already obsolete (and we need to perform a separate migration from the legacy .NET Framework to an up-to-date .NET Framework), some of them are too “fresh” and not proved by time. This is why it is very important to predict what will happen to the selected framework in 3-5 years, nobody knows whether it will be compatible with new versions and so on. Do you remember such a revolutionary technology as Silverlight? – This is what we are talking about… And that’s just a “clear” proof of our opinion.

Rewriting of the entire business logic from scratch

Unfortunately, we cannot re-use Object Pascal source code for Visual Studio and C# projects. It means that we have to rewrite from scratch the entire tested source code. One of the main pains – visual components migration. Delphi and C++ Builder are rapid application development tools (RAD), where a huge part of logic is stored inside components (built-in or 3rd-party). You can just drop these components to the form and use their logic. In terms of migration from Delphi to .NET – be ready to rewrite the entire source code from scratch (use .NET analogue or develop the same components logic from scratch).

Design and development of the entire UI from scratch

We will have the same situation with UI. You could use amazing Delphi components, which don’t exist for Visual Studio (of course, some vendors have the same component packages for Delphi and Visual Studio/.NET, e.g. DevExpress). Especially if we migrate from desktop to web or even from desktop to cross-platform (Xamarin). On the other side, such technologies as WPF and Xamarin have their own flexible UI designing principles, which allow you to build rich UI applications using standard Visual Studio techniques. By the way, the same UI designing principle is implemented in the FMX framework (complicated component is a set of an element sub components tree).

As we have already mentioned, each migration has its own pitfalls. Before any migration we have to perform business analysis and risk management. Who knows… maybe in 3-5 years you will go back to the same technology that you’ve started with.

Subscribe to our newsletter and get amazing content right in your inbox.

This field is required
This field is required Invalid email address
By submitting data, I agree to the Privacy Policy

Thank you for subscribing!
See you soon... in your inbox!

confirm your subscription, make sure to check your promotions/spam folder

Subscribe to our newsletter and get amazing content right in your inbox.

You can unsubscribe from the newsletter at any time

This field is required
This field is required Invalid email address

You're almost there...

A confirmation was sent to your email

confirm your subscription, make sure to check
your promotions/spam folder