Post reply

Good Luck is Needed with Old Versions

  • February 11, 2020 at 3:35 pm

    #3724814

    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

  • February 11, 2020 at 3:42 pm

    #3724817

    Grant Fritchey wrote:

    Jeff Moden wrote:

    I agree with everything you said but, with all the really cool stuff that's been built into SQL Server in the last 8 years, couldn't you have cited a better reason to upgrade other than XE?  Sheesh!

    Honestly, I'm not sure how that slipped in. I think it was a brain fart, not my point at all. Apologies.

    Heh... Been there, done that.  Here's to things that fart in the night and long before coffee. 😀  Thanks, Grant.

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • February 11, 2020 at 4:07 pm

    #3724822

    kiwood wrote:

    Here is the question that I wonder - how does it make sense to risk one's livelihood working for a company that doesn't upgrade?

    Any IT entity that does not know how to justify IT expenses is not long for this world.

  • February 11, 2020 at 4:17 pm

    #3724824

    EdVassie wrote:

    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.

    Security is a good clincher too.

  • February 11, 2020 at 4:30 pm

    #3724825

    I have been sitting here with an upgrade to an Oracle 10 system lingering on the books for the last 2.5 years.  I am thinking of having a little party for the project, when it turns 3 in the fall.  Maybe it is my utter lack of ability to sell a project, maybe it is the department is going at full speed, and can only consider new items.  Probably the former.

    As for the costs of the upgrade getting steeper as you go on, there was a direct upgrade path from 10 to 11.  You can go directly to 12, but only if you are willing to reset everyone's password.  Going to 19 (Oracle did not want to have a version 13 for some odd reason), there may not be a direct path, so you may have to make a pit stop at an intermediate version.  Now come the questions.  Did this error/creeping bug happen in stage 1 or stage 2 of the upgrade?

  • February 11, 2020 at 4:40 pm

    #3724830

    kiwood wrote:

    Here is the question that I wonder - how does it make sense to risk one's livelihood working for a company that doesn't upgrade?

    Great point and, I'm sure, an impossibly hard question to answer. I like paying my mortgage (OK, I don't like it, but it's pay the mortgage or live on the street, so...), which means I'm going to sometimes do things that may not be the best in order to keep paying that mortgage. I get it.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • February 11, 2020 at 5:21 pm

    #3724842

     I like paying my mortgage (OK, I don't like it, but it's pay the mortgage or live on the street, so...)

    I am in the same boat and get the short term aspect of the situation. My wife would be quite upset if I simply quit today. But... one should always consider that the job may not be there tomorrow to pay the mortgage. And having your skills all tied in old software can be a huge damper on the ability to find that replacement job.

    I seriously think more IT people should always keep an eye on future employ-ability. I love my job and have no desire to change. But I also love my living situation more and will not risk that to keep the job. If the job becomes too outdated then it is time to suck it up and find the next one.

  • February 11, 2020 at 6:24 pm

    #3724868

    DinoRS wrote:

    It's not that my Supervisor or the Head of IT don't want to let me upgrade but rather that SQL Server 2019 hasn't been validated yet within this organization and therefore we're stuck with upgrading to 2017.

    Third party vendors are the thorn in our side as far as some upgrades are concerned. We've spun up 2019 for reporting and move some of our work there. That part is in our department's control. Unfortunately, other areas depend on apps from 3rd party vendors. One of them has at least validated their software on 2017 and they seem open to us rolling out 2019 with the database in 2017 compatibility. The other vendor is not so willing to validate anything past 2016. Using that as leverage to get us to upgrade to the latest version of their software to get to 2017. The databases for both these apps are for the same part of the business and live on the same server. Our company is not going to approve the dollars for two different SQL Servers which will only have one database on each. We have to live with the lowest common denominator. So now my job is trying to convince the business to upgrade a software package in order to only be one version behind instead of two.

    I guess it could be worse. This will retire two 2012 servers (QA and Prod) and only leave us with two 2014 servers to retire in the not to distant future. Everything else will be 2016 - 2019.

  • February 18, 2020 at 11:30 am

    #3726685

    Third party contracts like that are only as good as the last test.

     

    I'm a DBA.
    I'm not paid to solve problems. I'm paid to prevent them.

  • March 5, 2024 at 4:58 pm

    #4390096

    I am late to this party, but am reminded of a company where I worked as a contractor in 1995. They ran their accounting on a System 36 they had bought in 1983, the year the System 36 came out. It was slow, lacked storage space, and took up a bunch of room. The ledgers had to be printed and copied every month, as part of the new month process was to delete the last month to free up space on the 500MB disk.

    I suggested upgrading to a small AS/400 and a new version of the accounting software for better reliability and performance. The Controller was horrified "We paid $80,000 for that system. There's no way the owner will let us replace it". That was foolish.

  • March 5, 2024 at 5:12 pm

    #4390103

    Same old story.

    Thanks for sharing.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • April 26, 2024 at 6:37 am

    #4415618

    Reading these posts makes me feel better about only having SQL Server 2016 (and an exit plan for it) and procrastinating over upgrading my Windows 8.1 tablet because it works as it is. Migrations are scary so good luck to anyone on old software and hardware especially with that first hurdle of getting approval from those holding the purse strings.

  • April 26, 2024 at 7:50 am

    #4415627

    What about the appliance argument? Namely, there's an application running on SQL Server 2008 & Windows Server 2003 that runs purely in-house and is not connected to the Internet. If we leave it alone, the likelihood of it breaking is less than that of us upgrading it. And if we upgrade it, it will cost money with the new hardware requirements, new licence fees and possibly having to pay developers for hundreds of hours because the old frameworks are no longer supported. We have an old server kept aside as replacement hardware & the original install media. If it ain't broke, don't fix it.

    I've come across this argument online and my standard response is to put it into VMs. The core point made though, is that if it works and is kept internal, does it really need to be upgraded?

  • April 26, 2024 at 9:24 am

    #4415657

    This is a timely repost.  The longer you leave upgrading

    1. The more convoluted the upgrade path will become and with it the risk associated with upgrades.
    2. The more likely that the list of vulnerabilities and bugs will have manifested.
    3. The less likely that security patches and bug fixes will be available
    4. The more likely that exploits for those vulnerabilities will have appeared in the wild.
    5. The more likely you end up with a spread of versions to support within your organisation
    6. The more likely you lose time to having to remember that you have to do things differently in earlier versions to the version you use most frequently.
    7. The harder it is to recruit people to work on platforms that are almost dead in the market place.
    8. The more likely the upgrade of one system requires the upgrade of another, with both needing an upgrade.
    9. The more likely that documentation for old systems has started to disappear from the web (AKA link rot).
    10. The more likely expertise has aged out of your organisation
    11. The more likely a DR situation has a bumpy recovery.

    The choice of when to upgrade depends on the organisation's appetite for risk.  There is a sweet spot where the risk of upgrade vs the risk of not upgrading are balanced.

    LinkedIn Profile

  • April 26, 2024 at 11:54 am

    #4415706

    I think we’ve all been there at some point in the past.

    As stated you have the risk of security issues arising, undiscovered software issues, aging hardware and OS, etc.

    Remaining within support constraints from MS is a very good reason to have an ongoing project plan to uplift older versions even if they cannot use newer features (legacy app for example).

     

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

Viewing 15 posts - 16 through 30 (of 35 total)

You must be logged in to reply to this topic. Login to reply