Question: I am looking for arguments to convince management to invest effort into refactoring.

We log work using Jira and relate every svn-commit to a jira call.

My idea is to do the following:

* manually spot an area of code which is extremely bad implemented, but often used: both from User-POV and of Developer-POV (bugfixes)
* get the svn-commits which contain the JIRA-Issues
* filter the issues according to some criteria (issue type, version, prio. etc...)
* compute the time/effort spent on these bugs
* estimate efforts and risks of refactoring
* present the numbers and ask for effort to fix it.

What do you think of this? Would such a measurement be useful and/or convincing? What are the Pros and Cons?

Answer: 
I've found that if you can provide valid numbers, managers are more likely to act. (If they can understand the logic and the cost/benefit.)

IMHO, to make a convincing case, you would need the following to show how bad it is:

* number of support incidents logged for the issues
* time spent in hours maintaining/band-aiding bad code/doing support
fixes
* time cost based on hourly rate of people doing the maintenance/band
aids/support
* some way to demonstrate how mission critical these items are to the
business

And to make the case for refactoring, you'll need:

* time estimate to refactor and implement each of the top 3 of these
bad things
* cost estimate for implementation (same hourly rates as used above)

With these, you can make the case for time savings if the refactoring takes a whole lot less than support time for 3 incidents for each of those top 3 items. You can argue that this shorter amount of time spent will 

* be less than n more support incidents
* there won't be any more of these incidents for these things (EVEN BETTER!)

However, the hardest part of this sell will be answering the following question, since lots of people don't budget time in schedules for all the support you're doing:

*How much longer will I have to wait for current project Y to get done while you're spending time working on these issues with X?????* (despite the current support timesinks, which can't be predicted and scheduled in Gantt charts) 

This depends a lot on how well you communicate with the decision makers, and how they understand the situation. 

I DEFINITELY think this is worth doing, so you get the practice of building the case with the metrics, and to save yourselves time, even if they don't go for it. Unfortunately, not everyone is easy to convince, despite the data. GOOD LUCK!
All such numbers are ultimately based on guesses, in your case comparing the amount you guess it would cost *not* to refactor vs. what you guess it would cost *to* refactor. The best you can do is show you have some kind of numeric, factual basis for the guesses, and you have a pretty good one.

The pros are that it will probably be effective in convincing them to let you refactor, and it might go well and reduce the number of bugs.

The cons are that if the amount of time spent fixing bugs doesn't drop by at least as much as the time spent refactoring, you probably won't be allowed to refactor anymore, and you will probably be blamed for the "wasted" time. 

The savings in debugging time gained by reducing complexity of the overall project, or in making it easier to add features, may be too hard to measure to help you much, but you could mention that those exist.