How Do You Define A "Legacy" Application?



I had an interesting inquiry with a client that began with this question - "What is the defniition of a legacy application?"  Yikes, I thought - this will be one of those long-ranging, rhetorical discussions that - at the end of the day - lacks the kind of decisive answer clients typically seek during inquiries. The client actually had a good reason for wanting an externally published, formal definition - an external entity was attempting to measure the company's risk by quantifying its exposure to "legacy."

Why repeat the question here? It's not that I don't have published opinion on the matter - I've written a number of pieces on modernization options and defined the term for those purposes, and I get tons of inquiry around "legacy skills" and the how, whether and when to "modernize" legacy applications. Those conversations follow a familiar path, and tend to end up at these points of agreement:

  • The app was written some time ago, its original authors moved on taking knowledge with them (lost knowledge).
  • Subsequent authors changed the application based on insufficient / lost knowledge, introducing bugs and de-stabilizing it.
  • The app is now brittle, and people are reluctant to change it for fear of breaking it.

In the above context, note that the underlying technology that people usually use to define legacy (mainframe COBOL, iSeries AS400, VB 6.0) has little or nothing to do with the symptoms. In fact the the symptoms could describe 5 year old Java, C# or .Net applications just as well as a 30 year old COBOL application.

Past experiences have taught me why focusing wholly on technology as being the cause of "obsolete" can be problematic. In this case, I'd advised in a Webinar that PowerBuilder was a legacy language from which folks should move ahead. No offense to PowerBuilder - I could have cited many other languages as obsolete. In the Q&A section of the Webinar, one attendee asked - "But all of my applications are written in PowerBuilder."  Ooops, scratch that generic advice.

Clearly, my proclamation of "obsolete" required the context of this client's situation as a litmus test. Therefore, I submit that we can't rely (solely) on technology as an indicator. But we can't ignore technology either, because it can contribute to the desire to shed an application if:

  • App can't be extended due to the lack of / waning 3rd party vendor support - perhaps APL, PL/I, VB 6.0 are examples.
  • App won't scale based on deficiency in original technology choice - app written as a throw-together temporary app, now needs to scale to meet public-Internet traffic volumes and security protocols
  • Long-standing poor coding techniques, "patching it fast" rather than "doing it right" over a long period of years for example

A succinct definition of a "legacy application" is more difficult than it seems, but perhaps that's the point - this isn't a simple matter. Deciding the fate of an application needs more than over-simplified terms like "legacy."   Perhaps we should take more of a potfolio view, and replace the entire question with a more appropriate test such as "When is an application no longer suitable for the business?"

Now that I've presented my opinion above, I'd really like to hear from you folks in the blogosphere and the Twitterati - How do you define a legacy app?


re: How Do You Define A "Legacy" Application?

Phil, I'll go with your definitions. Given that, most Java/XML/.NET are legacy applications by the time they go into production.Why? The developers have not communicated and documented enough and now move on. The application is brittle from the outset because the coding has been a rush of quicky-bugfixes so that the project won't get canceled. The used APIs are already obsolete as the project has taken two to three years. The app won't scale because of lack of support for new technology and the old one is no longer available.On top of that the application is obsolete in terms of functionality but obviously change requests had to be refused to finish it. Doesn't anyone see that coding or extending business applications is a dead-end street that leads nowhere?BPM could be the answer would it not follow the same old idea of rigidly analyzed and planned processes. A new paradigm of user-driven, customer focused, architectured collaboration is needed. That is the only non-legacy future that I see!

re: How Do You Define A "Legacy" Application?

Thanks for your thoughtful reply Max. I really believe that application mining tools have the potential to alleviate many of the problems that our posts cite. Dynamic auto-discovery of assets and the inter-relationships between them forms a current-state base.The base isn't enough though - firms need a dynamic roadmap of the apps with advanced graphical visualization, search (where used) and other intra-application views to make developers more productive. Inter- and pan-application views suit management requirements for apps information - metrics about cost, and complexity for example. In combination, the two levels of information offer technical AND management folks a big step forward from manual methods.They are not currently a panacea mind you, but a big step in the right direction, and hopefully, they will continue to improve and link other valuable sources of information (projects, infrastructure, incident-reports, run-time stats, etc).

re: How Do You Define A "Legacy" Application?

Definitions are always difficult. Wittgenstein ask what is the definition of 'game' - almost impossible try it!I reckon legacy is "systems developed by those who went before us that we need to dump and develop properly!"

re: How Do You Define A "Legacy" Application?

For some Friday Fun in response to Bob Marsh's post:"Definitions are always difficult. Wittgenstein ask what is the definition of 'game' - almost impossible try it!"OK Bob, I'll bite.As a noun:A competitive recreational or sporting event between two or more individuals/groups (teams) where team members are tasked with reaching a common goal first (as in a race) or accumulating the most number of points (board game or sporting event) - often within a prescribed duration of time, while following a codified body of rules governing permissible behavior.Noun alternate definition:Quarry, prey (as in game-bird)As a verb:To manipulate the intent of rules such that they are subverted to one's favor (to game the system)More seriously - defining legacy as those apps we need to "dump and develop properly" assumes that all our "legacy" apps were badly designed/structured and are beyond redemption. I'd call those apps obsolete.

re: How Do You Define A "Legacy" Application?

A legacy app is any app that went into production before yesterday. Every "new" app gets the pejorative term "legacy" when it is deemed too complicated to interface, too expensive to manage and maintain, becomes difficult to change, and no longer meets the requirements of the requesting users. On second thought, using that criteria, an app becomes a legacy app the second the license agreement is signed, and you move from being a prospect to a customer.

re: How Do You Define A "Legacy" Application?

I like Michael Feathers' definition... Legacy code is code without tests. So simple and yet so right!

re: How Do You Define A "Legacy" Application?

In my opinion Legacy system can be defined as, a system which is having business importance but we dont know how to cope with irrespective of the language it has been written or platform it is running on or its age.