In-place upgrades for Windows Server (updated for Y2016)

In the spirit of asking a Good subjective question I bring this forth again, in hopes that ServerFault will continue to be a preferred "go to" when searching on this topic.

OLD REFERENCE

Back in 2011 this question was asked: Reasons Why In Place Upgrades Are Bad

THE QUESTION

Is doing an in-place upgrade of Windows Server x64 (2008 R2, 2012, 2012 R2) to a newer supported Windows Server version a good practice these days or no?

THE ANSWERS

Remember from the link above: Great subjective questions tend to have long, not short, answers. The best subjective questions inspire your peers to share their actual experiences, not just post a mindless one-liner or cartoon in hopes of being rewarded with upvotes for being merely "first."

My opinion is, when supported, an in-place upgrade of a Windows Server OS to a newer version is the preferred method for upgrading a server (especially a VM) these days. Not only is it much quicker, and allows for greater automation, but it also no longer holds as much risk vs. reward that older OS in-place upgrades represented due to Microsoft's support of a better lifecycle transition model.

Microsoft has done a lot to make sure that in-place upgrades are easier than before and more seamless, without the problems that plagued older OS upgrades. This seems to be the recommended course of action if you want to keep everything as is: Windows Server Installation and Upgrade:

"If you want to keep the same hardware and all the server roles you have set up without flattening the server, upgrading is the way to go"

Even MS bloggers are believing the hype: In-Place upgrade of 2008 R2 to 2012 R2

In addition, VMs allow for snapshots, P2V, cloning, and rollback to ease in this transition. (Reference: "P2V it into a test VM and, uh, test it."

We should be "Treating servers like cattle not pets" - Randy Bias. The old days of caring and feeding the servers you are responsible for isn't done as intimately as it once was. Not every server is a snowflake, and public cloud hosting is a prime example of this practice.

For instance:

• Azure - Azure in-place upgrade options
• AWS - AWS in-place server upgrade options

I've personally done multiple in-place upgrades from 2008 R2 to 2012 R2 over the past year, with about 400 more planned for the next year and a half. All have gone just fine, with only minor issues afterwards on 2 servers that didn't require rollbacks. As long as the existing server is running fine, you should feel confident in moving this direction.

Some important things to consider when making this claim that in-place upgrades are the preferred way to go:

• Is the upgrade supported? - For example, switching language versions, or build types isn't Upgrade Options to Windows 2012 R2
• Are the applications running on the server fully compatible with the new OS version in their current state?
• Is there a way to rollback easily to the previous state before the in-place upgrade (VM Snapshot, backup, clone, etc.)?
• Does the hardware (if applicable) support the new OS?

• Is the existing server running well currently without issues?

  If the answer is YES to ALL of the above questions, then an in-place upgrade is the preferred route.