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.
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.
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...
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.
Prove out the new pieces using phased, selective deployment to users.
Evaluate progress to effort spent.
Ramp up migration if everything is going as planned.
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.
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.
Ada. Just kidding.
Possibly Python or Ruby. I am somewhat agnostic about both, but they certainly have some merit.