At my office, we are about to embark on an epic journey of converting an old Delphi 5 application to something more modern. One of our options is to convert to Delphi Prism, but we want to see what options are available to help us. So far, all I've found is Oxidizer (last worked on 2 years ago). Are there any other options for helping us convert reasonably quickly to Prism? Thanks.

  • Why are you trying to convert to Prism, as opposed to updating to a more modern version of native Delphi? That would certainly be far less of a headache. – Mason Wheeler May 11 '11 at 23:20
  • It might be less of a headache, but we want to be able to take this application as far into the future as possible, and going with a newer version of native Delphi is no guarantee that 5 years from now there will be any support. However, we're fairly confident .NET is in for the long haul, and converters from Delphi under .NET to C# are quite easy to work with later. There's other reasons for converting to .NET, as well, but that's one of the larger ones. – Tom A May 11 '11 at 23:24
  • I wouldn't be worried about that. I'm pretty active in the Delphi community and I know several of the Delphi team members, and IME there's no reason to doubt that Delphi will still be alive and under active development and maintenance 5 years from now. You'd really be better off saving yourself the headache. Prism is similar to Delphi, but it's different enough that what you're headed for is basically a rewrite anyway, which is the classic Thing You Should Never Do. – Mason Wheeler May 11 '11 at 23:36
  • 1
    @Jerry: Borland is dead, and they're no longer in control of Delphi. Embarcadero <> Borland. – Mason Wheeler May 12 '11 at 0:53
  • 2
    Also to add my two cents in for the improvements to Delphi, I'd like to see Embarcadero stop treating Delphi like it's a side project. When I looked at the feature matrix for Delphi XE and Delphi Prism XE, I felt like I was looking at Visual Studio XP (2002). Embarcadero is a long ways behind other companies in the capabilities of the tools they provide, and it doesn't help that a lot of versions of Delphi kept getting ragged on for being buggy, bloated, and difficult to use (I've even seen comments for XE). Not trying to be mean, just honest. – Tom A May 12 '11 at 14:57

As many comments suggest and encourage, rewrite, yes. Why? Many of those reasons have been mentioned in comments, notably the declining degree of direct language and tooling support, 3rd party component support, but also not mentioned is a decline in available talent to keep the ship going. It is the same problem that many of the mainframe era and direct derivative projects face: talent and interest in those types of systems is waning.

One of the biggest challenges for a migration effort isn't what language or platform or toolset to go to, especially today: there are lots of good options, some better than others depending on what one is trying to accomplish and expect from the resulting effort. Today the biggest challenge, as it has been for years, is finding the right talent to translate the old system into the new, or at least translate it well enough and efficiently enough for others to build in the new.

In the OP's case, it sounds like that they have not only skilled practitioners in not only the legacy language and tooling, but also to a degree are highly familiar with the customer and the domain. That is a big advantage.

What I suggest, based on my experience with genuine legacy migration projects, is take a bigger jump while there is expertise on the originating end. It becomes monumentally harder when those builders and maintainers leave.

  1. System usage and stability assessment. Is the system doing the things the customer needs, no more and no less? Are their particular pieces that can be isolated to a degree? Are there pieces that have plagued development because they are prone to breakage or get frequent complaints about? Are there pieces from the user's perspective that are missing (use cases that would fit the system scope that haven't otherwise been identified)? And so on...

  2. Use that information from the usage and stability assessment to initiate a spin-off, incubation project for coming to a more mainstream platform that tooling and training will be plentiful for in the foreseeable future. Use a mix of architecting/re-engineering and straight porting to get off the ground.

  3. Prove out the new pieces using phased, selective deployment to users.

  4. Evaluate progress to effort spent.

  5. Ramp up migration if everything is going as planned.


Personal recommendations:

  1. C# on a Windows or web platform as it provides familiarity in a lot of ways to Delphi, and it will be the draft horse of Microsoft for a while.

  2. Possibly a foray into mobile. It depends on what the customer needs and wants as this could change how I would prioritize it. One of the things the ThoughtWorks Radar suggest is many companies are moving to a mobile-first strategy for new projects. I personally would be most inclined to suggest the route of Android if looking at native apps, primarily because it's pervasive, but also in OP's case, mobile Java would be a fairly comfortable transition from Delphi. Google is definately not going away from this anytime soon.

  3. Ada. Just kidding.

  4. Possibly Python or Ruby. I am somewhat agnostic about both, but they certainly have some merit.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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