The business problem of technical debt
The problem I see here is more of a business problem with technical debt rather than a technical one. I'll answer your question with another pertinent one.
- Why should a customer pay you to rewrite code which will do the same job as it did before, whilst they gain no direct feature or financial benefit?
Difficulties of acknowledging technical debt to customers
Trying to get a customer to acknowledge technical debt is difficult at best and more often than not ends up becoming a case of "why did you write it that way to begin with if it's going to cost me more now?".
Being aware of technical debt and fixing the technical debt as you touch parts of the system incrementally as you have been doing is pretty much the way I would recommend doing any large scale debt reduction.
For any new work I also recommend padding estimates taking into consideration for incrementally fixing your build. It's natural to assume that the more complex the software becomes the higher cost of maintenance is involved. Refactoring and reducing technical debt is an active part of maintenance that should be paid as soon as possible, however break up the maintenance costs into smaller more palatable pieces for your customer.
What Robert "Uncle Bob" Martin says about Ethics and Software Craftsmanship
I think Robert C Martin gives this same recommendation about tackling this very topic in his talk in Part IV. Sorry it's a long watch but well worth it.
Metrics for calculating technical debt is pretty much the same as for estimating time to perform paid work. The trick is identifying the pieces that give the most pain, and chip away at them gradually. Always refactoring so that they always work, however slowing becoming nicer to work with and easier to maintain.
A real world example
I have a backlog of technical debt at the office of a piece of software which has a DAL which is about 80% NHibernate2 but the legacy portions uses Stored Procedures and manual proxys with domain logic written into the SP... (nightmare).
However for every maintenance project we may do say 10 maintenance tickets per 2 week sprint, 1 or 2 of those tickets will be a technical debt item. And the customer is happy with this as these are maintenance items and we get them to sign off on them as part of the maintenance sprints.
So effectively break each technical debt item up into a ticket which could be worked on by 1 developer for a 2 week sprint. This will give you a metric as to how much will it cost the customer, and also give you an indication of velocity as you go through a couple of sprints you will see progress.