Poorly written PHP will most likely be very difficult to convert, because many bad things in PHP simply do not exist in Java (the same is true and vice versa), so do not accept this because I say that Java is better - I will keep a good watch this fiery war).
If you are talking about an outdated PHP application, it is highly likely that your code contains a lot of procedural code and embedded HTML, none of which are going to convert well to Java.
If you're really unlucky, you'll have things like eval() , dynamic variable names (using the $$ syntax), looped include() statements, register_globals flag dependency, and even worse. Such things will completely hinder any conversion attempt.
Another serious problem is that debugging the result after the conversion will be hellish, even if you have beautiful code to start with. If you want to avoid regressions, you will basically need to go through the entire code base on both sides with a thin comb.
The only time you get a satisfactory result from an automated conversion of this type is if you start with a database with enough tides, written, at least mainly in the updated OOP code.
In my opinion, it would be better for you to do refactoring before the transition. But of course, given your question, this is more likely to win. So my recommendation is to stick with it in PHP. PHP code can be very good, and even bad PHP can be polished with a bit of refactoring.
[EDIT]
In response to a @Jonas question in the comments: “What is the best way to reorganize horrible PHP code?”
It really depends on the nature of the code. A large monolithic block of code (which describes a lot of bad PHP that I saw) can be very difficult (if not impossible) to implement use tests. You may find that functional tests are the only kind of tests that you can write on the old code base. They will use Selenium or similar tools to run code through a browser, as if it were a user. If you can get a set of robust functional tests, it helps you stay confident that you are not introducing regressions.
The good news is that it can be very easy - and satisfying - to break up bad code and rebuild it.
The way I turned to him in the past is a two-step approach.
The first step rewrites the monolithic code into a procedural code of acceptable quality. This is relatively easy, and the new code can be dropped into place when you go. Here, the bulk of the work happens, but you still get the procedural code. Just the best procedural code.
Stage two: after you receive a critical mass of a reasonable high-quality procedural code, you can again transform it into an OOP model again. This has to wait longer because it is usually quite difficult to convert the old poor quality PHP directly into a collection of objects. This should also be done in fairly large chunks, because you will be moving a large amount of code into objects at once. But if you did a good job in the first stage, then the second stage should be quite simple.
When you hit objects, you can seriously think about unit tests.