Know how to measure technical debt. It's usually an umbrella term to describe different risks and complexities in the software.   Instead of re-writing a legacy system consider evaluating its current state and looking at the product and business goals. Interviewing the people who work on the system can give you a good sense of the urgency. Look how many escalations or production issues the product has over the past months or years. Use retrospectives with your team to understand what can we do to make us more productive, to increase the velocity.   You can divide the tech debt into engineering and business debt. The latter is measuring the time to market, end-user experience, and stability. Software is enabling the business and that's why it needs to be ahead to provide the right opportunity for the business.   Identify and prioritize the work. In order to get buy-in from the stakeholders, you need to back it up with the data, estimates, and return on investment.   Big migration and refactoring are not always the right solution and even can introduce more problems. Because the complexity in the legacy system is hidden until you open it up during the migration. This can lead to the increased scope and more pressure to deliver.