Reasons Why In Place Upgrades Are Bad

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.

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.