In addition to the improvements already tracked under SAT-25087, we have received recurring customer feedback highlighting gaps in the current documentation around deprecated features in Red Hat Satellite, specifically regarding how customers can determine whether a deprecated feature is actively in use in their environment.

Customers report that while deprecations are listed in release notes and surfaced by tools such as the upgrade helper, there is no clear or actionable guidance on how to verify whether a deprecated feature is actually being used. This often results in customers spending significant time researching, opening support cases, and waiting for confirmation from Red Hat support

Customer Feedback Summary

1. Lack of Clear Instructions

• Customers expect explicit guidance or a documented procedure to identify usage of deprecated features.

• Current documentation often requires searching through Jira cases, release notes, or external resources.

• This leads to unnecessary research and repeated support engagement.

2. Impact on Time and Productivity

• Customers report spending hours determining feature usage before engaging support.

• This impacts both customer productivity and Red Hat support efficiency.

Proposed Documentation Enhancements

1. Add "How to Determine If This Is in Use" Section for Each Deprecation

• For every deprecated feature listed in Satellite release notes, include a short, consistent section such as:

• • Configuration files or settings to check

• • CLI commands or UI locations

• • Log messages, services, or artifacts indicating usage

• This would provide immediate, actionable guidance without requiring support engagement.

2. Standardized Documentation Pattern

• Prefer a generalized documentation template that can be consistently applied across deprecations, for example:

• • Feature description

• • Deprecation timeline

• • How to determine if this feature is in use

• • Recommended alternatives or migration paths

• Where a generalized approach is not possible, document feature-specific detection methods.

3. Collaboration Between Docs and Engineering

• As part of the release notes process, documentation writers can ask feature owners:

  "If I am investigating a Satellite environment, what signs should I look for to determine whether this feature is in use?"

• The response can then be incorporated directly into the deprecation documentation.

4. Documentation-First Approach

• While automated checks (e.g., foreman-maintain) are useful in limited cases, they are not feasible for all deprecated features.

• Given varying definitions and levels of "feature usage," documentation is the most scalable and reliable solution.

Expected Benefits

• Reduced customer confusion and research time

• Fewer support cases related to deprecated features

• Faster upgrade readiness and smoother customer experience

• Improved clarity and consistency in Satellite deprecation documentation