Skip to main content

How do we manage minor IT Component version changes in LeanIX?

  • August 11, 2026
  • 5 replies
  • 55 views

Hi Everyone,

I’m looking for guidance on how to handle minor version changes of IT Components in SAP LeanIX.

For example:

  • Java 8 Update 481
  • Java 8 Update 491
  • Java 8 Update 501

Do we create a separate fact sheet for each version/update, or only for major version changes?

Also, when do we decide to create separate fact sheets, and what is the best way to model version details if LeanIX is not integrated with a CMDB?

I’d appreciate any practical recommendations or best practices on how to keep this manageable without losing important lifecycle and version information.

Thanks in advance!

5 replies

Community Manager
Forum|alt.badge.img+2
  • priyankagupta
  • Community Manager
  • August 12, 2026

Hi Anjali,

We create a new IT Component fact sheet only when the version change materially affects lifecycle, supportability, or risk posture. The recommendation would be to have One fact sheet: "Java 8" — covering all update/patch releases within that major version. The patch level does not change the strategic picture (same EOL date, same vendor, same risk category). Creating 3 separate fact sheets would inflate your inventory without adding analytical value.
The SAP LeanIX Reference Catalog explicitly groups "minor, patch, and build versions" under the same Major.x or Major.minor.x product entry for precisely this reason. SAP LeanIX Help: IT Components in Reference Catalog.
 

Lifecycle Management Best Practices

  • Attach lifecycle dates at the major version level — use vendor end-of-support dates from the LeanIX Reference Catalog where available. Java 8 (Oracle SE) has a well-documented support timeline.
  • Set your own internal "Target Date" for migration — LeanIX lets you overlay internal lifecycle phases on top of vendor lifecycle data.
  • If you later integrate a CMDB (e.g., ServiceNow), the standard recommendation is: CMDB = source of truth for version instances; LeanIX = risk and dependency layer. The CMDB sync should bring in version as an attribute, not as separate fact sheets. SAP LeanIX Help: Obsolescence Risk Management – Import Software Assets

    I hope the above would help. If there are more questions then let me know.

    Priyanka
  • AnjaliN
  • Author
  • Rookie
  • August 13, 2026

Thanks Priyanka. 

    Carsten
    Forum|alt.badge.img+2
    • Carsten
    • Everlasting Love
    • August 18, 2026

    Hello ​@AnjaliN,
    we do not track minor version. But in the cases we need it, we use the version field to the relation. If we have a self written apllication and it is linked to Java8 component 501:
     

    Anyway this means much more maintenance.
    Best regards,

    Carsten

    Carsten Schubert
      Michelle Rahman
      Community Manager
      Forum|alt.badge.img

      🙂 I agree with the recommendations above. From a governance perspective, I've generally seen the most success when the IT Component Catalog focuses on technologies that drive lifecycle, risk, and standardization decisions. In practice, this means maintaining separate fact sheets for major versions (e.g., Java 8, Java 11, Java 17) while tracking patch or update levels as attributes on relationships, Systems, or through CMDB/discovery integrations when greater granularity is required.

      A useful rule of thumb is to ask whether the version change impacts support status, lifecycle dates, risk posture, or modernization planning. If it does, a separate fact sheet may be warranted. If it does not, creating additional IT Components often increases maintenance effort without adding meaningful analytical value.

      The goal is to keep the IT Reference Catalog focused on architecture and technology management while leaving instance level version tracking to operational sources or relationship data. This typically provides the best balance between reporting value and maintainability.

      • AnjaliN
      • Author
      • Rookie
      • August 19, 2026

      🙂 I agree with the recommendations above. From a governance perspective, I've generally seen the most success when the IT Component Catalog focuses on technologies that drive lifecycle, risk, and standardization decisions. In practice, this means maintaining separate fact sheets for major versions (e.g., Java 8, Java 11, Java 17) while tracking patch or update levels as attributes on relationships, Systems, or through CMDB/discovery integrations when greater granularity is required.

      A useful rule of thumb is to ask whether the version change impacts support status, lifecycle dates, risk posture, or modernization planning. If it does, a separate fact sheet may be warranted. If it does not, creating additional IT Components often increases maintenance effort without adding meaningful analytical value.

      The goal is to keep the IT Reference Catalog focused on architecture and technology management while leaving instance level version tracking to operational sources or relationship data. This typically provides the best balance between reporting value and maintainability.

      I agree Miechelle.

      Terms & ConditionsAccessibility statement