The Case for Upgrading

  • Eric M Russell (9/3/2015)


    Just curious what type of code changes would be needed for a MS Access application originally designed for SQL Server 2005 to support SQL Server 2014 ?

    Connectivity layer. If I understood correctly, the libraries or methods of connecting worked through R2, but weren't supported or allowed in 2012+

  • I'd be careful with the whole 'If it ain't broke...' mantra. While I generally agree with the sentiment, I've seen that 'wisdom' have the opposite intended effect. You have to make sure you are looking beyond just your instances and what they are integrated with. They don't exist in a technological vacuum and you may find that all you've done is accrue a lot of technical debt and now your server is the derided and costly 'legacy' component of a larger system.

  • We ran into this earlier this year too, although we're currently on 2008 R2. The server was 5 years old so it was time for new hardware. It also would have been a good time to upgrade SQL Server to 2012 or 2014, but not for an extra $100K. Now we're facing the decision whether to create a new BI infrastructure in SQL Server or Oracle. Either one will require buying a newer license so it'll be an interesting exercise to compare the costs and features of each.

    Be still, and know that I am God - Psalm 46:10

  • We have everything in 2008 R2. When we are forced to move we will make the jump to the most current version and then probably sit on that one for 6 to 8 years.

  • All this is why developers love greenfield projects. We develop a system then abandon it once it is deemed a "success". The smarter developers I have worked with always try and leave a maintainable system but know that the true grief is maintenance of the code and the surrounding technologies e.g. a SQL Server instance.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

Viewing 5 posts - 31 through 34 (of 34 total)

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