Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

If you have several million lines of Delphi code and want to incrementally migrate to .NET/C#, what strategy would you use?

share|improve this question
This is a very, very bad idea, and tends to be a massive failure everywhere it's tried. See Ryan Hayes's answer. –  Mason Wheeler Oct 7 '10 at 20:39
@Mason, you can't possibly know that it's a bad idea if you haven't seen the code. Maybe it needs to be rewritten anyway, and the company decided that if they're going to rewrite it, it will be easier to recruit .NET programmers than Delphi programmers. I'm only speculating, of course, but then so are you; the difference is, I'm stating my assumptions. –  Aaronaught Oct 7 '10 at 21:11
@Aaronaught Rewriting several million lines of working code is always an expensive idea and almost always a bad idea. –  MarkJ Nov 3 '13 at 10:13
@MarkJ: That's why the question says "incrementally migrate", and not "rewrite". Or are you trying to say that you should never upgrade platforms, no matter what? What about all the banks and insurance companies working to migrate all their mainframe and COBOL code? Sounds like maybe you read Spolsky's blog one time and are taking it a bit too literally. Migration to a new platform is one of the legitimate reasons for a rewrite. –  Aaronaught Nov 3 '13 at 19:57
@Aaronaught I was responding to your comment, not the question, and your comment says "rewrite" (twice!). And I was trying to say "rewriting several million lines of working code is almost always a bad idea", not "rewriting is always a bad idea". That's why I said, erm, "rewriting several million lines of working code is almost always a bad idea". –  MarkJ Nov 4 '13 at 16:43

10 Answers 10

I'd take a long hard look at Delphi Prism to migrate to .NET without rewriting in C#.

share|improve this answer
+1 That looks like a good hybrid solution. Nice find! –  Ryan Hayes Oct 7 '10 at 20:37
Don't migrate if at all possible. But if people with pointy hair are forcing it on you, this is probably your best bet. Prism is closer to the original code, and it's also simply a more powerful language than C#. (See prismwiki.codegear.com/en/Delphi_Prism_vs._CSharp for details) –  Mason Wheeler Oct 7 '10 at 20:54
@Mason: Right, a page on the CodeGear wiki - another totally unbiased source. Could you please get over your anti-.NET crusade? It's not just advocated by people with "pointy hair", it's a thriving development community. –  Aaronaught Oct 7 '10 at 21:09
@Mason, it's not inaccurate so much as woefully incomplete. And I'm not here to debate the merits of Delphi vs. .NET and you shouldn't be either. It would really be nice if people could confine their evangelism to discussions where it's actually on topic. –  Aaronaught Oct 7 '10 at 21:16
@Mason: I can read perfectly well, and I think you know that when I say ".NET" I am referring to the Microsoft stack. I don't know anybody that actively develops .NET applications in Delphi/Prism today. If I needed to develop a native Win32/64 app then Delphi would definitely be a contender, but choosing Prism effectively negates most of the advantages of .NET (in particular, the community around C#). –  Aaronaught Oct 7 '10 at 23:23

I had to do exactly this, although it wasn't several million lines, it was an order of magnitude lower than that.

I did it by implementing web services in .NET. Even the old versions of Delphi have decent SOAP support, so you can just start swapping out entire modules for web services written in .NET (just use the basic profile, no WS-* extensions).

And when you're done, you have a beautiful loosely-coupled SOA.

share|improve this answer
I actually did something similar for a VB6 -> C# conversion. The key here is incrementally swapping out modules. Now to make this easier I had to do a bit of careful refactoring but as long as you think before you act it is highly possible. –  ChaosPandion Oct 7 '10 at 22:19
That's the approach I suggest. This way you get an additional benefit from it than just "Yay, look, it works as before!" –  JensG Nov 3 '13 at 10:35
Exactly the problem that SOA was meant to solve. Great answer. Note that in 2013 another good option would be to go for a REST style API. –  Laurent Bourgault-Roy Dec 28 '13 at 2:55


  • Step 1: Find what pieces of the application can be broken off and rewritten individually.
  • Step 2: Get cracking. (It may take a while)

Option 2:

share|improve this answer
+1 for option 2. Every Delphi-to-.NET rewrite story I've heard has been a horror story that validates everything Joel talked about in that post and worse. –  Mason Wheeler Oct 7 '10 at 20:38
I'm sure that's not a biased statement at all, @Mason. Well, I guess there's a first time for everything, and my story is definitely not a horror story. Now, Delphi .NET, there was a horror story... –  Aaronaught Oct 7 '10 at 20:42
+1 (can't vote up anymore for today, but will tomorrow) for option 2 –  user2567 Oct 7 '10 at 20:44
@Aaronaught: Yes it was. Borland never should have tried it, and plenty of people in the community tried to warn them. And now Borland is dead, and Delphi For .NET is dead, but Delphi is still alive and kicking. ;) –  Mason Wheeler Oct 7 '10 at 20:44
Really, Borland shopuld have just written something Prism themselves - Delphi syntax, but using WebForms and other .net libraries/runtime (no TStrings etc, use .net equivalents (ListDictionary from memory) –  Gerry Oct 7 '10 at 23:22

Here is another alternative that I have found to be very effective. Now keep in mind that no matter what you do it will be a hell of a lot of work but by taking in all this advice I think you can pull it off.

One of the great things about C# is that it can register your assemblies for COM interop and will generate all of those nasty interfaces for you. What we did was take modules from our poorly designed VB6 application and have them use functionality from .NET.

Something you really need to remember is to keep your interfaces simple. Try to only require simple types to be passed to .NET. Also you will need to have a considerable amount of upfront planning to layout what functionality you will expose from .NET. You will need to perform extensive refactoring to make sure your new objects will integrate properly with the legacy code.

Once again there is no way you can turn this into an easy task but it can be done.

share|improve this answer

I've seen several attempts at this. So far I can't call any of them a success.

Why do people suggest to spend tons of man-hours to port something to another language?

Usually it's a combination of these:

  • lacking programming skills and knowledge of the original language

  • developers not wanting to learn another language, so instead they want to convert all code to their favourite language.

  • developers not understanding the existing code base, so they underestimate the amount and complexity of existing features

  • overestimating the advantages that a port would bring

  • people not having read Joel Spolsky's "things you should never do" :-)

Slap those together, and you've got yourself a recipe for disaster.

share|improve this answer
Hey, Wouter! Good to see you here on Programmers. –  Mason Wheeler Dec 28 '10 at 19:26
Why do people want to do this? Because (1) good C# devs can be hired all day long while good Delphi devs are rare and (2) Embarcadero's pricing policy, the still next to non-existent platform coverage and the countless sudden strategy changes in the past. BTW, I am using Delphi since it was called Turbo Pascal 2.x for CP/M and we have a similar sized code base here. And no, Free Pascal is not an option. –  JensG Nov 3 '13 at 10:30
@JensG: (1) There are many developers with 15+ years of Delphi experience. Not a single one with that many years of C# experience. :-) (2) FYI: Delphi compiles to win32, win64, MacOSX, IOS and Android. Anyway, nothing wrong with C#. if you've got a trivial tiny app: just rewrite it in any other language. Doesn't matter either way. However, if you've invested serious development time in an app, you'll have to think deeper if rewriting will be worth the effort. –  Wouter van Nifterick Nov 3 '13 at 22:16
"FYI: Delphi compiles to win32, win64, MacOSX, IOS and Android." FYI, that's why I added it: not to brag about it but to show that I know what I'm talking about. I known it, but I also know that "compiles" does not mean much when the rest does not hold. Furthermore, taking sth. into consideration and actually doing it is not the same. –  JensG Nov 3 '13 at 22:48
BTW, I said "good" Delphi/C# developers, that does not necessarily correspond to having countless years of experience. I don't want to elaborate on that subject any further, at least not here. –  JensG Nov 3 '13 at 23:27

The original authors of the refactoring browser and rewrite engine and the SmaCC compiler construction framework described how they transformed a 1.5 million lines Delphi program with 4 (extremely experienced) developers in 18 months. They wrote a Delphi parser and a C# generator, and then added AST rewriting rules and lots of mappings.

To make it successful they didn't hesitate to rewrite difficult Delphi parts, added lots of unit tests, and did the transformation in the daily build. They also still had the original developers, both C# and Delphi specialists, and the code was well-maintained.


share|improve this answer
interesting. Shame the paper is paywalled and I can't read it. –  tom Dec 30 '14 at 17:11
Indeed. I've found sending an email to one of the authors works well. –  Stephan Eggermont Jan 4 at 0:38

The two methods I've used in the past are

  • COM interop (i.e. register either/or/both Delphi and C# for COM and then each can instantiate each others' objects pretty easily)

  • Use mixed-mode C++ as an intermediary to marshal data between Delphi and C#. The C++ can be spoken to from Delphi as a standard DLL and spoken to by C# as a standard .NET library.

share|improve this answer

Identify the part of the delphi code not being used and mark it to not be converted. Press those in charge to make a solid commitment to keeping any of the functionality. When they say, "Well we may need it." get rid of it and promise to add it back to the new version.

See if you can rework any current change requests to the new language. There have been good suggestions on creating services.

Identify problematic pieces of code that has had a lot of bugs identified. It may be worth a rewrite.

It is tough to justify converting what is left, but eventually, the rest of the code may fall under the first three suggestions as time goes by. Business rules may change along the way.

share|improve this answer

You can actually use RemObjects Hydra to combine Delphi and .NET code into a single application. It lets you create plugin modules with either tool, and then combine them together. I've talked to people who have used it to add .NET features to legacy Delphi applications, as wall as others who have used it to move parts of their legacy Delphi application into a new .NET application.

Full disclosure: I work for RemObjects, but I honestly think Hydra is a great tool. More Delphi developers need to know about it because it means you can keep using the best tool for each part of the application: .NET or Delphi.

share|improve this answer

I just started working with Hydra, and in my view you still have to expose the interface yourself. Because I didn't need it much, it was not a problem for me, but it might be a pain if you need a bunch.

That said, I think Hydra is great for having the opportunity of using .NET in Delphi fast. I was forced to implement a .NET SAML client, because Microsoft does not always follow the standard exactly. For this purpose Hydra worked fine.

share|improve this answer
This looks more like a follow-up response to Jim McKeeth's answer. –  Peter Mortensen Dec 27 '13 at 21:23

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.