Legacy Cleanup 101: Your Guide to Managing Technical Debt

This article was written by Henn Ruukel, Principal Group Engineering Manager for the IC3 Fraud Prevention Team at Microsoft. 

If you currently own or are about to build a technical system, you will also need to figure out the "why," "how," and "what" about that system's legacy. In this article, I would like to share my perspective on this topic, which I have gathered based on modernization efforts in my team here at Microsoft. 

We have a 15+ year history of building spam and fraud detection systems using various technologies. This has led us to a significant variety in our tech stack, which we have systematically cleaned up over the past few years (and are still working on). Hopefully, this helps you in your journey!  

What is legacy?  

One way to define legacy is that anything you build becomes your legacy once it is born. From that moment onward:

·       it requires effort and maintenance to keep working;

·       it both limits and empowers your potential for future developments;

·       your team's skills and knowledge must include capabilities to maintain and modify it as long as it exists.

This definition doesn't only apply to the code you create. It also extends to business logic/functionality, architectural choices you make, and the infrastructure you choose to use. All components and layers of your system are part of your legacy.  

So, if you agree with this definition, you cannot avoid creating legacy. Therefore, it's better to accept its existence and incorporate elements into your planning process that constantly review opportunities to invest in legacy cleanup.  

Why should you invest in legacy cleanup?  

Each system and team probably has its own reasons and motivations, but here are a few common ones: 

External Dependencies and End-of-Life: When a technology or library provided by an external party is being deprecated, you usually receive ample notice to migrate or upgrade. This is a straightforward case with clear external motivation and deadlines.  

Technological Entropy: As your team and its portfolio of different systems grow older, you're more likely to face technological entropy. Different systems built at different times by different people naturally create variety in architectural approaches and tech stack decisions. While technical variety can make sense, consider consolidating technologies, when possible, to save costs and improve engineering efficiency.  

Team Intellectual Ownership Risk: It's essential to avoid situations where only a few people in the team can maintain and modify a particular system. This situation can create dependencies and dissatisfaction. Investing in this context involves freeing up these individuals and enabling the wider team to own the system again.  

New Technology Opportunities: Occasionally, the team may be tempted to try out new technologies. Invest in these opportunities while ensuring a clear commitment and decision-making process for adopting new tech.

How to manage legacy cleanup (in parallel with product development)?  

Assuming you and your stakeholders agree that investment is worthwhile, here's how to make it happen in parallel with your regular product development, where the backlog usually contains more new work than your team can deliver.  

Continuous Investment: Treat legacy cleanup as an ongoing process, similar to a monthly payment. This approach prevents situations where you need to halt all new work for several months to address legacy issues that have accumulated.  

Scope Management: Avoid mixing cleanup with system logic improvements. While it might be tempting to revise business logic during migration to new technology, this can expand the scope and time spent on migration.  

Short Iterations: Keep the scope of migration clear and small. Think of migration as jumping from one ship to another. Avoid spending months in a state where parts of the system have migrated while others haven't. Measure progress in calendar time, not developer hours.  

Dedicated Isolated Mission Team: Depending on your team's size and capabilities, consider creating a dedicated project team focused solely on migration, especially for multi-month projects. Alternatively, manage migration projects within the team, treating them like any other backlog work if the scope is clear and small.  

In summary, legacy is continually created, so invest in managing it openly and transparently within your planning cycles. I hope these thoughts help, and good luck!

At Digit Conference 2023, Microsoft is also figuring in a panel discussion called "Technical Debt: The Silent Killer of Software Projects and How to Overcome It", where you could learn more about legacy cleanup and so much more!