Understanding SQL Server 2008 and 2008 R2 end-of-support options
Published Jul 09 2019 07:00 AM 8,065 Views
Microsoft

Mark today's date: July-9 2019 - this day marks the official last day of SQL Server 2008 and 2008 R2 support, and has been in the lifecycle calendar since the day it released, 10 years ago. This means there's no more product updates coming, and Microsoft Support will no longer take support calls for discontinued versions. But there are options, so please read on.

 

SQL Server has one of the longest support lifecycles in the industry, which is maintained even in our latest release (SQL 2017 and soon SQL 2019): 5 years of mainstream + 5 years of extended support.

During the first 5 years (mainstream), Microsoft updates any given SQL Server release with enhanced capabilities, closes feature gaps, and addresses functional, performance, and security bugs.

In the 5 years of extended support, Microsoft addresses security bugs until the 10-year mark.

 

And if you move to Azure SQL Database, even with Managed Instance, then support lifecycle become a thing of the past. With an evergreen model, Azure SQL Database always runs the latest release of the SQL Database Engine code that is the same you run in your on-premises SQL Server. You can leverage the Azure Data Migration Service (DMS) to do online migrations to Azure.

How do we keep the continuous deployment model, and still don't break applications? That's because any feature or functionality that could be potentially affecting an application's functionality or performance is gated by compatibility levels. This protects your database that was created in Azure years ago from changing behavior throughout time with the continuous release model we have in Azure. See more information in the article Compatibility Levels and SQL Server Upgrades.

 

Wait, SQL 2008 released in July 2008, but SQL 2008 R2 released in May 2010 - why are these two share the same end-of-support date?

This is because both SQL Server releases share the same major version number: version 10. Different major version numbers have a different lifecycle. In SQL Server's history, the only time a major version number was shared was precisely with SQL 2008 and 2008 R2. You can see that for yourself in the article How to determine the version, edition, and update level of SQL Server and its components.

 

Options

If you were somehow caught off guard with the end-of-support date, there are options in order to maintain the supported status of your SQL Server estate:

  1. Upgrade to a more recent version of SQL Server or Azure SQL Database Managed Instance, without having to change and fully recertify your current application. If you want to modernize now, this is the way forward. This is especially useful for those vendor applications for which you don't have support anymore and didn't see a way forward. See more information about Compatibility Certification in the article Compatibility Levels and SQL Server Upgrades.
    • Compatibility Certification allows you to move to a SQL Server version that is well within the 10 years support boundary (at this time we'd recommend you upgrade to a version not earlier than SQL Server 2017), while ensuring your applications maintain its current functionality intact - in other words, virtually no code changes. As mentioned earlier, this is how we do it in Azure SQL Database.
    • And Microsoft provides ways to further ease your mind. The Microsoft Data Migration Assistant (DMA) tool allows you to perform a static functional surface area validation of the application code in the database (programmability objects such as stored procedures, functions, triggers, and others) and in the application (using a workload trace that captures the dynamic code sent by the application).
  2. Move to an Azure Virtual Machine running SQL 2008 / 2008 R2 and become automatically subscribed to an additional 3 years of extended support with Extended Security Updates (ESU) at no extra cost (apart from the cost of the VM), while you weigh options and execute your data modernization strategy. This is an useful option if you need more time to determine your next modernization step. See more information on ESUs in the SQL Server 2008 end of support landing page, and the Azure Migrate page for lift-and-shift options to move your current SQL 2008 / 2008 R2 into an Azure VM.
  3. Purchase an Extended Security Updates (ESU) subscription, and extend the supportability status of your SQL 2008 / 2008 R2 for 3 years (covers on-premises and other cloud solution providers such as AWS and GCP). This is another useful option if you need more time to determine your next modernization step. Once you have upgraded your SQL 2008 /2008 R2 instance, discontinue the ESU subscription for that instance. See more information on this option in the SQL Server 2008 end of support landing page and the Extended Security Updates frequently asked questions.

 

Download security updates for ESU-enabled SQL Server instances

An ESU subscription for Azure SQL VMs that are configured for automatic updates doesn't require any further action. For SQL Server on-premises or in hosted environments, or on Azure VMs that are not configured for automatic updates, you need to download and install a security update manually.

 

To be able to download a critical security update (if and when released over the next 3 years), you must first register the SQL Server instances for which you are eligible to access those updates. For more information, see Downloading Extended Security Updates.

 

Useful links

Here are a few useful links to help you navigate your options:

 

There are options to move forward and keep leveraging the innovations, scalability, robustness, and ease-of-use of the SQL Server platform, either in your own datacenter or in the Cloud. And knowing the options allows organizations to make informed decisions about data estates that are best suited for their rhythms.

 

Pedro Lopes ( @SQLPedro ) – Senior Program Manager

4 Comments
Version history
Last update:
‎Jul 08 2019 04:14 PM
Updated by: