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: 
Keep in mind that refactoring introduces bugs as well (which you will catch in your testing, but nonetheless are bugs and must be fixed). Don't pull a Netscape on accident. It depends on your personal definition of "refactoring." To some, this means "rewrite all the code" to others it means "change some internals." How do you tell what kind you are? Ask yourself the following question:

Am I changing the public interface at all?

If the answer is yes, you are doing redesign. If the answer is no, you are doing refactoring and can probably just do it along the course of your daily activities without special approval. This is relevant to your question because a redesign will generate many more bugs, while a refactoring is usually easier to perform (since your tests will already exercise the public interface and will not themselves need to be modified).

It is a difficult case to make, because no one ever knows how much X would have cost with or without the refactor that was done a year ago. In my experience the pragmatic managers always shoot this kind of thing down because:

1. No direct revenue stream comes from the effort (financial cost, not billable)
2. Ugly working code is still working code, you risk creating problems instead of fixing them (potential quality cost)
3. Other projects will be delayed while you refactor (time cost)
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.