Quick Scan Report – SQL 2008 and SQL 2008 R2 End of Life

What this check looks for

The instance’s version against Microsoft’s published end of extended support dates. SQL Server 2008 and SQL Server 2008 R2 both left extended support on 9 July 2019, and this page covers that finding.

The check reports whichever version applies, and each has its own page:

Everything below applies to any of them. Only the date changes.

Why it matters

The practical meaning is narrow and serious: no security patches, and none coming.

Everything else about the instance keeps working. That is what makes this easy to defer year after year, and it is why the finding is High rather than Critical. Nothing breaks on the end of support date. What changes is that from that day forward, every vulnerability found in that version stays open on your server permanently.

• No security updates. Vulnerabilities discovered after the date are never fixed for you. They are, however, published, so the details are available to everyone.
• No bug fixes, no cumulative updates, no hotfixes.
• No support. If something goes badly wrong there is no case to open with Microsoft, at any price.
• Compliance. Running unsupported software fails PCI DSS, HIPAA and most cyber insurance questionnaires outright. This is frequently the reason an upgrade finally gets approved.
• The surrounding stack ages too. An unsupported SQL Server tends to sit on an unsupported Windows, with drivers and client libraries that current application frameworks have stopped shipping.

There is a quieter cost as well. Every year of delay makes the upgrade larger. Upgrading from 2008 R2 today means crossing several versions at once, with a cardinality estimator change, deprecated syntax to find, and compatibility level decisions, rather than the single step it would have been years ago.

How to confirm it yourself

SELECT SERVERPROPERTY('ProductVersion')    AS [version],
       SERVERPROPERTY('ProductLevel')      AS [service_pack],
       SERVERPROPERTY('ProductUpdateLevel') AS [cumulative_update],
       SERVERPROPERTY('Edition')           AS [edition],
       SERVERPROPERTY('MachineName')       AS [machine],
       @@VERSION                           AS [full_version];

The major version number is the first part of ProductVersion:

How to fix it

Upgrade. There is no other answer, and the only real decision is how.

1. Find out what depends on this instance. This is the step that determines the size of the project, and it is the step most often skipped. Linked servers pointing at it, applications connecting to it, jobs running against it, and reports reading from it.
2. Check what will break. Run the Migration Planner report, which looks for the things that stop an upgrade: deprecated syntax, features removed in later versions, and compatibility level dependencies. Microsoft’s Data Migration Assistant does the same job and is free.
3. Decide the target. Going to the newest supported version buys the longest runway. Going one version back is sometimes the pragmatic choice where an application vendor has not certified the newest.
4. Decide the method. A side by side migration onto a new server, restoring the databases, is almost always better than an in place upgrade: it is testable, it is reversible, and it is a chance to fix the configuration findings elsewhere in this report rather than carrying them forward.
5. Plan the compatibility level separately from the upgrade. Restoring a database onto a new instance keeps its old compatibility level, which is a useful way to separate “the upgrade” from “the new cardinality estimator” and to roll one back without the other.

If you cannot upgrade yet, reduce the exposure rather than accepting it: put the instance behind a restricted network segment, make sure it is not reachable from anywhere it does not need to be, tighten the logins, and make sure the backups are good and tested. Those are mitigations and not a fix, and they should come with a date.

Stedman Solutions does upgrades and migrations, including from versions this old: databasehealth.com.

How long it takes

A week of effort is a realistic planning figure for a single instance with a handful of databases, spread over a longer elapsed period for testing and a cutover window. The assessment itself is a day.

Related reports

Related checks

Frequently asked questions

It has worked fine for ten years. It probably has, and it will keep working. The risk is not that it stops, it is that every vulnerability found from the end of support date onwards stays open permanently.

Can we buy extended support? Microsoft has offered Extended Security Updates for some versions, generally tied to Azure or to a volume licensing agreement, and they are time limited and priced accordingly. Worth investigating if you genuinely cannot move yet, and not a substitute for moving.

Which version should we go to? The newest your application vendor supports. If they support the newest, take it, because the support runway is what you are buying.

Is upgrading the operating system enough? No. It is a separate problem and usually a related one, since an unsupported SQL Server is often on an unsupported Windows. Both need doing.