Back in January 2010 when SQL Server 2008 R2 was released, the world was a different place.  The very first iPad had yet to be sold, Alabama beat Texas to win their first National Championship in 18 years, and nine years later not much has changed.  The iPad turned to be a run-away success, Alabama went on to win another four National Championships, and the release of SQL Server 2019 is right around the corner.  As for SQL Server 2008 R2, well, July 2019 marks the end of support.  Meaning Microsoft will no longer be releasing security updates for SQL Server 2008 and 2008 R2 and they should be considered not secure at that point.  A lot changed in technology since 2008 R2 was released, and before you upgrade to a newer version, it’s good to ask some questions about your current configuration.  


Does your current environment still work?

When you did the initial setup of SQL Server 2008 R2 almost a decade ago, your data environment looked way different.  Maybe you couldn’t even fathom having more than a dozen databases spread across a handful of servers.  Since then, your infrastructure has exploded with the need for large amounts of data to support your BI or Machine Learning applications.  Is SQL Server still the best Database Management System (DMS) for your business needs?  Maybe Mongo is a better solution for its blazingly fast reads, or maybe Postgres can perform the same work without the extra licensing cost.  


Do you even need this server?

Maybe your 2008 R2 server is underutilized or there’s databases on the server where their purpose has long been forgotten.  If this is the case, you’ll need to determine each if a database is in use and who is using it.  Our standard process for deprecating objects is to run a trace for two weeks and if the results come back clean, you can consider moving databases to already upgraded existing instances.  This is one of the easiest, quickest, and cheapest migrations you can do.  The steps to get this done are pretty cut and dry.  Backup, restore, apply logins, and check for orphans.  At the end of the day you’ll have one less server and one less SQL Server/OS license to pay for.  

See also  How to Use Whiteboard in Microsoft Teams


Where are you going to put it?

When 2008 R2 was released in early 2010, most viewed cloud offerings as not mature enough to reasonably run a SQL Server instance from it.  Now, putting your server in the cloud is as viable as a solution as choosing between a physical server and a virtual machine (vm).  The scalability and reliability of a cloud offering is unmatched by any non-cloud solution.  It’s something to be considered, even if you ultimately decide that the cost or function of an on-prem/vm server doesn’t require any of the cloud’s advantages.  


What else did you forget?

Of course, the data is the most important part of a database server.  When upgrading or migrating SQL Servers, no one ever forgets to migrate the data.  If you did, it wouldn’t be long until you were reminded by your users/devs.  What about all the other stuff that has to be moved?  Did you remember to move your Server Logins?  Did you check for Orphans?  What about Local Admins on the OS, did you remember to create them on the new server?  That’s just users.  A few other often overlooked items when migrating servers are SSRS configuration, encryption keys, MSDTC settings, SQL Server configurations, Agent Jobs, Scheduled Tasks, Linked Servers, Alerts, Operators, and maintenance work.

A lot has changed in the database world in 2010 when you were setting up your 2008 R2 SQL Server and rocking Gangnam Style.  Now it’s 2019, Big Data is big everywhere, half your servers are in the cloud, and your k-pop sensibilities has matured from Psy to BTS.  Now with SQL Server 2008 and 2008 R2 reaching end of life, it’s time for your SQL Server mature too.  Regardless of how you plan to upgrade/migrate your old SQL Server, Agio’s DBA team can help guide you through the choices and get the needed work done.

Learn More