Coming to terms with legacy tech

Last month, I finished a seven episode podcast series from Compiler by Red Hat about legacy technology and the challenges that IT professionals face when dealing with older hardware and software. It was an incredible journey, and I learned a lot. I’m still thinking about it seven weeks later.

Some of the stories, facts, and scenarios discussed in the series were eye-opening. For example:

  • One man inherited a manufacturing business from his late father. The machines ran on an archaic operating system that did not have documentation, and the guy had to hire a consultant to figure out the operating system to bring the facility back to life. Needless to say, the project involved a lot of troubleshooting and forensics on the consultant’s part.
  • A university owned a laser cutting machine that could only run on…Windows XP. The laser cutter cost several thousand dollars, so it didn’t make sense to scrap it. The device was a security risk from a network standpoint, but it still needed to be supported and maintained. The IT department had to figure out how to support and secure a key device that students had access to.
  • Hadoop ushered in the era of what we now know as data science by providing a way to store lots of unstructured data. It enabled growing platforms like Facebook to store gobs of data on user activity, but it didn’t provide easy mechanisms to work with that data. The early mindset around data was “collect it all and we’ll make sense of it later.” But data storage gets expensive at the terabyte and petabyte level, and now many companies have moved to a more considered approach of determining the end goal for data analysis before collecting a bunch of data. It was fascinating to learn how Hadoop was a boom and bust in the business world that impacts today.
  • Pretty much every data-intensive process you can imagine, from millions of simultaneous banking transactions to flight booking to taxes all runs through COBOL, which is a programming language from the 1960s. It’s hard to modernize something that powers so much critical infrastructure, especially when scheduling downtime is not an option.

Key Takeaways

I left the series with an understanding of some fundamental facts about dealing with technology in the workplace:

  1. Legacy technology is everywhere, and it’s pretty much a given that you’ll encounter it in some capacity if your job intersects with IT in any way shape or form.
  2. Contemporary computer science programs and boot camps don’t really prepare grads for the realities of IT work. They like to teach the latest and greatest—the flashy frameworks and darling languages that are hip for the day. They don’t always teach the legacy stuff, which puts students at a disadvantage when entering the workforce because most organizations are not working with the latest and greatest.
  3. Old doesn’t mean bad, even for technology. There can be this false impression that newer is always better, but that’s not always the case.
  4. Just because something can be modernized, it doesn’t mean that it should be modernized. There can be lots of reasons for not modernizing systems including but not limited to: budget, migration, costs, and human factors. If something is working, and it doesn’t pose a security risk, then it probably should be left alone.
  5. Legacy technology provides an opportunity to learn the fundamentals. Old tech is the backbone for new tech, whether hardware or software.
  6. No one has a clear definition of what legacy technology is. In common usage, “legacy” seems to mean “technology that’s older than I would like it to be and it’s kind of frustrating.”
  7. The faster you learn to adapt and live with legacy technology in your work, the better.

In my day-to-day work, I encounter many of the frustrations related to working with legacy tech described in the series. Systems don’t always talk to each other. Maybe there’s certain hardware that would be nice to upgrade (or purchase outright), but it can’t happen right now. Historical decisions regarding software and tooling make the prospect of migrating to a different system fraught with complications. The list goes on.

Although moving to a new platform might provide long-term benefits, it’s not always easy to make a change. Budgets have to be considered. Stakeholders and end-users have to be considered, which means that any modernization efforts require stakeholder alignment across multiple fronts.

Change is not always easy—even if it’s for the best.

The reality is that change may not be necessary right now, even if it’s for the best. So work with what you have, push for upgrades and system updates as much as possible, and most importantly, make sure that your recommendations reflect the actual needs and goals of your organization.

Ultimately, the question isn’t “How can we update and modernize our hardware and software?” but rather, “What makes sense for us?”

And therein is the biggest takeaway from the series: Relax—these situations are normal. You don’t need to flip a switch and modernize everything. Recognize that the best thing to do might be to leave the old systems in place. The key is to zoom out and look at the entire context. Get curious. Figure out how the legacy tech impacts operations, learn as much as you can, and if/when it’s time to upgrade, you’ll be able to move forward with confidence.

Further Listening + Reading


Image: Bliss, default background image for Microsoft Windows XP, used with permission from Microsoft

Scroll to Top