Legacy System Replacement

Its funny, when you tack the “legacy” adjective to a system it suddenly is something that must be replaced. However, like any other asset whether or not a legacy system should be replaced is determinable by a cost-benefit analysis. The following matrix is a good way to decide whether to replace a legacy system:

  High Business Benefit Low Business Value
High Quality Maintain Maintain
Low Quality Replace Scrap

If a legacy system is a high quality system then there is no need to replace it. This follows the old cliché: “don’t fix what isn’t broken”. If a system has low quality and low business benefit (measured by how many people use it and how vital it is to their job) then its better just to scrap the system and not replace it. The only place where it makes sense to replace a legacy system is when it has a high business benefit but is of low quality.

This was a question on my last exam, I felt it was worthwhile information.


Father, Husband, Software Developer, Podcaster, Blogger, Gamer, and the Future Leader of the Zombie Resistance. My thoughts are my own.

Tagged with: , ,
Posted in Software Engineering
One comment on “Legacy System Replacement
  1. eswarann says:

    The various challenges depending on the quadrant one chooses to go with are unique in themselves . See – http://eswarann.wordpress.com/2012/01/26/challenges-in-it-legacy-systems-transformation/

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: