I am working on compiling a list of reasons why in place upgrades of software and operating systems are a bad idea. There are many people that I work with that think that it is easier and better to just install the new version of a piece of software or an operating system on top of the old version. I, however, believe that this is generally a bad idea and that it is better to take the extra time to uninstall the previous version of a software item or perform a clean installation of the operating system. All of this is also contingent upon having a solid backup operation in place.

I would like to gather other thoughts that people have about in place versus clean installations.

  • What are the advantages and disadvantages of each in relation to both software and operating systems?
  • What types of problems have you run into and how did you resolve them for both software and operating systems?
  • Is there anything else that I should know of that I can share with my coworkers in relation to this topic?

Thank you in advance for your help with this. I look forward to hearing what all you have to share.

  • This post should probably be marked as community wiki...
    – voretaq7
    Jan 20, 2011 at 17:14
  • I think that this being a community wiki page sounds like an excellent idea.
    – John
    Jan 20, 2011 at 17:58

3 Answers 3


I would be surprised if any system administrator likes in-place upgrades. The simple truth is that they are not and can never be reliable. First you have to make the huge assumption that every software package initially installed on a system was packaged 100% correctly. This is never true. There are always packages with logic errors in them or that write to files they forget to mention in their package specfile. Writing package scripts is an incredibly unglamorous job, and is always assigned to the most junior developer on any software team.

Then, you have to assume that the host was correctly managed over time. Nobody ever went in and manually modified configuration or manually installed binaries that conflict with the packaged binaries. That never happens, right?

Remember that installing all these new packages means shutting down the old versions of the packages first. Package shutdown scripts are among the most poorly tested of all software. Nobody wants to deal with the incredibly boring and unthinkable case of their precious software package being deactivated and discarded. Plus there's a huge gotcha in this - shutting down packages which contain shared libraries means doing some very clever work to shut down packages which have those libraries loaded in to memory, or swapping running libraries in memory. That is extremely hard to get right.

Finally you have to assume that the people who produced the new release for the system thoroughly tested all possible combination of upgrades and not just the simplest case of upgrading the immediately previous version to this one. You have to believe that somehow they were able to devote the essentially infinite resources necessary to deal with every possible upgrade path.

As you can see, that is one giant (steaming) heap of assumptions. In practice none of those conditions are ever true. People install their own binaries on machines all the time. Package install and removal scripts are always buggy (I could write a whole dissertation on that one issue alone). The net result is that in-place upgrades are a fool's errand.

I should also note that my team performed a major OS and software upgrade of 7500 servers at my work last year. We tried so hard to make an in-place upgrade work but ultimately it just didn't, for many of the reasons listed above. We ended up wiping all the machines and installing the OS and all software from scratch. Problem solved.

All of this leads to my joke that the software release manager's mantra is Nuke it from orbit -- it's the only way to be sure. Completely wiping and reinstalling systems is the only sure path to success. You can get by with incremental upgrades most of the time, but eventually it's time to start fresh.


I can't say I'm a fan of in-place upgrades if given the choice, but there are times where it can make sense. All too often the answer in IT isn't one thing or the other but rather "It's not as easy as all that".

You have to balance the cost of doing an in-place upgrade vs. a fresh install and data import, with a realistic balance of both costing both approaches on a best and worst case scenario for each type of upgrade, and the chances of hitting a problem (some products are worse than others for in place upgrades and support staff from some companies will tell you that they support in place upgrades but prefer a clean install if possible). If you can tie software upgrades to hardware upgrades then this might help make the "clean install and migrate" path more attractive.

One case where in place upgrades are nearly always problematic is where you are attempting to fix a fault by upgrading to the latest version of a system. More often than not this causes problems somewhere down the line - at the end of the day you can't build on poor foundations. On the other hand a perfectly well set-up system with a good, well supported, and well tested upgrade path might be perfectly well suitable to an in place upgrade. Add in a lot of custom settings that are preserved in an in-place upgrade but lost in a migration and this is one case where the in place upgrade might be a much better option by far.

A few things to consider is that a fresh install and migrate approach might give you improved availability (depending on how smoothly the migration step can work, Microsoft Exchange handles this well for example) and certainly gives you a very good "rollback" strategy if you do have problems with the new version of a system.

  • Robert I think your point that this is a gray area is an excellent one. I should note that after the big clean & reinstall project we did over a year ago we've done several dozen major in-place software upgrades. I think you have to do clean installs at intervals, but in between you can defintely do in-place upgrades. Jan 20, 2011 at 20:40
  • 1
    @Phil As you say in your answer (great one, +1 and all that) its hard to be sure because of the unknown variables. That's the issue here I think and why its a grey area. It isn't a case of "it works" or "it doesn't work", its more a case of "its inconsistent" and that is every release manager and change manager's nightmare. I don't like inconsistent systems. I much prefer "It's a nightmare, but a known nightmare" to "I dunno"... don't you?
    – Rob Moir
    Jan 20, 2011 at 22:55

I agree with you when it comes to server OS in-place upgrades not being the best idea. But for workstations, I've done in place upgrades for XP>Vista>7. Even though it took longer, the user was happy to have everything the way it was.

As for software, if the installer provides an uninstall as part of the process, than there shouldn't be an issue there, as that's what its meant to do. Some apps are also ok with just installing the new version over the old.

You don't mention anything about what you are upgrading, the software types or OS. You should drop a little more info in there on the specifics.

At the end of the day, a blanket statement of saying all in-place upgrades of software or OS is bad, is like saying you don't use Automatic Updates because once, you had an update give you an issue.

  • I was originally thinking about MS Office 2007 to MS Office 2010 and also from Windows XP Pro to Windows 7 Pro.
    – John
    Jan 20, 2011 at 17:58
  • Dan see my answer for many reasons why in-place upgrades are extremely risky. Jan 20, 2011 at 20:13
  • I think we can make generalised statements like 'In-Place upgrades should generally be avoided'. Sure, exceptions. But boiling general approaches down like this is a useful thing to do. Otherwise you end up with analysis-paralysis at every decision. Jan 20, 2011 at 22:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .