Congratulations, you've embarked on the single riskiest type of project that is possible.
Complete rewrite, second system, unresolved people problems, lack of technical direction, up front willingness to make it big - any of those are red flags that would cause sane people to run screaming the other way. The only bonus is that it would be hard to pick a worse language than the one you have now.
First we need to set a baseline expectation with some rough figures. On average an "enterprise software development project" upon delivery takes 200% of estimated time, 200% of estimated budget, and delivers 50% of initially promised features. Those aren't the failures - those are the successes. Failure is extremely common, and looks the same as success until the organization pulls the plug because there isn't a working deliverable. That is average. Given the list of red flags that leapt out at me, your baseline expectation should be that you're at severe risk of starting below average.
I wish I was exaggerating. Unfortunately I am not.
You're going to need to start counter-acting that with some positives.
First of all the platform. There are a ton of acceptable platforms that will do just fine for you. If you want to move away from PHP (I'm biased - I would), then I strongly recommend that you embark on pilot programs in different environments to see what works for you. Then go with whatever had the best reception among important stakeholders (including developers!). What you choose will not be more important than whether stakeholders are happy with the choice.
Secondly the feature set. You're building a second system. Your top priority needs to be avoiding second system syndrome. Everyone knows what they do not like in the current system. Everyone has their, "I wish" and "what if" lists. Individually those look great, and they are informed by experience with the first system. But when you pile them all into the second system, it will fail. Therefore someone must be in place to say no to feature requests, and must be ruthless. (Read The Mythical Man-Month for a classic book inspired by an architect of a second system trying to figure out what went wrong.) As a general rule of thumb, on a first system the inexperience shows and a third system generally goes well, but a second system is the most likely to fail.
Thirdly software estimation. Run, do not walk, to pick up Software Estimation: Demystifying The Black Art by Steve McConnell and improve your organization's ability to produce accurate estimates. Very few organizations are any good at it, and improving on this is a top priority before trying to embark on any large project.
Fourth, shy away from the "enterprise" label. In general enterprise software means software that is sold to executives who are disconnected from the actual work. Therefore it possesses excellent marketing and only occasionally technical merit. Oracle would love to get your business. They would definitely make you pay top dollar. But unless you have something specific that you'd gain from them, they don't really have much to offer technically that PostgreSQL doesn't have. And, speaking personally, the largest database that I've seen was a MySQL database at Google. If Google can make it scale to their needs, it can scale to yours. (OK, so Google was able to back it with what was effectively a RAM disk built on top of a redundant array of inexpensive computers. And Google doesn't use MySQL for most of their data storage needs.)
Good luck. Hopefully I scared you. You should be scared. This is definitely a high risk project. But it is not impossible - just very, very risky. A failure to accept, understand, and actively mitigate those risks is a guarantee of failure.
