May 3, 2019 at 5:44 pm
Eric M Russell wrote:The main considerations are:
Does support become a consideration?
What I meant was that, when considering which version of SQL Server to run on, if there are no financial or known technical barriers, then my recommendation would be upgrade to the latest generally available release.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 3, 2019 at 11:47 pm
Minimum upgrade point for us depends greatly on the application which will be using it. That is not always a current version. I get to spend the weekend migrating two more remote systems to new VMs and upgrading their SQL to 2012 (from SQL2008). SQL2012 is the most recent version supported by the application vendor under our current support contract. Going to a new version of the vendor software would be a huge capital investment because of the production line hardware that would need to be updated or replaced. So we just go for the newest version we can.
If there isn't an application restriction our current standard is for SQL2016. We typically skip every other version as much as possible to standardize as much as we can. Of course there are always one or two systems which just have to use the version we are trying to skip.
May 7, 2019 at 8:14 pm
Minimum upgrade point will depend on your migration cycle and where you are from a timing perspective. If you just migrated to 2016, you may not be ready for 2017 for another 6 months or whenever you can complete your analysis of LOE to migrate and test.
I agree with Steve. 2016 SP1 should be the minimum. 2017 if possible.
May 10, 2019 at 6:19 am
We had this conversation just after 2017 was released, to replace our aged 2005 servers, and I pushed hard (and won) the decision to go with that over 2016. With a massive SQL code base, multiple other projects that are considered higher priority by the business and various other factors, we're still not quite finished yet. The days of "wait for service pack one" are really a thing of the past and I'd definitely recommend getting a close to the most recent version as you possibly can - that might be difficult if you have a large number of third party applications with compatibility constraints, but pressuring vendors to help you get onto a platform with the maximum support possible is to your benefit ultimately.
If Microsoft would make aspects of exactly replicating a server easier, especially things like Job IDs, it would make some of the more cumbersome aspects of commissioning a replacement, upgraded, server easier.
May 11, 2019 at 4:54 pm
Interesting topic and I've had to consider this many times over the last few years. In my experience, places I've worked at have usually been software assured, so straight licensing cost hasn't been a factor. If a decision has been made to upgrade, the usual restriction has been version limitations on what the vendor will support. Sometimes those can be both frustratingly and surprisingly old!
If not a vendor system, then usually I will recommend the latest version released as long as it's not less than six months old. A few major versions ago, I used to go by the old maxim of waiting for SP1 to be released, but I think as time has gone on, RTMs have become more stable and complete than they used to be. So even if SQL 2017, for example, did have Service Packs, I wouldn't have waited for the first one (usually about 10 or so Cumulative Updates) and indeed upgraded some Production systems to SQL 2017 by about CU6 or so.
Where I currently work, we're about to upgrade our Data Warehouse from SQL 2012. As tempting as it is to say wait a bit for SQL 2019, that would mean, for me to feel comfortable, waiting until about October/November to start testing in DEV, assuming it is released in June. We can't wait that long for various reasons, so SQL 2017 it is. Still a fairly major upgrade though!
May 11, 2019 at 5:01 pm
.
May 11, 2019 at 5:03 pm
Jbeckman wrote:How can MS help? By prodding the lazy vendors to support newer versions. We are held back by vendors who in some cases are recommending 2008! And these aren't mom-and-pop outfits, either. It's pretty maddening having to constantly remind the business side that the version of SQL supported by their vendor is *not* supported by Microsoft.
This I agree with. I'd pull partner status if they can't support a new version in 12-18 months. Most of the time it's just them doing testing. Nothing changes.
Absolutely. That aspect is quite frustrating for me because I went from working in an industry of many vendors falling all over themselves to offer reasonably cutting edge solutions to an almost cartel feel where there is seemingly little motivation for them to bother upgrading the SQL back end with new application versions. Incredibly, we still have some vendors offering SQL 2008 (not kidding) as the standard. I have to bite my tongue a bit when directing then to the Microsoft product life cycle website!
May 11, 2019 at 5:06 pm
Minimum upgrade point will depend on your migration cycle and where you are from a timing perspective. If you just migrated to 2016, you may not be ready for 2017 for another 6 months or whenever you can complete your analysis of LOE to migrate and test. I agree with Steve. 2016 SP1 should be the minimum. 2017 if possible.
Respectfully, I disagree. SQL 2016 SP1 is going out of support on the 9th July this year, so upgrading to that seems a waste of time to me. My absolute minimum would be SQL 2016 SP2, but I'd argue hard for SQL 2017 (latest CU).
May 13, 2019 at 3:44 pm
When permitted by the vendor, we upgrade test to the latest available. The next version is probably there when testing is over in some scenario's
Viewing 9 posts - 16 through 23 (of 23 total)
You must be logged in to reply to this topic. Login to reply