Software Development
IT Architecture
View more blogs
Modifying legacy systems presents real challenges. Whether its an unfamiliar code base, disregarded business logic which controls the flow of the application, or other aspects of an ageing system such as outdated norms, practices and repository structures.
Here, Senior Software Engineer Liam Treacy explores techniques and strategies which make the task easier.
Challenge: Navigating complexity and unknowns
There is a lot to consider when making changes to a legacy system. The system will often have existing users, a long operational history, a patchwork of sporadic changes or fixes applied by different teams over the years (most likely contributing to accumulated technical debt). And, often these systems no longer align to the organisations technical standards.
Tech author Michael Feathers describes legacy code as ‘code without tests,’ while others say the term is more pertinent to an application/system for which the team responsible has lost knowledge on how it works or why.
In my experience it's often the case that both are true. More generally we can say that a legacy system, is one in which making even a small change (whether a new feature, bug fix, addressing security concerns etc.) is more challenging and difficult than should be expected.
So how do we approach making changes to such systems?
Recommendations: A few simple steps to significant improvements
Drawing on experience of managing legacy systems, including complex interlinked applications, I’ve faced these challenges head on. Here’s how to start with firm foundations:
Maintain stability and respect the code base: Legacy systems usually have a proven history of operation and, while difficult to quantify compared to easier metrics like code coverage or static analysis, it is a very important aspect to keep in mind. You need to respect the code base. Also, the users, or consumers, of the system will be used to the "quirks" of how things flow and react, so you need to bear this in mind and engage with them before making changes. Engage users proactively to understand what they expected from the system before making any changes to legacy code/features. Depending on the age and complexity of the codebase, its often best top focus on feasible improvements that maintain stability – for example, refactoring small sections of code at a time until confidence in the method or code snippet was gained.
Document findings where it adds real value: It's not a good idea to set out to document an entire system in one go but making detailed notes of the flow through the system of a single feature you are tasked with modifying is a beneficial thing to do. Consider a case where you are adding a new field for the user to save in an existing record. By doing this you will gain a detailed knowledge of a vertical slice of the system, from the UI to the database. Over a long enough period such "salami" work will unlock a lot of the mysteries of the system. Clear documentation is also really beneficial when new people join the team and need to start out on the same journey as you – navigating complex systems.
The important basics of the ‘Boy Scout’ principal: Attempt to leave the system in a better state than when you found it. Maybe while working in a particular area, you rename a variable to better reflect the nature of the function it’s in which will hopefully help future developers working on the system. While this may seem like an obvious point to raise, when you’re working on a complex legacy system and fire fighting your way through complexity to make even the smallest impriovemnt, its easy to focus on the end goal and forget the small improvements you can make on the way. If you’re working with a development team, think about how you can facilitate collaborative sessions to identify small improvements.
Legacy systems shouldn’t mean legacy practices: Start with the solid foundations you would in any development envioronment - understand the nature of the applicaions and the technical stack involved. Then focus on bringing in good modern development practices and processes if they don’t exist already from test driven development and static code analsysis to clear processes for updating documentation and Automated tests around new code (where possible). Critically, consider how to build confidence through pair programming and team sessions, which allow everone to share knowledge and confidence and reduce the fear of working on something which may have gained a reputation for being difficult, complex or just not very exciting. Get new perspectives on the code base.
Conclusion
The guidance above can help shape a practical approach to dealing with legacy systems. The process doesn’t need to be daunting or overwhelming. Every system will differ and have its own peculiarities, but the key outcome is to leave the running system, code-base and responsible team in a stronger state than when work started.
Published: February 2026
OpenPerspectives is our platform for Opencast people to share their thoughts and perspectives on modern digital delivery. It offers practical insight into user-centred design, engineering excellence, product leadership, data-driven decision making and building expert capabilities, grounded in real-world experience.
Related Content
View more blogs