Different methods for technical debt accumulation have been discussed, but they have mainly focused on immediate accumulation. Arguably, there is also delayed accumulation, wherein the environment around static software assets changes. Here, updates to the assets no longer deliver the environments assumptions to the assets, they become detached from the environment, and we find the assets to have accumulated debt. This debt closely reminds of software legacy, as it represents assets which can no longer be subjected under the same development actions as newly created ones. In a recent multi-national survey, it was discovered that over 75% of technical debt instances’ have perceived origins in software legacy. This communicates about the close relation between the legacy and the debt concepts. While it encourages us to further explore applying established legacy management methods for technical debt, the relation also exposes challenges. Notably, we should consider if legacy  is being  merely rebranded into the more favorable technical debt. And if this is the case, how do we ensure that all aspects of the legacy instances are identified so as to convert them into fully manageable technical debt assets. Failure to do so, will result into having technical debt assets with varying levels of accuracy, and this undoubtedly hinders technical debt management efforts overall. Nevertheless, while considering these challenges, the software legacy domain should be further researched as both a commonality of technical debt instances and as a possible interface for enhancing existing management approaches.