December 10, 2016 at 11:42 am
Comments posted to this topic are about the item Faster Versions and More Support
December 11, 2016 at 2:48 pm
One possible downside of the fast release pace is the expense of upgrading. Paying new license fee each year or two is going to be very unattractive for some folks whose purchasing department already lacks a sense of humor.
My other concern about rapid pace is giving short shrift to testing. Take a look at the SSMS release that says Oops - you can't connect to older versions of SSIS but we plan to fix that.
New features: We love that. Stuff that used to not work and got fixed: Brilliant. The "oh shit" of stuff I need that went boom: I can more than do without that.
ATBCharles Kincaid
December 12, 2016 at 3:05 am
Steve Jones - SSC Editor (12/10/2016)
...supporting multiple versions isn't a bit deal...
No matter what support it will take some effort but I agree that with 3rd party (i.e. not Microsoft) resources available of the quality of SQL Server Central then it gives professionals a fighting chance.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 12, 2016 at 6:22 am
It is going to be a nightmare for DBAs... just think in 10 years how many different versions of SQL Server we will have to support.. not to mention Microsoft support folks as well.
We already have SQL 2005, 2008, 2008R2, 2012, 2014... haven't installed 2016 yet...
The problem with the rapid releases of SQL Servers coming is that vendors of software packages do not keep on top of the newer versions. I just upgraded an app we have running here to their latest application version and it ONLY supported SQL 2012. My boss is asking me why do we have to spend so much money on SQL Server every year for new licenses... for 90% of everything we run the new features are no help to us so the huge cost justification isn't there... but we have to upgrade to keep up... we fell way behind with SQL 2000 and I certainly don't want that to happen again. The double edged sword of upgrading.
December 12, 2016 at 9:39 am
Markus (12/12/2016)
...The problem with the rapid releases of SQL Servers coming is that vendors of software packages do not keep on top of the newer versions. ....
This is the problem we face. We need to wait for the 3rd party applications to support the new version, then have to get budget (and justification) to update the 3rd party applications (including cost, training and downtime) before we begin to upgrade SQL.
Often the SQL upgrade is the cheapest step in the process.
...
-- FORTRAN manual for Xerox Computers --
December 12, 2016 at 9:45 am
Agreed; I have vendors even now who try to get me to install a new instance of 2008 R2 for them :hehe:.
December 13, 2016 at 8:26 am
If Microsoft does intend to stick with a new release every two years, just for the purpose of introducing new features to market and maintaining competitive advantage, then it should include free R2 upgrades. For example: 2016 R2, 2020, 2020 R2 ...
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
December 13, 2016 at 10:32 am
The release cadence may be increasing but the issues remain the same. I recommend upgrading vigorously, say 3-6 months after a release so there is enough time to find out about big breaks. Any database that is not being upgraded should be on the list for decommissioning.
December 14, 2016 at 1:30 am
GeorgeCopeland (12/13/2016)
The release cadence may be increasing but the issues remain the same. I recommend upgrading vigorously, say 3-6 months after a release so there is enough time to find out about big breaks. Any database that is not being upgraded should be on the list for decommissioning.
Wasn't that the rule? Don't upgrade until at least SP1.
ATBCharles Kincaid
December 14, 2016 at 4:23 am
GeorgeCopeland (12/13/2016)
The release cadence may be increasing but the issues remain the same. I recommend upgrading vigorously, say 3-6 months after a release so there is enough time to find out about big breaks. Any database that is not being upgraded should be on the list for decommissioning.
No disrespect to you but you think any database that isn't upgraded should be decommissioned? Really... If the vendor of the software doesn't yet support it how can one upgrade? Secondly IT Depts don't have unlimited hours to spend on just upgrading to stay up-to-date. Third, software comes and goes.. however company historical data must remain sometimes for 7-10 years or forever. If that software doesn't run on the newer this or that you must simply maintain the system.
I wish our IT Dept had the number of people that we could keep current with WIndows and SQL Server builds... However, the sheer cost of upgrading is massive... we have over 60 production servers running well over 700 databases. In a 2 year release span of new versions of SQL Server I could never get everything upgraded every 2 years. One project we have been working on for over 18 months is upgrading one major system. SQL Server is a very small piece of it and it is the last system we have databases live in SQL 2005. We are about 12 months away yet from 100% of upgrading that system along. The amount of people involved in moving to the newer system, their time, the hardware, the software the time to install and test it all is massive. AND the databases are in SQL 2012... that is the newest version they supported when we installed it in November of 2015. So.. now before it is 100% live in production it is 2 versions old already.
December 14, 2016 at 8:10 am
Again, any database that is not being upgraded should be on the list for decommissioning. Make the owner of the data aware that they are on the decommissioning path. Make them understand that they are on legacy support and will have to pay the price for that support. Help them to understand the value proposition for upgrading their applications. Don't just lead them down some path of support forever. That path is nonsense.
December 14, 2016 at 8:24 am
GeorgeCopeland (12/14/2016)
Again, any database that is not being upgraded should be on the list for decommissioning. Make the owner of the data aware that they are on the decommissioning path. Make them understand that they are on legacy support and will have to pay the price for that support. Help them to understand the value proposition for upgrading their applications. Don't just lead them down some path of support forever. That path is nonsense.
Put this way it makes total sense.
As usual, communication is key.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 14, 2016 at 9:45 am
GeorgeCopeland (12/14/2016)
Again, any database that is not being upgraded should be on the list for decommissioning. Make the owner of the data aware that they are on the decommissioning path. Make them understand that they are on legacy support and will have to pay the price for that support. Help them to understand the value proposition for upgrading their applications. Don't just lead them down some path of support forever. That path is nonsense.
Easy to say not very easy to do..... In a company you may have several hundred applications running to support the business. Due to laws of data retention and legal reasons a company MAY have to keep that data for 7 years to forever. If the vendor of that app no longer exists you may be stuck with it like that forever. Also, it is a matter of budgets as well. I don't know of any company that has just specific teams dedicated to upgrading applications. It all about budgets and # of man hours. This one large upgrade we are 80% complete with has cost well over a million dollars to upgrade and we are 18 months in the 24 month implementation... AND parts of it are already out of date.
December 14, 2016 at 9:53 am
Oh for goodness sake, snap your fingers and wish for the moon and stars all you wish. If Legal wants an archive solution they can for darn sure pay for it. All applications are in some state of development. The only thing I care about is if they have revenue. If they do, then build it. Otherwise shut it down.
December 14, 2016 at 11:20 am
Another thing to consider is that there is zero ROI in upgrading existing systems. During economic downturns, these type of upgrades are the first things to go when 'doing more with less'. Then two years later, the upgrade effort is massive. The best way to approach upgrades IMHO, is to dangle the carrot of the new features, and provide a environment to try them out. Also simply refuse to install old software of new hardware. My current shop is on the small side, and we successfully got all of our 2005 and 2008 servers migrated to 2014 last year. But good luck in getting 2016 in just a year later. Things like this really need to be decided at the 'C' level, dba's can only do so much.
Viewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply