May 3, 2019 at 12:00 am
Comments posted to this topic are about the item The Minimum Upgrade Point
May 3, 2019 at 6:56 am
I am upgrading some systems right now and we're going (from 2008 R2 - 2014 to) SQL 2017 although at least for the DWH I will rather sooner than later recommend to move to SQL 2019. The latter one for the features, the other ones for the support of SQL Server. The strategy we go for is: Upgrade to the most recent version so the next (must be) upgrade is furthest away in the future.
The Client likes this approach and the next step may be just to stack small SQL Instances as Docker Containers instead of using full fledged VMs for each instance which requires mixed authentication.
May 3, 2019 at 9:14 am
For me it all boils down to costs. Any change in licensing comes under the category of "difficult conversation".
The costs in terms of time and effort to upgrade is something that is more in my control. It is a solvable problem.
There is interpretation of test results. Working out how to codify the decision making process will help speed that up. If 75% of the decision points can be codified then I can focus on the remaining difficult considerations and maybe chip away so that 75% goes to 80+%.
In the open-source and NOSQL world the test-heavy approach means we upgrade more frequently and the perception of risk is lower. When I read down the fix list of a SQL Server service pack my first reaction is that a lot has changed and therefore the risk is huge. When I take a step back the majority of changes don't really have an impact on my particular scenarios so the risk is actually tiny. Perception and reality are not the same thing.
May 3, 2019 at 1:10 pm
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.
May 3, 2019 at 1:21 pm
Years ago the most stable version of SQL Server would have been selected as the upgrade target. Since Microsoft changed to a 'born in the cloud' model, and began using Azure SQL database as the initial code base for upgrades, the on-premises versions have been far more stable when released. At this point I would have no concerns with choosing SQL 2019 as the minimum upgrade point.
MattF
May 3, 2019 at 2:12 pm
I've never known any release of SQL Server to be categorically "unstable". Every release fixes some issues and introduces new issues, but every experience is unique depending on what features you use and how you use the product.
I've worked for companies in the past who would sit on a specific release of SQL Server for several years and dismiss new releases with skepticism. Maybe executive management doesn't trust Microsoft to release good products, or maybe it's not trusting their IT staff to handle the upgrade process and code changes. But without trust the IT organization becomes stagnant, and even the good staff members will start to leave.
The main considerations are:
- Will this new release have integration issues with my existing 3rd party tools and applications, and are there upgrades for these products as well?
- How will this new release affect my SQL execution plans, and can we readily mitigate this?
- What are the costs for the upgrade?
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 3, 2019 at 2:13 pm
For me it all boils down to costs. Any change in licensing comes under the category of "difficult conversation". The costs in terms of time and effort to upgrade is something that is more in my control. It is a solvable problem.
I agree. Upgrading at all is a hard conversation with costs. but if you decide, why not 2016/2017? The cost is the same to move t0 2014.
May 3, 2019 at 2:14 pm
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.
May 3, 2019 at 2:32 pm
I've got a sneaking suspicion that the number of fairly modern apps that would run happily on SQL2005 or earlier and not just those who insist on a highest supported version of 2008R2.
May 3, 2019 at 2:44 pm
I would think another big factor holding some back could be licensing. Not everyone pays for Software Assurance.
May 3, 2019 at 2:51 pm
We appear to be standardizing on SQL Server 2016. I work for a large state agency, so I don't know all of the applications we have. Of the ones I know about, most are on SQL 2016. Although we do have one, major third party app where the vendor insists upon our using SQL Server 2008 R2. No, I've no idea why they've not upgraded.
Kindest Regards, Rod Connect with me on LinkedIn.
May 3, 2019 at 3:11 pm
In the lab space, third party vendors can be VERY SLOW to validate their code on new versions. We have two different vendors we work with who are telling me that maybe by next year they'll qualify their apps on 2016 which will then be 3 versions back from current. Getting them off of SQL Server 2012 is maddening. All of our in house applications are running against SQL Server 2017 in DEV, QA and Production. It's the 3rd parties that hold us back.
May 3, 2019 at 3:13 pm
Y.B. wrote:I would think another big factor holding some back could be licensing. Not everyone pays for Software Assurance.
This isn't a question on whether to upgrade. If you've made the decision, to which version do you upgrade?
Right...absolute brain fart on that one. I know my previous employer didn't want to deploy the latest and greatest following the whole "let Microsoft work the bugs out first" attitude. That being said we would only be talking one version behind. To purposely deploy something that will be out of date the second you deploy it is crazy.
Viewing 15 posts - 1 through 15 (of 23 total)
You must be logged in to reply to this topic. Login to reply