The curse of replacement projects

I was at a Meetup the other day with Eric Evans. I liked the talk even if it was very similar to the one he gave at the last JavaZone. Eric makes the same point as I do in respect to replacement projects. They are more expensive than you think and have a high risk of failure. Even those that succeed often fail to produce more than nominal value. The project barely manages to produce a new system on a new platform that does the same things as the old one did. Eric’s advice in the face of these obstacles is to avoid replacement projects completely. Why start something that is bound to either fail or provide minimal value? But is this the right conclusion? I do not think so.

Eric is half right

Many replacement projects are started for the wrong reasons. People seem to make up these reasons more as rationalizations than as real arguments. They will also base their decisions on impossibly optimistic estimates of the costs involved. These projects should be converted into enhancement projects that build on the legacy system in an intelligent way.

Eric is half wrong

But there are also many replacement projects that are necessary. The reasons vary but one stands out in my experience: a core architectural design parameter has been invalidated since the system was built. Two common examples of obsolete design parameters are:

In these kinds of situations it can be exceedingly difficult to align the system with the way one wants to do business. The system becomes a constraint that prevents the business from exploiting new possibilities. Customers start to notice that you are operating in an outdated manner: “You will have to wait until tomorrow before your changes will be visible”, “Describe your problem in 200 characters”.

An alternative approach

The interesting question to ask is “How do you plan a replacement project so that it stands a chance of succeeding?”. The answer is in the strategy you use. The core mistake most replacement projects make is that they try to replace the legacy system in a “big bang” style. This leads to a “at least as good as the old system” mentality. Scope is contingent on an unknown quantity, the full feature set of the legacy system. In addition, the project has no way of getting real feedback since nothing is released before “everything” is completed.

There are two general approaches (and an infinite number of combinations of these) that are far superior to the big bang approach:

There are many possible ways to pursue these approaches. Each legacy system provides a unique context that heavily influences how you should tackle the problem. The Agile Release Strategy wiki describes a large number of possible approaches together with their inherent strengths and weaknesses.

The hard truth

There are some core truths that you must face if you want to succeed with a replacement project:

Replacement projects are hard, but with the right strategy you can lower the risk of failure to an acceptable level.

Posted on 2010.01.26 at 21:01

Comments are off for this post.


About Niklas

Born in Sweden, grew up in New York, lives in Norway. Yes, I have problems with identity, but I do think that my background helps me see things from a different perspective.

Read more