Finding Deprecated Features Before They Bite

Finding deprecated features gives you time to replace dependencies before an upgrade turns them into failures. Use runtime evidence and code review together, because neither one sees every path through an application.

Deprecated Does Not Mean Removed

A deprecated feature remains available in the release that marks it, subject to the published conditions. Microsoft recommends moving away from it. A removed feature is no longer available in the target release. Those states create different deadlines and different testing needs.

Read the deprecation and discontinued-feature lists for the exact destination release. Don’t assume a feature survives because it worked on your source. Equally, don’t report every deprecated interface as an immediate outage. Describe the actual dependency and the release where it becomes a problem.

SELECT
    SERVERPROPERTY('ProductVersion') AS product_version,
    SERVERPROPERTY('Edition') AS edition;

SELECT name, compatibility_level
FROM sys.databases
WHERE database_id = DB_ID();

Keep the engine and compatibility level with the review. Compatibility level can preserve selected behaviors, but it doesn’t bring back a removed component. A migration assessment should consider both the database and the surrounding scripts and services.

Read the Runtime Counters

SELECT
    instance_name AS feature_name,
    cntr_value AS observed_uses
FROM sys.dm_os_performance_counters
WHERE object_name LIKE N'%:Deprecated Features%'
  AND cntr_value > 0
ORDER BY cntr_value DESC;

These counters identify deprecated feature use observed during their current lifetime. Save a timestamp and the server startup time alongside them. A restart changes the observation window. A monthly task that hasn’t run during that window can remain invisible.

A nonzero counter is a lead, not a complete call stack. Determine which application or job uses the feature. Frequency alone doesn’t set priority. A rarely used recovery script can be more important than a frequently executed but easily replaced diagnostic.

Use the documented visibility permissions for your SQL Server version. Keep collection errors visible. A query that couldn’t read the counters doesn’t establish that the instance has no deprecated dependencies.

Use Events to Find the Caller

Extended Events provides deprecation_announcement and deprecation_final_support events on supported versions. A targeted session can add context that aggregate counters lack. Verify the event metadata on your instance before designing a collection. Select only the actions and retention needed for the investigation.

SELECT
    p.name AS package_name,
    o.name AS event_name,
    o.description
FROM sys.dm_xe_objects AS o
JOIN sys.dm_xe_packages AS p ON p.guid = o.package_guid
WHERE o.object_type = N'event'
  AND o.name IN
      (N'deprecation_announcement', N'deprecation_final_support');

Plan the session’s overhead and output location rather than starting an unlimited capture. Query text and session context can contain private information. Store the result appropriately and stop collection when its purpose is complete. Review what ran during the observation window.

Search Definitions and the Application

SELECT
    OBJECT_SCHEMA_NAME(object_id) AS schema_name,
    OBJECT_NAME(object_id) AS object_name,
    definition
FROM sys.sql_modules
WHERE definition LIKE N'%sp_change_users_login%'
   OR definition LIKE N'%sp_depends%';

These patterns illustrate a search for older interfaces. They aren’t a complete deprecated-feature catalog. Read each match before classifying it because comments and harmless strings can match too. A simple text search doesn’t parse T-SQL semantics.

Definitions can be encrypted or hidden by permissions. Dynamic SQL can be assembled from fragments that don’t match one search term. Applications and external scripts can send statements absent from database modules. Include those sources in the review rather than overstating coverage.

Check Agent jobs, deployment scripts, and emergency runbooks as well. Old commands tend to survive in material nobody runs daily. A recovery procedure deserves a test on the target version even if the application workload never touches its code.

Replace Behavior, Not Only a Name

Read the recommended replacement’s permissions and semantics. A newer interface can return different columns or handle edge cases differently. Change the caller deliberately and test its expected behavior. Renaming a procedure call without reviewing how its output is consumed can create a quieter defect.

Prioritize removed features and dependencies that block the target migration. Then plan the remaining deprecated uses with owners and review dates. Keep evidence of the old behavior so tests can compare the replacement. The list should drive work rather than become another permanent report.

Avoid broad search-and-replace across application SQL. A pattern can appear in comments, examples, and different execution contexts. Make the smallest reviewed change that removes the dependency, then exercise the path that previously used it.

Recheck Through a Representative Cycle

Repeat runtime collection after the change and include the relevant scheduled processes. Keep the static review results too. No observed use is meaningful only within the window and paths you covered. Write that scope clearly instead of declaring the whole estate clean.

I want each remaining item to have a known caller and a reason it remains. That is much easier to manage than a counter nobody owns. Review the list before the next upgrade and whenever an old operational script returns to service.

A deprecation warning is not tomorrow’s outage, it is today’s chance to remove a dependency deliberately.

This post was rewritten from scratch in September 2026. The original, published on 2012-03-09, 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.