It is recognized in the world—in business and Information Technology (IT), that “Legacy” applications (anything Legacy) are a drag on the companies (#). The functionality that these “systems” provide to users is often incomplete, more expensive than necessary, challenging to use, and just cumbersome. Unfortunately, frequently the users as well as developers, get used to and comfortable with them! And this reinforces the resistance to change.

Is believed that the IT departments of many organizations (the focus of these writings) are expending the bulk of their budgets--some report up to 80% (#), on software maintenance activities that provide relatively little value.

Instead of investing at least some time (10-20%)--as some progressive companies do (#), in modernizing the code that would reduce, simplify and eliminate future maintenance activities. Time and resources should be provided, as ‘Maintenance,' to fix errors, streamline the systems, and provide enhancements or additional functionality.

Legacy – What is it?

Legacy is one of these terms used with varied meanings. Even Legacy IT (as mentioned, the subject of these writings) is somewhat differently defined and understood. A basic definition I want to use is that Legacy IT is the use of information systems (and at some levels infrastructure), that is to a certain degree, or have some elements of it, outdated, antiquated and even obsolete.

I am identifying or defining Legacy IT by classifying various areas: Architecture (Systems), Hardware and Software technology, Operating System and Tools, Data Structures, Databases, and File Systems, Applications (ERPs, etc., Software Package or "Home Grown"), Program Code, Procedures and Norms, Standards, etc. We could also include organizational structures (#).

For example, an organizational structure could be outdated for today’s needs. Maybe a flatter structure is needed.

In System Architecture—the hardware, interconnections, etc. could also be Legacy. Could be using slow routers, modems, switches—inappropriate Ethernet and Internet and still using Coax or lousy TCP/IP address, and so on and maybe having cloud connectivity issues.

The hardware could be old and unsupported. Or not having enough resources—CPUs, Memory, etc. Early operating systems can't easily be upgraded because of the old hardware. Old, outdated tools (like utilities and developer tools, programming languages, etc.).

Data still residing on what we call 'Flat' file, with fields defined in the program. Even when using a modern Relational Database Management system (RDBM), many applications still operated and working as a 'flat-file. With limited data structures and missing out in the use of advances and features of Relational DataBase Management systems (RDBM) already in place.

Having applications designs or based on Batch processing, with limited On-line processing. Application Systems consisting of large, complex, monolithic programs—making it very hard to understand and modify. Still using old, outdated programming languages and having rigid or inexistent standards and norms. The list goes on and on.

We are further concentrating here on the AS400 platform (AS/400, iSeries, System i – or however you recognize it as), which enjoys the dubious reputation (quite falsely) of being 'legacy', both in Hardware and Software. When, in fact, it is often (the AS400, etc.) where the "System-of-Record" or critical data resides (#).

An expensive and wasteful practice

Maintaining and enhancing these legacy systems, even though many are handling ‘mission-critical’ applications, is costly and unproductive (#). Adapting them to better respond to customer needs is sometimes impossible or economically feasible. 

These expended efforts, both of the IT users—and the IT resources, are frequently expensive and harm the final users, customers, and partners. As mentioned, users, as well as developers, tend to get "comfortable" with them, and this inertia prevents needed improvements.

I can often picture it if you will, like walking through a swamp, where each step requires lots of effort that slows you and gets you messier, instead of making an effort to seek dry land and make good progress. You may never get where you want to or be too late, or is too expensive!

These legacy applications we are referring to are mostly those on Mainframes and Mid-Ranges, where the development was started decades ago, with tools and techniques oftentimes that have nothing to do with today's development tools; using old, cumbersome programming languages.

Many are employing less useful and less productive tools that unnecessarily tax the developers and result in longer and less effective outcomes for their users, with most using obsolete data/file structures instead of taking advantage of modern and powerful Databases.

We also see this with Mainframes (or “Big Iron”) and with distributes systems—Windows, Linux/Unix, with additional burden when multiple systems architectures are interconnected (Very common).

But we know that legacy applications (etc.) works and sometimes very well, no doubt about that, and are still working; and usually mostly have been maintained by following old, outdated practices and tools--even though better tools have been readily available.

We know they are running mission-critical applications! But IT Systems need to be nimble, agile to adapt to today's, always changing, customer needs. And flexible to stay ahead of the competition.

We have the wisdom, experience, and knowledge to make it right.

Note: ‘#’ will be replaced with references to other sources.