I was wrong. Every time. Unless the system is quite small and single-purpose, you very likely don't understand the full scope of what it does, why it is written the way it is, which constituencies it serves, all of its interfaces, etc.
The few times I have been involved in rewrites they always took longer than expected, cost more than planned, and ended up with kludgy patches at the last minute as features of the old system that nobody talked about or knew existed suddenly became showstopper must-have requirements. In other words, they turned out like almost any other corporate IT project.
Customer X wants the product in 12 weeks or they're going with a competing product. Customer X may be spending 6 or 7 figures with us over the next 5 years in upfront costs and ongoing maintenance and support fees.
You may be saying, "It'll just take 6 months (24 weeks) to re-write this from scratch and do it right" (managers are used to hearing programmers say this sort of thing). For the most part, managers don't care about "doing it right" from a technical perspective, they only care about the bottom line. How is doing it right going to make more money (especially if we loose customer X in the process???)
Also, be careful when making this suggestion. Many programmers who suggest this are simply uncomfortable with other people's code. They can write stuff from scratch themselves, but can't maintain or extend code they've not written (that's always a bad sign). And to make matters worse, they always use the argument "stuff I did not write is horrible".
So unless you feel really compelled to do this, and you can do a good, objective quantification (here is why a re-write will make us more money) as why it must be done, don't bring it up.
Also, telling mgt that a whole team in the company produces bad code may not be in your interest and it certainly won't make that team your friend going forward.
Another factor is the lack of budget in the project =/
One major way to tell: can you clearly specify what the revised version should be doing, in a way that doesn't involve "whatever the old version did"? Another litmus test: do you fully understand the old code and why it sucks the way that it does?
Mind you, refactoring can happen at a fairly high level -- if you identify the worst, most broken part of the code and first lock down/simplify its interfaces, you can write a drop-in replacement for that whole chunk. Just remember that if writing your drop-in replacement is going to take weeks (rather than days)... or if your estimate keeps sliding..., you've probably chosen too large a chunk and should slice & dice a bit more.
I've had this discussion so many times that now I just have it with myself, and generally only say aloud the correct answer (though it's disappointing).
Psychologically, it's a beautiful thing to wipe the slate clean and just do everything fresh from the start. If only this worked as planned more often (and budgets were hefty enough to support "doing it right", and there were not already a user base who actually wanted to keep some of the broken bits because they knew how to use them already, and you didn't have to deal with a few team members who seemed to always be writing more code just like the old stuff, etc etc)...
Then, send it to yourself.
If, for instance, you can change the platform and do the rewrite significantly faster than the original technology and implement changes faster, then the rewrite may be the may to go.
Imagine you have an app built on J2EE, with lots of logic on templates and no tests whatsoever. It's huge and maintaining it takes a huge effort. Every bug takes weeks to fix and generates wrong data that has to be corrected manually.
Imagine you can write an equivalent app in Ruby on Rails in two weeks, with tests.
Which way would you go?
"Imagine you can write an equivalent app in Ruby on Rails in two weeks, with tests."
You've already said that the existing app has "lots of logic" and is huge. Every bug takes weeks to fix, which means the "lots of logic" is seriously twisted up and not easy to decipher.
If that's the case -- figuring out the logic to fix one bug takes weeks, then it's inconceivable that you'll untangle all of the logic in two weeks. That's before you write a single line of Ruby -- if you want an "equivalent" app, that means you have to know what the current one does, first.
This is the usually-fatal flaw in the "rewrite" argument. The existing app needs to be rewritten because no one can understand it anymore (is is both poorly-written and very large/complex). But because no one can understand it anymore, it will be extremely difficult to rewrite, unless you work as if you were creating a new, similar application.
This is also why refactoring works. You cut off a bit of the existing app, figure out just that bit, write tests for it, and then replace just that bit with new code.
You can even refactor an app into a completely different language, actually -- you have two apps running parallel, and gradually move over bits of functionality from one to the other. In the process you'll need to gradually enforce order (and separation of concerns...) on the original app, but you need to do that either way.
First, a huge Java app is about 3 to 10 times smaller (in LoC) when ported to Ruby or Python.
Second, there is a lot of boilerplate code and configuration in a typical Java app. Not nearly that much with either Rails or Django.
And third, basic CRUD functionality, something that has tons of Java boilerplate associated with it, is usually very simple with Rails (or Django).
As for the tangled logic, it's the way many apps evolve. They are designed at their start and then refactored and patched into their current form. The current app wasn't designed anymore - it evolved - and, in order to properly maintain it, you'll have to understand how and why its evolution took place.
One more point - in order to reimplement it on top of a more modern framework, you don't need to understand thoroughly what your mutated-beyond-recognition Java app does - you only need to know what it should do. The fatal flaw you point out may not exist.
If you don't know what the app should be doing, then I have to agree - you are doomed from the start.
Refactoring will give you some time, as it reverses the mutations back into a designed state - and improve things a bit, but it will not be able to bring the orders-of-magnitude improvements you see when migrating from an old and obsolete (but still widely used) infrastructure, to a more modern one. That's when a rewrite would be warranted.
The app with the twisted logic (where bugs take weeks to fix, that has mutated over years and years of hacked-in change requests and quirky tweaks often for specific users' needs) is the one that screams for rewriting, but this is also the app where no-one knows exactly what it does anymore.
And if you don't know what it does, I have no idea how you could claim to know what it should do.
Many of the odd features are there for customers who aren't even customers anymore, but no one knows. Even the code doesn't always help much -- I've seen processing where it fails in the mid-method every time for some foolish reason (and logs an error then returns), but the code after the failure is actually direly broken and must never be executed.
I've tried (failed, actually) rewriting one of these as well as doing lots of refactoring on these kinds of projects.
With the first kind of app, you still understand it, so bugs can be fixed, new features are possible, and there's no clear case to rewrite it. With the second kind of app, you can either do what I mentioned above (and maybe you're talking about this, more than a rewrite?) -- start talking with/watching users, take a lot of notes, and build a new similar application all the way through, which will necessarily start off missing much of the functionality of the existing one.
Refactoring isn't about giving you time; it's about paying off technical debt and forcing the codebase back into a state where you can do progressively larger refactorings. This includes modularizing the existing app so that you can replace it piecemeal. New pieces do not need to operate within the old framework. It's quite possible (and sometimes desirable) to refactor the original codebase completely out of existence.
This is the difference between software and most other forms of "construction." There are no material costs. There is no scrap to reclaim. Bits can't be reused like steel. Tearing down code is negative work. This is also goes toward the odd feeling we often have that software shares so many attributes the fine arts even though it shares so many attributes with engineering disciplines.
First: realize that the word rewrite, not the act, strikes fear into the hearts of people. Just don't say it.
Second: realize that the difference between a "fix" and "rewrite" is nil. Are you going to fix it without changing it? Not if the problem is really in the code. You don't edit out the plot hole in your novel or unpaint your landscape into a lounging nude.
Now, the answer: say you'll fix it. You're really talking about the same thing. You asserted that it would be cost-effective and efficient. To me, that implies that it will address the urgency.
It's almost always quick and easy to fix what you know is wrong. The part that makes it hard, slow, and expensive is rolling it out. For instance, it may have taken a week to design a better data model for your SaaS app vs. a month to try to find and mitigate a slow query, but now you have to figure out how to migrate all of your clients, and that's a bitch.
Although, rewriting can be a lot of work. While there may be a temptation to rewrite everything overnight, it can be quite difficult to pull off. Although, I think devoting some time to a rewrite attempt may help you gauge the total time it will actually take. If it proves easy enough, you can go for it.
Then I would provide the benefits of doing both and then I'd present this to the person and say having, looked at our current code I believe that we should rewrite it because of X, Y and Z, in fact I'd even summarize this at the bottom of the table as well incase they want to take the table away and think about it.
Can you be more specific about why the code is bad? There are a limited set of architectural reasons for which I would support a complete rewrite. They typically correspond to non-functional requirements: 1) scale - the system architecture simply cannot support scaling 2) reliability - the system architecture is built in such a way that the system often fails 3) multi language - the system needs to be modified to support multiple languages 4) security - the system needs to be modified to support a more robust security access model etc (there are many items like this)
These things all touch every single bit of code and so could warrant a rewrite. Im skeptical of most other reasons. In most cases you can just modularize the most dangerous aspects and you will be fine.
Likewise, function names are ideal to refactor -- many IDEs will automate this for you.
I don't know your situation, but this sounds to me more like framework envy (and I base this on experience... I've worked with projects on a lot of crappy and/or homegrown frameworks before). If you haven't actually done any major projects in the newer framework yet, that's a bad sign as well, I'm afraid. :)
On a more positive note -- it might be possible to incrementally move to a new framework. It's harder if you want to switch languages/environments completely, but if not, it's probably quite feasible (switch over a feature at a time). If both frameworks can access the same session storage... that's likely the main tricky aspect.