December 15, 2016 at 4:46 am
Charles Kincaid (12/11/2016)
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.
Microsoft eases this with Software Assurance. It's like renting the software, getting upgrades with this. It's costly, but if you want to keep up, it makes some sense.
December 15, 2016 at 4:48 am
Markus (12/14/2016)
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.
I'm with Markus here.
If I have a SQL 2000 db that is still in production, and working, what's the issue? At this point it's unlikely anything will break. Certainly a security issue could come up, but those seem to be rare, so I'd stick with them. Same for 2005.
Upgrades after a long time could be painful, but so is trying to keep up.
December 15, 2016 at 5:25 am
Steve Jones - SSC Editor (12/15/2016)
Charles Kincaid (12/11/2016)
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.
Microsoft eases this with Software Assurance. It's like renting the software, getting upgrades with this. It's costly, but if you want to keep up, it makes some sense.
We signed an Enterprise Agreement with MSFT earlier this year to purchase SQL cheaper with SA... however, it is sticker shock to the app folks that want to upgrade to pay for it that way... when they cannot tell me if they will upgrade in the coming 3 years. It is all about cost to upgrade and ROI and a lot of these small systems just don't have an ROI for the amt of time and money it takes to upgrade.
December 15, 2016 at 8:19 am
Steve Jones - SSC Editor (12/15/2016)
Markus (12/14/2016)
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.
I'm with Markus here.
If I have a SQL 2000 db that is still in production, and working, what's the issue? At this point it's unlikely anything will break. Certainly a security issue could come up, but those seem to be rare, so I'd stick with them. Same for 2005.
Upgrades after a long time could be painful, but so is trying to keep up.
Only worth it if there is an issue or changes to be made. Even then it is only worth considering.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 15, 2016 at 8:36 am
The issue is the technical debt that accrues to old databases. I have seen entire departments evaporate because they could not afford the development work needed to upgrade. I advise a less blasé approach to upgrading. Clients need to be informed of potential costs.
December 15, 2016 at 8:53 am
GeorgeCopeland (12/15/2016)
The issue is the technical debt that accrues to old databases. I have seen entire departments evaporate because they could not afford the development work needed to upgrade. I advise a less blasé approach to upgrading. Clients need to be informed of potential costs.
Agreed but considered inaction <> blasé.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply