I think you need to determine;
a) what part of the code is related to business logic, data manipulation (database) and such things as proprietary file structures, mathematical processing, etc.? This is material that can pretty much raise the “as is,” because it will most likely be written in Pascal with the much smaller, more obvious elements of OWL / BP7. For example, when I did this using the application, I had a series of units that were engaged in loading / saving proprietary files, material for calculating Easter eggs, material for working with mathematics on arrays, etc. - All this happened from BP7 to Delphi (1) with virtually no changes.
b) what part of the code is associated with the graphical interface (and nothing else) - message loop handlers, dialog element constructors, control properties, etc. This stuff will require a lot of work for the port in Delphi, and if you can not find someone with a good line in .RES →. DFM (or similar), I think you will look at creating this bit from scratch. Not bad, because if it is a 16-bit application for Windows, then you probably want to use this opportunity to at least make it more “modern”. I think this will be the most time-consuming part of the project.
c) what part of the code uses things that, as you know, can be done differently in Delphi, but it will work like it is now, on pascal? This is where @BloodySmartie points to the transition to an earlier version of Delphi for me. You should port this project to something like Delphi 5/7, making obvious (and well understood) changes to things like string manipulation. The more of this material you can leave without transport, the better, in my opinion. Get something that works, and you will check the basic behavior, and then proceed with the refactoring / refinement process to make the most of Delphi when and when resources allow. You can have (like me) arrays of pointers in BP7, where each pointer goes to an array of pointers, which ultimately lead to the object - this is how we circumvented memory limitations in the 16-bit Windows world. When I first ported my application, these pointer arrays to pointer arrays still worked fine in Delphi, and I left them alone until I had time to do something more "Delphi-like" with structures.
But before you do all this - why are you porting the application? If you port it, because in any case you are going to make a reasonable amount of changes to the functionality of the application, then it may really be the right time to rewrite the application. Since you are rewriting in Delphi, you can still use pieces of functions and procedures that are still based on a business rule, so this is not necessarily a complete and complete rewrite from scratch.