Legacy Is Not a Dirty Word
Thursday, May 8, 2025
I’m an architect, I like to solve problems and help create something new, something innovative. I can’t tell you how many “modernization” projects I’ve run, and how often it turns out the organization didn’t really need a whole modernization initiative, the team needed to figure out how to leverage the systems they already had.
You see, in tech, a “legacy system” is a bad system. It’s a dead man walking, something that irritates the tech team and they would love to just get rid of, but somehow business just won’t let go of this fossil, this antiquated system that has been around for over THREE YEARS!
In business, however, there is something called Fiduciary Responsibility; the business team not only wants to maximize the company’s return on investment, but is often required to do so legally. So, if you have a perfectly good system that is working, there really isn’t a strong business case to replace it.
There are sometimes very good technical reasons to retire an old system (like the time my team had a Microsoft Server that hadn’t had any security updates for ten years), but, to be honest, there are lots of things that can be done to maintain older systems while still adhering to modern performance and security standards.
Define Who (or what) should see it
One of the challenges with a legacy system is that everyone in the organization seems to have access to it. Over time, like an old house, different people or services end up with keys, sometimes visitors who honestly aren’t ever coming back (I found I still had access to a system 5 years after I stopped working for a company once).
A regular audit of who has access to legacy systems is critical to data security and performance of that system. Sometimes old jobs run for YEARS in parallel with the “new” process, either because no one knew it was there, or because the team isn’t sure if it’s really needed.
Modern systems need fine grained security. The business needs to control who has access through strong business processes, not just an engineer giving someone some keys. This sometimes requires the use of facades like an API gateway that can use the identity managed in the organization’s IDP (Identity Provider like Microsoft AD/Entre or Google Cloud) or sometimes simply updating the processes to current standards.
I’m a big believer in systems like Sailpoint which allows business stakeholders to approve and audit who has access to what systems. Organizations usually think of this as something only used for people, but, honestly, services like ETL jobs or AI and ML are scooping up HUGE amounts of data, sometimes data that they shouldn’t.
The solution to restricting access to that system isn’t to completely rebuild it in some new model, the solution is to know why who, and what and has access and then manage that in from a practical, business needs process.
Integrate it into your Data Orchestration
Usually legacy systems exist for some sort of data input process that is difficult to change. Sometimes it’s a hardware thing that can’t be retired like old trunk lines managed by some giant conglomeration of other companies like in air travel or financial systems. Sometimes it’s regulatory and the system can only be modified with a heavy audit process. Sometimes it’s Mary in accounting who just refuses to change and we don’t want to make Mary angry.
But while the system needs to remain, and often remain as the source of truth for the data it’s producing, it doesn’t need to be an island. You need to understand what parts of your legacy data are duplicates that need to be updated from other sources (say, customer contact details need to be informed by Salesforce) and which parts need to inform OTHER systems (formulae for a specific deliverable).
This is all doable with triggers and incorporating functions with Apache Airflow (or even using Astronomer’s compute power with sidecars). While actual integration patterns may be a little different from system to system, they shouldn’t be substantially different. That is, your legacy system can trigger Airflow DAGs that become part of your big data pipeline just like modern, cloud native systems.
Retirement Should Be Graceful
By securing your legacy system with best practices and integrating it into your modern data workflows, the legacy system shouldn’t require a huge effort when it finally comes time to truly remove it from your enterprise.
By the time the vendor stops providing updates and patches, by the time the operating system no longer supports the dependencies your legacy application requires, by the time Mary has left the company and no one really knows how to use it anymore, the processes that the system managed are now part of other workflows, the data is now part of the enterprise data, slowly migrated to other systems, and other “sources of truth.”
I’m not saying you shouldn’t be considering retiring your legacy systems, but I am saying there are ways to maximize that original investment and actually leveraging it for the entire enterprise in a way that provides more value with less effort.
Legacy is not a dirty word, it’s an investment to be cherished.