SQL Server 2008 End Of Life

Microsoft will no longer release security updates for SQL Server 2008 and SQL Server 2008 R2 after July 9, 2019. Remaining on legacy infrastructure exposes your business to security threats, makes you non-compliant with regulations, and is more costly to operate.

You can bet hackers have the SQL Server 2008 a end of service date penciled in their calendar. They will be adding their finds to the list of SQL Server 2008 vulnerabilities. Once hackers have crowd-sourced the list of vulnerabilities, they will conduct a quick Google search to download a list of companies currently on unsupported servers and will begin exploiting those companies. 

It really is that easy. So instead of dealing with a data breach and explaining to your CEO and customers that you remained on legacy systems past the end-of-service date, you should probably just upgrade your IT infrastructure. I mean... it's over 10 years old anyway, it's about time you move on!

SQL Server 2008 End of Support

You have nearly identical options with Windows Server as you do with SQL Server 2008. First, you can migrate your SQL 2008 Server to Azure, giving you 3 more years (until 2022) of extended security updates for free. Second, you can upgrade your on premises 2008 to SQL Server 2012, 2014, 2016, 2017, or 2019 by July 19, 2019 and leave it on-premise or in Azure. Or for your third option, you can migrate and upgrade from SQL Server 2008 on-premise to Azure SQL Database Managed Instance.

Step 1 - Assess

Before you to anything, use the Microsoft Data Migration Assistant to assess your workloads before migrating. This tool detects compatibility issues that can impact the functionality of your database on a newer version of SQL Server. It can also move your schema, data, and un-contained objects from your source server to the new target server. Read the step-by-step guide to using the Data Migration Assistant to get started.

Next, you'll want to use the Microsoft Assessment and Planning (MAP) Toolkit, a tool to evaluate your IT infrastructure. Doing so will allow you to discover all database assets and their characteristics, including size and database details, statistics on the number of tables, views, as well as stored procedures within those databases.

It's been a long time since 2008, what version of SQL Server should we go with now? The answer to that is Azure SQL Database Managed Instance. Why Azure SQL Database Managed Instance? Because it's a fully managed Platform-as-a-Service (PaaS) solution where Microsoft automatically patches and updates your workloads with automated backups, built-in high availability, and security. All of this decreases management overhead when it comes to maintenance, dramatically decreases total cost of ownership, but most importantly frees up YOUR precious time so you can do more creative and productive tasks! Skeptical? Here are stories from 4 Microsoft customers who moved to Azure SQL Managed Instance. And for more details on the platform itself, watch the video below for more details.

Not ready to fully commit and completely change how you do IT? No worries, it can be a lot for some, which is why SQL Server 2019 hosted on Azure or on-premises is your next best option. You'll still be able to take advantage of a huge leaps in technology and lots of savings! You can even check out the top 10 reasons people choose SQL Server 2019.

Step 2 - Migrate

Let's fast forward a few weeks when you and your team has assessed your environment, has decided they want to go with Azure SQL Managed Instance, and are ready to go. The following are the steps to migrate to Azure, which you can read in more detail in Microsoft's step-by-step guide.

1. Provision and configure an Azure Virtual Network (VNet)
2. Create an optimally sized Azure SQL Database managed instance
3. Create an Azure Storage account for backing up your source database
4. Create a Database Migration Service migration project with the source and target defined
5. Connect and test your application

Step 3 - Optimize

Once you're done it's time for post-migration optimization! Because you're moving to an edition of SQL Server that is 10 years newer than your current one, and is now managed by Azure instead of being on-premise, you may run into query regression issues. You can fix this by changing the compatibility level of your source database then going into query store to drill-down on performance before and after your changes. Next you'll want to check for missing or incorrect indexes, as they waste memory and CPU. To fix that problem, use the Database Engine Tuning Advisor.

Thank you for reading and I appreciate you taking the time to drudge through some pretty dry material. Of course it's important to remember that *ideally* these steps will work exactly as described, but as everyone in IT knows, things never go as instructions say they will. But this article should get you going in the right direction. Have fun!

More readings

1. SQL Server 2008 and 2008 R2 End of Support is Coming
2. An Easier Path to the Cloud for Your Legacy SQL Server Data
3. Migrating SQL Server to Azure SQL Database Managed Instance
4. Cloud Lessons Learned: 4 Companies that Migrated Their SQL Data
5. Extended Security Updates After End of Support for Windows Server and SQL Server 2008 and 2008 R2
6. Extended Security Updates for SQL Server and Windows Server 2008/2008 R2: Frequently Asked Questions