When to rewrite vs. upgrade?

Question

All custom legacy software needs changing, or so say our users. Sometimes they want a feature or two added and all that is necessary to change a bit of code, add a control, or some other minor upgrade task. Sometimes they want to ditch their error-prone VB5 desktop solution and rewrite the whole thing as a rich Web 2.0 ASP.NET MVC application. More often, however, the scope of changes to legacy functionality lies somewhere between these two extremes.

What rules of thumb to you use to decide whether you should upgrade an existing application or start from scratch?

Answer 1

This will sound cliche, BUT, go for standard cost/benefit analysis:

1. Take the cost of resources for the re-write (REALISTIC cost - meaning multiply your estimate by 3-5 times). This includes possibly needing to train other developers on your new chosen architecture/tools, AND the cost of re-training the users.

2. Take the resource cost from hard-to-implement changes anticipated in the next N months (based on your experience) - only counting the marginal cost (meaning, if the cost of a change in VB5 app is 1 week and the cost of that same feature to implement in rich Web 2.0 ASP.NET MVC application is 3 days, you count it as 2 days of savings). Add in projected benefit from new features the web 2.0 app will provide the users that VB5 app can not provide at all.

If the former is less than the latter, go for a re-write.

Answer 2

Generally I'd say that if the resources (time, money, developers etc) required to add the feature are more than it would take to re-write, then re-write.

You need to add some bias, for instance re-writing the application might also result in reduced support costs in the future as many of the bugs will be removed as part of the implementation, but there will also be issues when writing a new application (training, small bugs that make their way into the finished product, random debugging messageboxes or rubbish like that).

Answer 3

I don't have a rule handy to decide that, but I suggest reading Things You Should Never Do, Part I, where Joel Spolsky writes about single worst strategic mistake a company can make.

That said, we completely rewrote an application for a customer, and it was the right thing to do, since it's now more reliable, faster, has more features and is more beautiful than the old one ever was. Extending the old application (which has gained a lot of features over the years that were just somehow hacked in) would have been more expensive in the long term, since it's a living application, getting additional features once or twice a year.

Answer 4

I try to avoid a re-write at all costs - sometimes they're necessary, but they're always significantly more trouble than initially expected, and they tend to re-introduce bugs that have long since been squashed in the legacy version.

If the business requires that you add features that the current platform doesn't support, it may seem like don't have any other option except to re-write, but consider your other choices - can you add the functionality another way? A report or small webpart on your intranet? Automatic emails? Some kind of web service that goes against the database? There are a number of ways that you can add functionality without completely scrapping what's there and accepting all the risks that are involved.

From the business perspective, it's cost vs. benefit. If you're adding a single feature, it's dev time vs. benefit of the feature. However, if they want a single new feature that requires a rewrite, suddenly the 8 hour feature becomes an 800 hour feature (be realistic when you estimate the development time for the rewrite - "I'll do it in the next week" isn't often realistic), and the business may no longer be able to justify the development time. Make sure the cost is justified by the benefit.