Joel Spolsky said in one of his famous posts:

The single worst strategic mistake that any software company can make: rewrite the code from scratch.

Chad Fowler wrote:

You’ve seen the videos, the weblog posts and the hype, and you’ve decided you’re going to re-implement your product in Rails (or Java, or .NET, or Erlang, etc.).

Beware. This is a longer, harder, more failure-prone path than you expect.

Have you ever been involved in a BIG Rewrite?
I'm interested in your experience about this tragic topic, and in particular, in any big rewrite that was completed succesfully (if any).

  • What is your threshold for BIG?
    – rwong
    Nov 15, 2010 at 3:15
  • A project that is consolidated during many years; ie not a project that can be rewrited in one month. Nov 15, 2010 at 7:35
  • :) That can be anything. What someone fresh out of college without any experience can do in several months to a year is quite different than what someone with a decade or more of hard earned experience can do. Apr 6, 2011 at 12:32
  • Mozilla successfully transitioned addons.mozilla.org from CakePHP to Django. There's a talk describing this big rewrite (DjangoCon 2010 Switching addons.mozilla.org from CakePHP to Django), but the TL:DR version is that they switched one URL at a time.
    – user16764
    Mar 2, 2014 at 20:25
  • The counterpoint to Joel is Fred Brook's seminal book "Mythical Man Month". In his essay on pilot systems he asserts you will throw away one system, so you might as well plan for the event. In effect there will be at least one rewrite, likely two as the "most danger" in Brook's eyes is in the second system where all earlier foregone flourishes and features are lumped on.
    – EBarr
    Jun 19, 2014 at 2:18

13 Answers 13


I've been involved in a few rewrites over my career and they were all disasters. I think they all fail for the same reasons

  • Vast underestimate of effort required: Every time someone wants a rewrite, it's because the old system is using old technology and difficult to maintain. What they fail to consider is that because of it's age, it may have 30-40 man years of development effort into it. Thinking you can then rewrite the whole thing in 6 months with a team of 5 is silly.
  • Lost knowledge: The old system has been around so long, it does a lot of stuff, and is hooked into everything. There is no up-to-date documentation, and no single point of authority that actually knows all the things the system does. There will be pieces of knowledge with particular users in particular departments, and finding them all is difficult or impossible.
  • Poor Management Decisions: The rewrites I've been involved in had a similar expectations from management: The new system should be 'done', and the old system could simply be turned off on a particular date, period. No other option was acceptable. I think they get this in their head, because they are spending all this money to hire new people for this huge project. In reality, the better risk mitigation strategy is to rewrite the major functions of the old system, say tackle 50-75% of the old system for a first release, and then see how it works! Because of #1 and #2 above, this would probably work out much better, as we find out some of the features that were missed, and what's needed to actually turn off the old system.

Rewrites can be very successful if you scope them correctly. I don't know if these meet your threshold of "BIG" (TM) projects, but let me describe to you a couple of the more successful rewrites.

Project 1

The company I worked for had a shelf strip printing system used to generate the labels you see on retail shelves from something called a planogram. The planogram was generated in industry standard software and our tools read that document to create the shelf strips using a template for the target store. The templating software was a mess with nested finite state machines that spanned several classes and 3 DLLs. When the time came to implement the (then) patent pending approach to do peg boards it was clear the current code could not support what we wanted to do.

Solution: We scoped the rewrite to just the template engine. We used proper OO design to take care of the current requirements, as well as address the new peg board requirements. Time for the rewrite was 1 month. If we did a whole-scale rewrite of the whole tool chain it would have taken well over a year--but we didn't need to do that.

Project 2

A web application our team built from the ground up was starting to outgrow its original design. Our client also had a suite of new requirements that would make the site a lot better for our users, more "Web 2.0" compliant if you will. While we could have shoe-horned our existing design into framework we currently had, maintenance was a nightmare. We knew the application intimately, and we knew which parts we had to bring forward and which parts were going away as part of the new version.

Solution: It took our team 3 months to complete--it was not trivial. The end product was faster, more scalable, and more enjoyable for the end users. We surpassed our client's expectations. That said, we had to split our team up so that the more immediate bug fixes and band-aid patches would get done on the existing system while the other half worked on the new system. We had extensive testing in place, and incorporated early in the process. The reason this worked out so well is because we intimately knew this application and our client.

Project 3

I have to include a failure here. We were supporting a client who needed an information management tool for use in disaster/crisis situations. We inherited a Java Swing application that the original developers wrote without truly understanding Swing. By that I mean that they did not follow Sun's recommendations for dealing with Swing and managing the UI properly, as a result you would get into infinite event loops and other strange and hard to track issues. As a result it was laden with bugs, user interface problems, etc. This was a very complicated application. In order to preserve our sanity, we attempted to rewrite the poorly written Swing app into a well written Swing app.

Solution: We completed the rewrite in about 4.5 months when we estimated 3 months. The application performed better, both in the UI and in how much data it could handle. Then the tsunami in 2004 happened. The sheer magnitude of the number of people they had to track demonstrated that Swing was the wrong technology for what they really needed. We couldn't keep up with our performance tuning, and they eventually abandoned the tool in favor of a cobbled together web app created by the Oracle team they had in house. Sure we could justify what we did based on the knowledge we had at the time, but the rewrite wasn't aggressive enough, and we failed to tell our client that their requirements for the number of people that could possibly need to be tracked were too low.


Rewrites are sometimes necessary, and they can be completed successfully if you plan it correctly. You can get further with targeted rewrites for portions of a system than you can for whole-sale rewrites. Finally, what causes a project to fail isn't necessarily the rewrite itself. While we can never be clairvoyant, we can come up with some worst case scenarios. I've learned to design my systems to support twice the worst case scenario I can think of. In the case with the crisis management system, that wasn't enough--the actual numbers were 20 times the worst case scenario we were given. But that wasn't the worst case scenario we could think of.

  • Rewrites for the sake of rewrites are not your friend. There is always a lot of complexity you don't see, and you'll find that the ugly things you see are training tools for your client. Always show your current progress to your client at regular intervals so that they can help you catch the worst offenses.
  • Targeted rewrites are useful to deal with the worst offenses in your code base. Don't do a whole rewrite if you can limit the scope and address the majority of your problems.

I've been involved with several rewrites that were from VB6 to .NET. In 2 cases the rewrites went smoothly and we were actually finished ahead of schedule. The other rewrite did take longer than expected but completed without any major issues.

In our particular case rewritting was NOT the worst decision that our company could make. The end results were actually much more stable than the originals and put us in a much better place.

  • I wouldn't call that a rewrite... more like an upgrade.. unless you converted the code to C# or something. Did you actually start from scratch on the new code?
    – Jay
    Sep 22, 2010 at 13:27
  • 4
    @Jay - They were all rewrites, no conversion. We took the opportunity to redesign all three apps. I don't see any value in a straight conversion if you don't address the short-comings of the existing system. In our case that was starting from scratch.
    – Walter
    Sep 22, 2010 at 15:17
  • How big were they? How many lines of code in original system, how many person-months did the rewrite take?
    – MarkJ
    Feb 7, 2012 at 11:59

One of the biggest traps when doing a complete rewrite of an existing system is to think "We don't need to specify what the new system has to do - it's very simple, it just has to do exactly what the old system does!".

The problem is that most likely nobody exactly knows what the old system does, and you'll spend countless hours on making your new system work according to the way that different users of the old system think it should work. The original requirements of the old system are also most likely not available.

  • 1
    I can attest to this. It's OK to use a working copy of the old system as an input to a requirements doc. But then the customer must sign off on that doc, not some vague notion of the old system. Aug 11, 2015 at 7:11

Mine is a "success" story. My project involved a primary site with 4 independently managed/written satellite sites (subdomains with different applications on them). We had 4 primary user bases (all within separate active directories) and none had a common authentication system. 3 were well-established and silo'd applications and the 4th satellite was brand new and had copied much of it's code base from our most established site.

Goal: Implement an enterprise wide identity system that could authenticate accounts across 4 domains and full manage (with self-service) accounts in 1 of the domains. Because .Net was already implemented on the satellites, the classic asp site that served as the "lead-in" would need to be rewritten, identity management added in, and all sites would need regression testing to make sure no services were impacted.

Resources: 3 primary architects - programmer, identity management, project manager. Approximately 20 developers, 10 analysts, 10 testers.

Time to completion (start to finish): 1.5 years

Launch Success: Near Failure

Longevity Success: Terrific

I was the identity management architect, so I designed the databases, subsystems and logical interfaces by which all of the satellites would interact. The "programmer" architect was a lead developer with extensive business knowledge of all of the satellites and experience with the applications and their development up to that point.

After several months of requirements gathering with 50 or so different people from various departments in our corporation, we managed to get the logical architecture ironed out and started banging out code. Because of the nature of the change, we had to rewrite our own website and all of the functionality that it contained into .Net. In some cases it was just a matter of refactoring. In many cases it involved a complete rewrite of the processes surrounding it. In 2 cases we simply abandoned the original feature as not important. We missed 2 deadlines in the process (but ended up hitting the original deadline I had proposed - barely). On launch day nothing worked. We launched on a Saturday so the impact was fairly minimal, but I spent the entire day combing through logs, rewriting pieces and evaluating server loads. More testing might have helped. A more complete SDLC might have helped even more (we had an SDLC, but it was mixed).

By the end of the first day, all of the sites were up and running and everything was working (I would say a nominal success). Over the course of the last 2.5 years everything has been a terrific success. Having all of our sites on a common architecture with a common framework base has made development and cross-developer work much easier. Features I wrote into our site 2.5 years ago (during our rewrite) have since been seen/adopted by a couple of the satellite silos.

We have increased logging, user tracking, increased up-time, a singular application responsible for authentication/authorization/identification. The satellite silos can focus on their applications entirely and can trust that any authentication/authorization problems exist with the identity management application.

Our project was a lot of frustration, heartache and disasters. In the end it has paid off and then some. I am 100% in agreement with Joel Spolsky's assessment of rewrites as a general rule, but there are always exceptions. If you're considering a rewrite, you just need to make sure it's absolutely what you need. If it is, then be prepared for all of the aches that come with it.


I'm involved in a huge code rewrite now... the only problem is I'm the only one working on it! The maintenance costs of our current software is outrageous, it has a lot of bugs, and we have 1 FT employee maintaining it so we decided to build our own.

Its much slower then I expected it to be but ultimately I think it will be so much better because we'll have our own codebase so any changes they want in the future can easily be implemented (the software needs to change frequently to keep up with current times). Also we're making some major changes to the design while we rewrite it.

  • I'm in the same boat at my current client - except I'm wearing the "full timer" hat. Maintaining the existing Access application while finishing the rewrite of the "new" .NET replacement which I've taken over from previous developers. It's not straightforward/easy and constant unforeseen problems causes it to take a lot more time than everyone expects. Sep 22, 2010 at 15:40
  • 5
    when you are done, please update your answer with "I expected it to go like this, but it went like that" to help others do more realistic estimates.
    – user1249
    Apr 2, 2011 at 18:11
  • 1
    @Thor Sure, but you may be waiting a while. There is a lot more to the application then I ever anticipated (security, compliance, etc) and trying to build something WELL instead of just building something is taking more time than I thought.
    – Rachel
    Apr 3, 2011 at 16:10
  • sounds like you already have additional horrorstories to share :)
    – user1249
    Apr 3, 2011 at 17:41
  • 12
    @MarkJ Sadly the project got cancelled after a year or so because the company did not want to spend the money and resources to keep building it. I guess they thought we were joking when we told them it would take about 5 years with one part-time programmer working on it... I was very disappointed, but I did learn a lot and I feel it made me a better programmer overall.
    – Rachel
    Mar 28, 2012 at 20:15

I took part in a complete rewrite in my previous job. And we were very happy to have done so. Let's just say that sometimes the codebase is so rotten that it's better to start again.

It was an internal application - the main business application, in fact.

We maintained the old system as we wrote version 2. If I recall correctly, it took us about a year (two programmers, and then a third). We didn't need to touch the database though, so at least data migration wasn't an issue.

  • Care to share why the old version was too bad to remedy? Did you change platform?
    – user1249
    Apr 3, 2011 at 18:43
  • 1
    We changed databases (SQL Anywhere 6 to MS SQL Server 7), but the main driver was that the application had been written almost entirely using the worst way to write Delphi: all the model and controller logic in the views, 500-line triple-nested loops, etc etc. It was a mess, we couldn't see how to even start unmessing it, and we were changing databases anyway. Apr 3, 2011 at 20:15

It all depends. In my case I followed Joel Spolsky's advice and I was wrong. It was about an Insurance Website. The site was horrible and here's what I did, then what I should have done:

Bad strategy: I supervised a group of 4 students to:

  • Student #1 - rewrote the database access/queries to make them safe
  • Student #2 - moved all the css "up"
  • Student #3 - made all the pages w3c compatible
  • Student #4 - solved all pending bugs
  • Myself: removed all php warnings and crappy stuff (duplicate code and so on)

It took 2 months. Then we re-designed the site. Then we did it multilanguage. All in all we had to keep large portion of crappy code and the database structure stayed the same. So I'm still being working on crappy stuff for one year now and it will never be finished until we decide a complete rewrite, which will never happen actually.

Good strategy:

  • Study the whole site, make a good "Product requirements document".
  • Re-design properly the database
  • Start from scratch with my own framework (which already works)
  • Re-designed the site.
  • Do multilanguage.

Time it would have taken: two months (maybe less).

  • Good code.
  • Good maintenance.
  • Productivity.
  • No answers like "we can't do this, the Website can't handle such products".

So, my final words: it all depends on the complexity of the stuff you have to rewrite.

Don't hesitate to correct my post to make it proper English please, thank you very much

Olivier Pons

  • If the project took 2 months I wouldn't consider it a "BIG" rewrite. Especially with a team of only 5 people on it. Apr 6, 2011 at 11:28
  • You're right in a sense. I just thought "BIG" was closer to "FULL" rewrite than "> 2-4 people working on it". Do you think my post is useless? If so I'll remove it. Thanks. Apr 6, 2011 at 11:33
  • No I don't think it's useless at all. You raise several decent points. I only wanted to make my comment because the problems experienced on a small scale are very different from the problems seen at a very large scale. In my answer I consider the rewrite of medium scale. Apr 6, 2011 at 11:51
  • @Joel: ok I've read your answer, this is not the same "problem" at all. Once again it all depends on the case. By the way I've translated a few years ago the whole Joel's article in French (on my personal blog) ;) Apr 6, 2011 at 16:06
  • 4
    @OlivierPons I'm not sure that comparing what you actually did against what you think you could have done is a fair comparison... Aug 10, 2012 at 14:03

A company I worked for started a major refactor of the codebase.

Half the team was set to work on the refactor, and the other half continuing to maintain and improve the existing product.

As you can imagine, the refactor never really came to a point where anything worked - it was just a constant on-going process that didn't really ever have anything to show for itself.

The idea was that the refactored codebase would be better to work with and we could just "drop in" in the new features the team had added to the existing product afterit was done, and "catch up".

But it ended up being the company's downfall.


I've been on a big rewrite for the last 3 years. Original we estimated the project to take 2 years. The basic idea was to replace the hardware, use an existing OS, rewrite the business logic (from c to CPP), create a new IO card and write a new UI.

Along the way we made some terrible decisions. We had no real experience in CPP and no mentor to teach it well. We tried building a UI framework ourself based on win32. The hardware was cheap and the BSP flawed with bugs. The software was super flexible but hard to maintain. Last year we threw out the home grown UI and developed a UI in .net. We also completely rewrote our persistence mechanism and data communication protocol.

It took a lot of extra effort, but now the project is almost finished and the first units are tested in the field. The project had way to much risk to have any change of being successful. There were some positive things about the project, we started using SVN (instead of VSS), we took time to write unit tests and implemented a nightly build. We also started using scrum to have a better process.

In retrospect i think the rewrite of the business logic was not necessary, we should only have re-factored the most ugly parts. And for writing a UI from scratch don't do it unless it is your core business.


Actually I am starting a big refactoring. 4MLocs probably should be downsizing to 800KLocs or less. This project has a lot of Copy&Paste, misunderstanding language features, lots and lots of repetitive useless comments, poor decisions, temporary hacking and more hacking turned permanent (including workarounds), complete lack of knowledge on basic principles on Computer Science or Software Engineering. Probably maintenance team of 32 bad programmers will be replaced by 2 good ones after refactoring.

  • I'm curious to hear a follow-up to what happened on this. Did it succeed? What did you learn along the way? Or where are things now, if it's unfinished? Jan 3, 2019 at 0:44

I wrote a blogging engine in 3 weeks. I rewrote it in 8 hours.

Planning ahead is key to a successful rewrite. Knowing the system inside and out it also a benefit.

  • 5
    Would you consider a 3 week project a large project? Sep 22, 2010 at 14:52
  • @John: No, I wouldn't say it's large, however I'm pointing out the time difference between writing something and adding pieces on-the-fly, vs. re-writing with a solid plan. I rewrote an entire management system in 3 weeks that originally took about 8 months to put together. Again, a solid plan and direction is what you need.
    – Josh K
    Sep 22, 2010 at 21:01
  • Having an existing version (with or without source code, but one which you can tinker with freely) definitely helps the rewriting effort. More is better.
    – rwong
    Nov 15, 2010 at 3:20
  • To be precise, you implemented a prototype blogging engine in 3 weeks.
    – user1249
    Apr 3, 2011 at 18:42
  • @Thorb: Sure, I guess that could be said.
    – Josh K
    Apr 3, 2011 at 19:07

A bit more than a decade ago, I've worked for a company which decided to do a "redesign" of their aging core product. Since then, mentioning the word "redesign" is a punishable offense. It took much longer than expected, obviously costed more, and the new product was much more similiar to the old product than initially planned.

Not the answer you're looking for? Browse other questions tagged or ask your own question.