Reading the SQL Server Support Lifecycle

The SQL Server support lifecycle tells you which support phase a release is in and when that phase ends. It doesn't tell you whether your installation is current, so check the build and the product's lifecycle record separately.

Identify the Product You Actually Run

Start with the Database Engine version, edition, and installed build. Don't use the SSMS version as a substitute. A modern client can connect to an old engine. Keep separate inventory records for components that have their own release or support schedule.

SELECT
    @@SERVERNAME AS server_name,
    SERVERPROPERTY('ProductVersion') AS version,
    SERVERPROPERTY('ProductMajorVersion') AS major_version,
    SERVERPROPERTY('Edition') AS edition,
    SERVERPROPERTY('ProductLevel') AS product_level;

Use the major release to locate the matching Microsoft Lifecycle product page. Check the edition notes and any servicing requirements listed there. Save the dates and the date you verified them. A copied spreadsheet should point back to the record it summarizes.

If you inherited an estate, repeat the inventory across every instance. An application name doesn't identify its underlying SQL Server release reliably. Include standby and reporting systems. They can remain old long after the primary application has moved.

Separate Mainstream and Extended Support

SQL Server releases under the Fixed Lifecycle Policy generally have mainstream and extended support phases. Mainstream is the broader phase of the support lifecycle. Extended support continues a narrower set of support and security servicing conditions. Read the policy rather than assuming both phases deliver the same kinds of fixes.

The end of mainstream support isn't the same as the end of all support. Equally, being inside extended support doesn't mean an application can demand a new product feature. Explain the distinction in operational terms: which issues can receive the kind of fix the business needs?

Use the exact dates on the product record, not release year plus mental arithmetic. Product timelines and servicing details deserve an authoritative check. A migration plan built around an approximate anniversary can miss the actual deadline.

Support Status and Patch Status Differ

SELECT
    SERVERPROPERTY('ProductUpdateLevel') AS update_level,
    SERVERPROPERTY('ProductUpdateReference') AS update_reference,
    SERVERPROPERTY('ProductVersion') AS full_build;

A supported major release can still have an old, vulnerable build installed. Compare the build with Microsoft's servicing table for the applicable branch. Conversely, the newest available build of an expired release doesn't restart its lifecycle. These are two separate questions in the inventory.

Check Windows and dependent drivers too. The database engine isn't the entire application platform. An unsupported operating system or connector can complicate incident handling even when SQL Server itself has support remaining. Record those dependencies with their owners.

Keep licensing entitlement separate again. A perpetual license and a current support phase aren't the same thing. The software continuing to run doesn't prove that new fixes or support services remain available under the conditions you need.

Understand What Happens at the End

The engine doesn't normally stop because its support date passes. The important change is the end of ordinary support and servicing coverage for that product phase. That leaves the organization carrying more operational and security risk. It isn't a scheduled shutdown built into your database.

Extended Security Updates can provide qualifying security updates for eligible releases and deployments after ordinary support ends. They don't extend the product lifecycle or recreate the whole original support offering. Check the program's terms, dates, and enrollment requirements for your exact situation.

Treat ESU as time to complete a transition, not a reason to stop planning one. Assign an owner to the migration and to the temporary coverage. If those responsibilities are separate, make sure both teams agree on the date the bridge ends.

Turn the Date Into a Work Plan

Start with application certification, supported upgrade paths, and a test environment. Leave time to identify dependencies and rehearse recovery. The lifecycle date is the end constraint, not the date to begin discovering which applications use the instance.

SELECT
    name, compatibility_level, state_desc,
    recovery_model_desc
FROM sys.databases
WHERE database_id > 4
ORDER BY name;

This database inventory gives the application review a starting list. It doesn't identify every external dependency. Add owners, connection destinations, jobs, and integration processes from operational records. A forgotten reporting export can delay a migration as effectively as the main application.

Review the Record After Changes

Update the inventory after upgrades and instance retirement. Keep evidence of the actual new build rather than marking a project complete from its planned date. Review lifecycle exposure regularly enough to catch newly discovered systems. The estate changes while the calendar keeps moving.

I prefer a short record with a verified date, an owner, and a next action. A color alone doesn't explain the consequence of an expired release. Make the record useful for arranging testing and downtime, not only for presenting a status slide.

A support date is not an upgrade plan, it is the deadline your plan must respect.

This post was rewritten from scratch in September 2026. The original, published on 2009-04-08, was a short announcement about something that no longer exists. The address is the same, the subject is now something worth keeping.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.