I suspect that the real answer is that there are as many different reasons as there are decisions that are made, but certainly there seems to be a set of factors that the best organizations tend to consider when making the decision to replace an enterprise system.

I think you generally have to recognize the fact that the discussion likely won't even come up unless there is some issue with the system - some factor that leads to dissatisfaction with the current system. That initiating dissatisfaction tends to frame the discussion, and can color the weighting of the other factors that feed into the decision. Expense is one possible factor, but surprisingly that is often not the dissatisfaction factor that initiates the replacement discussion. Legacy system cost has generally been ongoing and relatively steady – it’s a pain that the organization is already used to. When cost is the initiating factor is generally because the cost suddenly changes, as during Y2K when the cost to retrofit legacy systems suddenly ballooned, initiating a great many replacement discussions. Often, the business wants to do something with their enterprise system that the legacy system cannot support: integration with other systems, customer web interfaces, real-time transaction processing, improved decision support, streamlined internal processes, transaction throughput, or overarching strategies such as reducing cost or supporting agility and flexibility – usually these reflect ways in which the business wants to change the way it operates, and the legacy system is a barrier to the new operational mode. The desired capabilities will then drive the discussion, since the discussion isn’t about the system per se, but the value of the new operation method as compared to the cost of changing the infrastructure (enterprise system) to support the new gains.

Enterprise systems by their nature tend to be expensive, so the discussion will inevitably include consideration of all the possible benefits to the enterprise, not just those that sparked the discussion. Since these systems also tend to have broad impact across many of the organization’s processes, the discussion needs to include all the possible costs and negative impacts, particularly any undesired changes to business processes that the new system might require. Remember that most of the gains from changing the system will be through changes to the organization’s business processes, so the organization must consider both the positive and negative changes that the system will impose.

Ideally the discussion is logical, performance based, and strategy driven, but political considerations are always going to be a significant factor. Politics isn’t necessarily a dirty word; politics is the mechanism by which an organization allocates limited resources among a variety of competing needs and opportunities. Where this can be an issue is that the influence an individual in the organization has on the political process is rarely directly proportional to the importance of the individuals official business function. Individuals with significantly more or less influence than justified by their business function will result in a skewed decision process. One strategy here is to be as inclusive as possible – make sure that as many voices as possible are included in the decision process; influence inequities will tend to cancel each other out when the decision process includes everyone.

To get back to the original question, the real sign that a system needs to be replaced comes down to an increasing number of customer requests to have the enterprise system do things it cannot do. The decision about when (immediately or on a schedule) depends on how quickly the desired capabilities are diverging from the system’s actual capabilities, and how much pain that divergence is causing the organization as a whole.

Thomas M. MacKay
Associate Director
Information Technology Services
Christopher Newport University

A very interesting question.

A few tongue-in-cheek answers:

1.Technical obsolescence – all the underlying technology is going away – probably the number 1 reason, my guess. Vendors, having made their money on the previous sale want to sell new product and announce sunset dates on the old ones.

2.Inability to cope with change – like a building with a bad floorplan, every re-model gets harder and harder, less elegant and takes more time. The well ordered code we started with is tied up in knots with point patching. And like a plane hitting the sound barrier with the progressive compression of air as it speeds forward, we create increasing complexity with every hasty change made to an existing system.

3.Unavailability of baseline specification and requirements and design documentation for further maintenance and improvements. Because of all the patch-ups, the original specification, requirements documents are woefully out of date and all systems understanding must come out of Baseline Change Request databases.

4.Unavailability of people with the right skills and experience to effect maintenance and improvements. See maintenance fatigue.

5.Perception that somehow, there must be something cheaper better faster out there. Whether this is based on hunch, or on solid analysis, the American way is to improve. Unfounded hunches become the basis for crusades of change and doing away with the old order.

6.Keeping up with the Jones’. The CEO comes back after listening to war stories from the competition and orders a sea-change – Now! Many CEOs have short attention spans and even shorter patience with obstacles presented to them. If CEO determination and resolve is all it took to eliminate legacy systems there wouldn’t be many left!

7.Maintenance Fatigue – The staff and organizations that have been maintaining the legacy system are tired and unenthusiastic. The choice of technologies in the as-built system is neither contemporary nor appealing and there are better jobs out there. For most programmers maintenance is usually a first job, and often perceived as a launching pad for another more interesting one.

8.Offshore Disaster - After the tired and unenthusiastic staff have been replaced by a young and inexperienced (but enthusiastic) team from India and the off-shoring is going south, many enterprises start over.

Yes, that legacy system is technically imperfect. But why do we think a new one will be better? What makes us believe that the new system will even match the old one? Especially taking into account that the old system will continue bring money while we are developing a new one. This means that the company will have to continue invest in enhancing the old system, which in its turn means that the new system will always be in catch up mode... So, what do we base our optimism on other than the enthusiasm of developers who want to get rid of old baggage?

I tend to say that systems die for business reasons, not technical. And they should. From this point of view technical obsolescence is not always a serious enough reason. Look at the number of old applications still running on mainframes. Yes, if a vendor doesn’t support the platform anymore, AND you lose your key staff, AND you have scalability issues, AND you need to enhance the system beyond what it was designed for then may be...

Another BUSINESS reason to consider a re-write is the amount of “pluck” that the system accumulated over the years. Every system deteriorates with time. Numerous bug fixes and enhancements, different hands with different development standards, different ideas – pluck has a tendency to accumulate. Every developer knows it. So, I find that the best litmus test is the face of your key developer who is responsible for the system after you asked him to implement an enhancement. If you look at the expression on his face you will know if it’s time to re-write.

Eugene Nizker

.. that this is hardly driven by hard economics or business case but rather emotions and lobbying..

A system is usually replaced when one of the following happens:

1. When a company starts branching out to new areas which are not handled by the current system.

2. A new Broom arrives in the comapany and informs the existing management that "the company can't go on like this" or that he\she can't be responsible for the old system performance.

3. A variation of #2, when someone on the board wakes up and demands a better report\control system.

4. when the support of the current system is lacking and there's a doubt about its life expectancy.

5. When the support is expensive and the company is looking to reduce expenses.