Technical Debt is the amount of work required to eliminate the compromised quality in a codebase. The "interest" paid on technical debt is reduced productivity as compared to the productivity that would had with a good codebase.
One way to consider technical debt is to think about the difference in productivity between a developer with 5 years experience working with the code in question versus the productivity of a developer who, though with the same amount of similar experience, is new to this code. If the developer of five years experience in the codebase is significantly more productive than the developer new to the codebase, the experience required to be productive has a cost, the salary of the developer to gain that experience plus the salaries of those who taught him what he knows plus the cost of lessons learned the hard way.
What is the price of reducing technical debt? It is, no doubt, high. To determine it, we will find the desired end point then determine the cost to achieve it.
What is the end point to this process? It is code that is optimal for the business. Code that never changes probably does not require remediation. Code that does change should be manageable so that change and addition of new features occurs at the rate required by the business with acceptable cost and quality.
The end point of remediating a function point is where
1. the function point is encapsulated
2. APIs and frameworks of the architecture are used at optimal level
3. references to APIs and frameworks are injected by an IOC container
4. code passes static analysis evaluation
When determining technical debt, measures of various code qualities should be used. Using SQALE (Software Quality Assessment based on Lifecycle Expectations), code should meet these standards as it progresses through the development lifecycle:
1. testable
2. reliable
3. changeable
4. efficient
5. secure
6. maintainable
7. portable
8. reusable
My own preference for migrating away from a legacy codebase would be these which may progress in parallel:
1. migrate reporting from the legacy codebase to a solution using OLAP and reporting tool
2. migrate applications to new systems as desired
3. refactor and upgrade remaining applications
Software Architecture - those things in your system that are hard to change. Martin Fowler