We’re close to end of life on certain common operating systems, so naturally, upgrading has been a frequent topic lately. However, when we say “upgrade the OS,” we actually mean migration. This is for a few reasons.
Your Current OS Has Baggage
The number-one reason not to do an in-place upgrade of your operating system is the baggage that former OS had. When I say “baggage,” I mean old drivers, old desktop profiles, uninstall files of the previous OS patches, not to mention any file changes, registry changes or bugs that were from the previous install.
The Baggage is Full of Space Wasters
Most likely after the re-install, the new OS’s drivers will take over and replace the old ones anyway, but now the old, unnecessary drivers are left behind taking up space and potentially creating confusion in the future. If you’ve ever worked in a decent sized company, you’ll know that the profiles that accumulate on Windows after a few years of use is pretty amazing. Every user who’s ever logged on, even if they’ve long left the company still has a profile. While these don’t inherently hurt anything, they take up space. One of the largest complaints about modern versions of Windows is how large the uninstall files for patches can grow. If you’re doing an in-place upgrade, all of those previous uninstall files come along with it, again, taking up more and more space.
The Baggage Has a Bug Infestation
Finally, oftentimes bugs in OSes come from one file or registry change somewhere in the OS. This could have been an intentional change by a user or an accident, or a file install that made this change. Well, all of those changes pull forward with an in-place upgrade, so those all may resurface in your new OS. Depending on what the changes are, they may not give the same result in the new OS, or may not make any change at all and be vestigial clutter in the new OS. All of these changes and files and everything pulled forward makes it difficult to troubleshoot the OS after an upgrade.
Support
Many applications don’t recommend, or even support doing in-place upgrades. Even if those applications do support it, there are often caveats associated with it, such as requiring a repair install after the in-place upgrade. Pulling all the baggage mentioned above forwards can create a real support nightmare when it comes time to use the application on the new environment.
Complexity
The main reason people cite for wanting to do an in-place upgrade instead of a migration is that it’s simpler … but in our experience it rarely is. There are many things to keep in mind doing in-place upgrades, like if the old OS even supported going directly to the OS you want. For example, if you’re running 2008 R2, you can’t go straight to 2016, and if you thought the baggage for going from one OS to the next was bad, doing a double upgrade is even worse.
This website from Microsoft shows all the various upgrade options. Even if your OS supports the direct in-place upgrade, do your applications? If the version of the OS is old, often the application is as well, which may mean you end up doing an in-place upgrade of the application, which can lead to the above problems, then afterwards, doing an OS upgrade, and then possibly upgrading the application again, depending on supportability … in the end this can be way more work than doing a migration.
Migration
So what’s the option that pretty much everyone does in modern times? Build a new OS side by side. This was a major concern in the time of physical servers, because it meant that you had to dedicate another whole piece of hardware (which often had to be bought) to build anew. That could get pricey. In modern virtualized times, however, it’s not that difficult to simply spin up another VM. From there you migrate the data. Luckily, this too has gotten much easier in modern times. Most applications have some form of migration tools built in to help you migrate mailboxes around (Exchange) or databases (SQL). There are still some applications that are not easy to migrate, but it’s likely those applications would also have trouble with an in-place migration.
Conclusion
So can I say that 100 percent of the time it’s always easier to do a migration than an in-place upgrade? Not necessarily. If you have a basic file share, or flat file based application, an in-place upgrade may be sufficient. If the server isn’t very old and hasn’t been tweaked and modified a lot, and has plenty of free space, it may be possible to do it more quickly in that manner. Does that mean you’ll have a better end-experience after the in-place compared to the migration? It takes some analysis to figure that out on a case-by-case basis. Let us help.