Outdated Technology: When to Build New vs Refresh the Old

"If it ain't broke, don't fix it" is a common mantra when dealing with aging business applications. This attitude has merit, as upgrades and new systems require time and money. However, clinging to severely outdated technology for too long has major downsides, including accumulating technical debt and hampering workforce productivity.

Just how big of a problem is outdated technology to IT organizations today? MongoDB commissioned Forrester Consulting in a study they made available back in December 2022. They summarized some of the findings which I’ll highlight two here:

  • 57% of respondents said that their legacy technology was too expensive and doesn’t fulfill the requirements of modern applications.

  • 47% noted that their systems landscape struggled to handle the rate of change required to stay up to date with customer expectations.

That’s a lot of IT decision makers describing problems that they aren’t just theoretically going to face; they are dealing with them right now. The study broke down the concerns they are dealing with and what is holding them back and one of the biggest findings is that the rate of change and need for agility in data collection, security, and quality of that data is severely hampered by legacy systems.

In my experience, one of the ways we view legacy systems falls into two categories:

  1. Open systems with accessible APIs, but outdated front-end interfaces. The underlying logic still functions, but the user presentation layer is clunky and dated.

  2. Closed legacy systems with minimal API access or integration options. These rely on terminal emulation, green screens, and are generally unable to be tweaked for modern audience needs.

Closed Applications

Closed legacy systems generally require more extreme measures like RPA or complete redevelopment. The costs escalate given lack of accessible APIs and integration points. Closed systems may ultimately need to be rebuilt from the ground up using modern low-code tools or full-stack development or replaced with purchased off-the-shelf applications. Too often, I’ve seen one closed system replaced with yet another one.

Example 1

A client that I worked with a few years back was planning to sunset their legacy mainframe solution and my company was working with them one the time management solution. I was brought in to help them solve an application they had overlooked which managed the vacation bidding process for union workers at one of their facilities which the logic and execution was one via their mainframe. To keep the sunset schedule intact, I leveraged low-code to build an app in a matter of weeks that fulfilled the requirements and provided an improved experience through the UI. The full stack solution posed was estimated to take months and the developers were already busy working on the other applications impacted by the mainframe sunset, so rapid app development was able to come to the rescue.

Open Systems

Open systems present opportunities to refresh and extend UIs, workflows and reporting while leaving back-end functions intact. Low-code platforms can facilitate rapid front-end improvements to open legacy systems in weeks rather than waiting years for full replacements. Example upgrades include new mobile-friendly interfaces, AI-enhanced workflows, and intuitive role-based dashboards.

Example 2

We worked with one client to build a completely new front end to a risk management system (RMS) leveraging the Mendix platform. Their clients were happy with the features of the underlying RMS application, but very unsatisfied with the UI. Working together with some users and product owners, we designed a new interface and developed it in months over the years quoted to them previously.

Outdated technology takes a toll on diminished workforce productivity, complex vendor relations, and lack of agility. Users accustomed to consumer tech such as smartphones feel hampered by cryptic interfaces. However, these issues are low on the spectrum of why a business decides to deal with outdated systems.

What drives change these days is concern around the safety and quality of the data in these systems. Clunky interfaces can lead to errors and generate data inconsistencies. The lack of modernization limits the reach and coverage to those interfaces instead of mobile alternatives or cloud-native approaches hosted globally. In a future post, I’ll break these concerns down into how building applications helps address these concerns.

Regular incremental improvements using low-code can maximize legacy system lifespan at reasonable cost. However, legacy apps that cannot be cost-effectively upgraded will ultimately need replacement. The key is balancing targeted upgrades while budgeting time and dollars for new systems where entirely necessary. With proactive management, technical debt remains manageable, and low-code, while not a platform to solve every problem, is a valuable tool in the IT toolbox for modernizing these legacy applications. Maybe it really does need ‘fixed’ after all.