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.

Ask yourself why you want to move from LAMP; is it because of deficiencies in the stack, or deficiencies in the practices and design around the original application? Bad code can be written in any environment, from assembler to the most astronautical architectures.

Currently, my company runs a highly scalable set of web services on Linux, nginx, MySQL, and Python; the biggest hurdle has been the problem of poorly written legacy code, not the scalability of any of the aspects of this stack. You could do the same thing in Java, or .NET; it really doesn’t matter, as long as you have the expertise in that stack to make it effective.

Yep, you have a problem – but the solution is not to rewrite!

Now, solutions for actually fixing your problem in a constructive way.. you need to start shearing off layers of the old system and replacing them, that’s clear, and that means that you need to maintain compatibility with what you already have. So that sounds like web services (which you can write in any language you like, C++ even).

So, identify which parts of the system can be replaced with a totally independent web service, and start to reduce the complexity of the main system. Then, once its been cut down to a more manageable size you can start to refactor (sorry for using that clichéd word) the codebase to get rid of any irrelevant cruft and replace it with something a little more well-designed. Hopefully you’ll be able to see how more modification, maybe replacing larger parts of the main system with better-written code would then help more.

And once you’ve done that, chances are you’ll have a maintainable, extensible system that is a solution.

The trick is:
1. independant components, well designed to a specification and documented as to how to use them and what they do.
2. rework some of the existing code so it still works exactly the same way, but better. This means you’ll have to document what its supposed to do.
3. Document it some more – I don’t say this because of liking documentation, but because it sounds like there was a general lack of rigour in how the system has been worked on in the past. Hack some code in, hack in some more and you end up with a mess. Force documentation and specifications and you’ll have a much better chance of keeping things in line.

I don’t see any path from this that isn’t full of failure – one of the biggest draws of the LAMP stack is that PHP has a lot of libraries, and if the code is already in PHP you’re certain that PHP supports anything you need to do.

You can write bad, unmaintainable code in any language, but your choices for “Enterprise” web are basically Python, Ruby, C#, Java, or PHP. The only benefit of moving away from PHP might be moving to a statically typed language – that’s one argument I could agree with, but for anything else I don’t think there’s a strong reason from moving away from PHP as a language.

First of all, any use of C++ for web development is so incredibly niche as to not even be worth considering. If you’re asking “what language should we use?”, then I can guarantee you 100% that the answer is not “C++”. That out of the way, as others have said, there are options:

I would say that far and away the two most common choices for enterprise-y web applications are Java (and one of its frameworks) and C#/.NET (probably ASP.NET MVC for a greenfield development, ASP.NET Web Forms for anything that’s been in production a while). I find the decision between those two is often largely driven by preferred server OS. Java for Unix, .NET for Windows. You can do Java on Windows but it often makes you sad. You can allegedly run .NET on Unix using Mono but I would recommend against betting your business on it.

Others have mentioned Python and Ruby. My personal experience with these two is little and none. My understanding is that there are quality frameworks for both. My understanding is further that they are not particularly commonly seen at the enterprise end of the spectrum.

Those who have dismissed PHP out of hand have already been accused of bias. I’m biased as well – I dismiss PHP out of hand, and I think you should too. You’ve already built one absolutely typical PHP trainwreck, don’t go out and build another.

Having said all of that, you describe “a very large web application”. You mention “possibly hundreds” of programmers having dipped their oars into it over 10 years. I’m going to assume that you have quite a few programmers working there. And I’m further going to assume (possibly inaccurately) that this large PHP application is the main or only thing they are working on, and that therefore, many or most of these programmers do not have any significant large-scale experience with anything other than PHP.

They are not going to built a good “second system” in any other platform.

If you’re going to do this thing, you need it to be started off by experienced developers who live and breathe the platform you choose to use. I said above that my personal experience with Python and Ruby is little and none. I could easily learn them and I’m confident I could write good code with them. But if I tried to use a large-scale system as a learning experience, I’m positive I would produce a trainwreck which didn’t take 10 years to look as bad as the system you’re hoping to replace.

Ultimately, if your company can afford to spend the time, effort and money on a second system (and rewriting a 10-year-old system will be a lot of time, effort and money), you’re going to need to spend a fair chunk of that hiring people who have extensive current experience in the platform you select.

According to Joel Spolsky – the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.

You say:

poorly written due to a large number of patches and possible hundreds of programmers

That is not the reason. Joel explains all in the following article http://www.joelonsoftware.com/articles/fog0000000069.html

Read it and then think about how you can make what you have better.