Back around 2014, my then employer was putting a case together to move from the last SQL2005 servers. The thing that clinched it was reliability.
We worked out we might get perhaps 3 fewer unplanned outages over a two year period. Even reducing the unplanned outage count by 1 per year would pay for the project, so it went ahead as a no-brainer.
The upgrade was very timely. Some application and database changes made soon after the upgrade increased memory requirements to beyond what the box could cope with. We exploited the new Buffer Pool Extension feature which gave back enough performance to last us until the memory could be upgraded.
It it aint broke don't fix it seldom takes into account the cost to the business of keeping the old stuff working, it stays focussed on the marginal cost of the upgrade. When you take into account all the business costs, plus the loss of opportunity in not being able to use new features, then upgrades become much easier to justify.
In my current job we plan to go live this week with SQL2019 for our development environment, with production following in about 4 weeks. The high degree of compatibility between releases, plus the desire to present to the business the ability to exploit the latest features gives us the confidence to go ahead on this.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara