Rebuild Or Buy: The Decision To Scrap A System

A few weeks ago, I wrote about how replacing an existing system is a bad idea and refactoring is a better direction. In that post I said:

Generally, wholesale re-engineering of a system is a bad idea, because the system still serves a purpose and its’ functionality is a moving target. If the system does not serve a purpose, then what is the point of rewriting it?

The main reason that systems do get replaced regardless of the advice above is corporate politics. What I mean is that in some cases, the politics involved with continuing to maintain a maligned application are costly. The better political decision could be to start over and just replace the old system. This should not be seen as an easy decision, but there is one topic that must be discussed in this situation, sunk costs. Fred Wilson had a fantastic post about sunk costs earlier this week:

Sunk Costs are time and money (and other resources) you have already spent on a project, investment, or some other effort. They have been sunk into the effort and most likely you cannot get them back.

The important thing about sunk costs is when it comes time to make a decision about the project or investment, you should NOT factor in the sunk costs in that decision. You should treat them as gone already and make the decision based on what is in front of you in terms of costs and opportunities.

The moral of the story is, when looking to replace a system, do not consider sunk costs. Many people in management will use sunk costs as part of the argument of build vs. buy. Generally, sunk costs are irrelevant to the discussion. If you are deciding to replace an existing system, mentally you have already written off the costs of the system. So, using the money spent on the existing system as part of the costs of building a new system is disingenuous. To put it in even simpler terms, let’s say you have an old PC that is running slowly but you have not maintained it well. If you decide to buy a new PC, do you include the costs of the old PC? I know it is not a great analogy, but it is the same general idea.

Now, if you can compare the costs of just rebuilding the system vs the cost of buying the system while ignoring sunk costs, you are finally comparing apples to apples. However, given the topic of my recent post, I would like to add a third apple to the comparison. How much would it cost to refactor and enhance the existing system to match the features of the proposed systems? Disappointingly, most management teams will not consider this third option. “We are trying to get rid of the system, why would we throw more money at it?”

For many enterprise applications, the cost of the software and support is in the millions of dollars. So, if a purchased application will cost you $5 million, and you are willing to pay that amount, why not consider talking to the team about modifying the existing system? People will talk about the political problems, but if an application works well people will not care how it got built. The other option, rebuilding the system is almost always a bad choice. There is the thinking that the team will have learned from the effort of building the first system, so the second system will be so much better. What normally happens is that the system gets over-designed, complicated and bloated with tons of features in an attempt to ensure that you do not see the failure of the first system.

What option would you choose?

3 thoughts on “Rebuild Or Buy: The Decision To Scrap A System

  1. Ignoring sunk costs is basic management wisdom. But don’t throw the baby with the bath water : debugging any system takes effort and time – even when the system is the latest all-singing all-dancing shiny technology. An old system may embody the accumulated collective wisdom of all those who had to maintain it over the years. Most of that accumulated collective wisdom will probably not migrate to the new system – or you are a knowledge management guru. Be careful about wishing to start from scratch because you might actually have to do it and realize that a smoothly running system is about way more than just having all functionality pass the first user acceptance test.


    1. Jean-Marc,

      It may be basic management wisdom, but it is wisdom often forgotten (at least in my experience). There are issues with each potential choice as well. Even with “buy”, how much work goes into integration, and what features do you lose with the purchased system? Debugging does suck, but there is a lot of knowledge in the system. Nobody said it would be easy 🙂


Comments are closed.