From Legacy to Heritage:
I work for BMW and when I joined I was told not to use the word “legacy” to describe our application, but instead to use the word “heritage” due to the way “legacy” brings up negative connotations.
I sat down and thought about it and realised that “legacy” is actually very damaging.
Changing How We Talk About Established Applications
The way we talk about our software systems profoundly shapes the culture of our development teams and the perception of the code we maintain. For decades, the term “legacy application” has dominated our vocabulary, often carrying a heavy burden of negativity. It implies old, slow, cumbersome, and something to be replaced rather than respected.
It’s time for a linguistic upgrade. Instead of labeling our foundational systems as “legacy,” we should embrace the term “heritage application.” This simple change shifts the narrative from one of obligation and burden to one of value, history, and strategic importance.
Why We Must Stop Using “Legacy”
The primary issue with the term “legacy” in a software context is its inherent negative connotation. In general use, a legacy is often an obligation or a financial burden left behind. In development, this translates to:
- Implied Technical Debt: It suggests the system is fundamentally broken, poorly coded, or riddled with flaws—even if it’s the most stable, profitable system your company owns.
- Demoralization of Maintainers: Developers responsible for “legacy” systems often feel their work is less valuable or exciting than those working on “greenfield” projects. This leads to low morale and higher staff turnover on critical systems.
- Justification for Reckless Rewrites: When a system is labeled “legacy,” it becomes easier for management to justify an expensive, risky, and often unnecessary complete rewrite, rather than opting for disciplined refactoring and iterative improvement. As Martin Fowler famously put it, “Legacy code is code without tests.” The problem isn’t the code’s age; it’s the lack of maintainability.
- Stigma and Fear: New developers approach “legacy” code with apprehension, assuming they are about to face a nightmare of spaghetti code, rather than seeing an opportunity to learn from years of business logic implementation.
The Power of “Heritage Application”
Switching to “heritage application” reframes the conversation around your established software assets, introducing several powerful, positive concepts:
- Focus on Value and Reliability
A heritage application is one that has stood the test of time. It represents years—or even decades—of:
- Proven Business Logic: It contains the core, hard-won knowledge of your business operations. Its functions are battle-tested and reliable.
- High Stability: It continues to run mission-critical operations without fail. You don’t replace heritage systems because they work and make money.
- Strategic Foundation: It is the reliable bedrock upon which all new features and systems are built or integrated.
- Respect for History and Craftsmanship
The word “heritage” recognizes the skill and dedication of the developers who built and maintained the system over the years. It shifts the focus from perceived flaws to:
- Intellectual Property: It acknowledges the immense intellectual investment contained within the code.
- Mastery: It encourages developers to view working on the system as an opportunity to master complex domain knowledge, rather than fighting a losing battle against obsolescence.
- A Path for Modernization, Not Destruction
Using “heritage” encourages a mindset of evolution and preservation over pure destruction. The conversation moves from:
- Old (Legacy): “How do we kill this system?”
- New (Heritage): “How do we strategically modernize the most critical components to meet current needs, while preserving the proven stability of the whole?”
By making this simple linguistic pivot—from the depreciating “legacy” to the valuing “heritage”—we foster a healthier, more respectful development culture focused on stewardship rather than abandonment.
