Sandbox. If at all possible, you should have a complete environment on your machine including database, web server, caches and what else that is part of the actual live installation. This does not mean you need 10 load balancing web servers or a million row database, rather it should contain enough of it to be representative of the real installation. You should also be able to re-create this sandbox with a simple command (including populating databases, installing environment etc).
This applies to all languages and not just PHP.
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.
Best Answer
As far as why LAMP has a bigger mindshare (if not market share) than WAMP: probably because the LAMP components don't have licensing costs. That makes getting started cheaper. Cheap Linux hosting has to be cheaper than cheap Windows hosting just for that reason alone. The free/libre nature of LAMP makes it possible to just try it out for free. From there, everything else is an accident of history, although IIS and Windows have historically had more and more severe security problems than Apache and Linux.
As far as what you need to know as a developer:
ls,ps. Not just to run them, but to understand them, how to find out information about them. (man ls,man ps, the "--help" type options).ssh,scp,sftpcan help.If you have spare hardware, even 5 or 6 year-old hardware, you can easily install something like Slackware linux distro. Just getting Slackware up and running will teach a lot, configuring Apache, MySQL and PHP will teach you even more.