End-of-Support Management Module (ESMM)

OOF® Origin Open Foundation®

Independent Methodological Authority

Architecture: SLGA™ — Software Lifecycle Governance Architecture
Parent Standard: Software Retirement Standard (SRTS)
Category: Governance & Enforcement
Subcategory: Software Retirement Governance
Type: Core Module
Governed Space: Software End-of-Support Governance
Module ID: SLGA-SRTS-ESMM-02
Origin ID: OOF-SLGA-SRTS-ESMM
Version: 1.0
Status: Canonical Open
Effective Date: 15.10.2026
Compatibility: Methodology OS — Modular Compatibility
GIE-Compatible: Yes
AI-Readable: Yes
Authority: OOF® — OriginOpen® Foundation
Protection: Protected Methodological Work
Canonical Language: UCL — Universal Canonical Language (English)

Canonical Definition

End-of-Support Management Module (ESMM) is the Core Module within
Software Retirement Standard (SRTS) that governs how changes to the
availability, scope, responsibility, and termination of software
support and maintenance are identified, evaluated, communicated,
controlled, and preserved throughout the software retirement
lifecycle.

ESMM establishes end-of-support as an identifiable governance condition

affecting the relationship between a software object, its support
provider, supported capabilities, maintenance obligations, security
update availability, operational users, dependent systems, and
continuing responsibilities.

The module distinguishes support termination from maintenance termination,

support availability from support effectiveness, vendor support status
from actual operational use, and the end of a support obligation from
the elimination of operational risk.

It requires support transitions to remain connected to identifiable

software versions, support arrangements, applicable time or event
conditions, affected stakeholders, available assistance, known
limitations, continued operational dependencies, and required
retirement or replacement pathways.

ESMM recognizes that software may remain in production after formal
support ends, that different support capabilities may terminate at
different times, and that third-party, internal, community, or
extended support may provide different levels of continuing
assistance.

It also recognizes that unsupported software may remain subject to
operational, security, contractual, evidentiary, and continuity
obligations even when ordinary maintenance is no longer available.

ESMM governs the classification and controlled treatment of these

conditions without treating the cessation of support as proof that
software has been retired.

It applies to enterprise applications, commercial software, open-source

components, cloud services, operating systems, firmware, AI systems,
autonomous software agents, and embedded or industrial software.

Its principal governance output is the Software End-of-Support
Profile.

Operational Role

ESMM establishes the governance framework for software support transitions

and the continuing conditions that arise when support is reduced,
modified, transferred, or terminated.

It governs:

Support object identification
Support provider identification
Support arrangement recognition
Support scope definition
Support capability classification
Support lifecycle conditions
End-of-support recognition
End-of-maintenance recognition
Support status verification
Support transition planning
Support termination conditions
Support responsibility
Support authority boundaries
Support communication
Support dependency assessment
Continued unsupported operation
Security update availability
Critical correction availability
Extended support
Alternative support
Support transfer
Operational restrictions
Unsupported software risk
Support evidence
Support status monitoring
Support exceptions
Support reassessment
Support closure
Handoff to retirement governance

ESMM does not independently withdraw software from operation or
establish that software retirement has been completed.

Operational Question

How can software support and maintenance transitions remain
identifiable, evidence-supported, and governable when support
capabilities, providers, contractual conditions, security update
availability, operational dependencies, and continuing
responsibilities may change or terminate while the software itself
remains in use?

Position in Architecture Governance Flow

SLGA™ Governance Flow

Software Requirements → Software Creation → Software Dependencies →

Software Configuration → Software Quality → Software Security →
Software Release → Software Deployment → Software Change Management →
Software Retirement

Cross-cutting: Software Lifecycle Control

SRTS Core Module Flow

Retirement Planning Module (RPM) → End-of-Support Management Module (ESMM)

→ Software Migration Module (SMM) → Residual Dependency Management
Module (RDMM) → Retirement Closure Control Module (RCCLM)

ESMM is the second Core Module within SRTS.

It governs the support conditions identified during retirement planning and

establishes their implications for continued operation, migration,
dependency management, and retirement closure.

Its governance remains applicable when software support ends before
retirement planning begins or when support continues after operational
withdrawal.

Governed Space

Software End-of-Support Governance

This governed space concerns the identification, modification, reduction,

transfer, and termination of software support and maintenance
capabilities.

It begins when a software support condition becomes relevant to an
identifiable software object.

It includes support scope, provider responsibility, service availability,

maintenance capability, security updates, transition conditions,
affected stakeholders, operational restrictions, and continuing
obligations.

It remains active where software continues operating after support
ends or where support-related responsibilities remain unresolved.

It concludes for a defined support relationship only when the
applicable support transition has been established and remaining
obligations have been appropriately resolved, transferred, or
preserved under governance.

Governed Object

The primary Governed Object is:

A Software Support Transition Case representing the evidence-supported

relationship between an identifiable software object, its applicable
support arrangement, support provider, support capabilities, changing
support conditions, affected operational dependencies, transition
requirements, continuing responsibilities, and resulting support
status.

The governed object must preserve, where applicable:

Support Transition Case ID

Software Object ID

Software Version

Support Provider

Support Arrangement Reference

Current Support Status

Support Scope

Maintenance Status

Security Update Status

Support Transition Origin

Support Change Condition

Effective Support Transition Time

Affected Users and Systems

Continuing Operational Use

Operational Restrictions

Residual Support Obligations

Responsible Function

Support Evidence

Support Status Version

Scope

Software Support Identification

Support Provider Identification

Support Arrangement Classification

Support Capability Assessment

Support Lifecycle Recognition

End-of-Support Recognition

End-of-Maintenance Recognition

Security Update Availability

Support Transition Conditions

Support Responsibility Transfer

Extended Support

Alternative Support

Unsupported Software Operation

Operational Restriction Requirements

Stakeholder Communication

Support Evidence Preservation

Support Status Verification

Support Exception Management

Support Reassessment

Support Transition Closure

The module does not create contractual obligations or determine legal
liability.

It preserves the governance relationships necessary to identify and

evaluate such obligations through applicable specialized mechanisms.

Foundational Principle

The termination of software support changes the conditions under which

software can be maintained, corrected, secured, and relied upon; it
does not automatically terminate the software's operational presence
or the responsibilities associated with its continued use.

Support status must be established according to the actual
capabilities and obligations available for the identified software
object.

Support Terminated ≠ Software Withdrawn.

Support Available ≠ Support Sufficient.

Vendor Support Ended ≠ All Support Capability Eliminated.

Support Transition Case Identity

Every governed support transition must have a stable identity.

Relevant elements include:

Support Transition Case ID

Software Object Reference

Support Provider Reference

Support Arrangement Reference

Transition Origin

Transition Status

Effective Condition

Responsible Function

Evidence Reference

Record Version

The identity must remain stable across support announcements,
reassessments, transfers, and closure.

Supported Software Identification

ESMM must identify the software object to which the support condition
applies.

Relevant elements include:

Product Name

Software Object ID

Build

Edition

Deployment Model

Supported Platform

Environment

Support Contract Reference

Applicable Support Channel

A general product-level announcement must not automatically be applied
to every version or deployment without establishing its actual scope.

Support Provider Identification

ESMM must identify the provider or function responsible for the
relevant support capability.

Potential providers include:

Original Software Vendor

Internal Engineering Team

Third-Party Support Provider

Open-Source Maintainer

Community Support Network

Infrastructure Provider

Managed Service Provider

Extended Support Provider

Successor Organization

Provider identity must remain distinguishable from software ownership
and operational responsibility.

Support Arrangement

A support arrangement establishes the applicable relationship under which

assistance or maintenance is provided.

Relevant elements include:

Support Provider

Supported Software

Supported Versions

Covered Capabilities

Support Conditions

Support Period

Service Restrictions

Response Commitments

Exclusions

Termination Conditions

Applicable Evidence

ESMM must not infer contractual support obligations solely from the
existence of technical assistance.

Support Capability Classification

Support may include different capabilities.

Relevant categories include:

Technical Assistance

Defect Investigation

Corrective Maintenance

Security Updates

Compatibility Updates

Performance Corrections

Configuration Assistance

Incident Response

Recovery Assistance

Documentation

Operational Guidance

Migration Assistance

Support status must reflect which capabilities remain available rather
than relying only on a binary supported/unsupported label.

Support Scope

ESMM must establish the scope of the applicable support relationship.

Relevant dimensions include:

Software Product

Edition

Platform

Deployment Environment

Supported Configuration

Support Capability

Customer or User Group

Geographic or Contractual Scope

Time Period

A support capability available for one software configuration must not
automatically be assumed applicable to another.

Support Lifecycle Conditions

Software support may pass through multiple identifiable conditions.

Potential conditions include:

Full Support

Standard Maintenance

Limited Support

Security-Only Support

Extended Support

Third-Party Support

Community Support

Support Transition Pending

End of Maintenance

End of Support

Unsupported Operation

These conditions must remain associated with their actual capabilities
and restrictions.

End-of-Support Recognition

ESMM must identify the condition under which a support arrangement
ends.

Potential triggers include:

Scheduled Support Expiration

Contract Termination

Vendor Announcement

Product Discontinuation

Version Obsolescence

Provider Withdrawal

Service Termination

Support Eligibility Change

External Requirement

Loss of Required Support Capability

Recognition must distinguish announced future termination from support
that has already ended.

End-of-Support Effective Condition

The effective end-of-support condition must be established through
applicable evidence.

Relevant elements include:

Effective Date

Effective Event

Affected Software

Affected Versions

Affected Support Capabilities

Provider Reference

Applicable Exceptions

Transition Arrangements

Evidence Source

A scheduled end date must not be confused with a verified current
support status.

End-of-Maintenance Recognition

ESMM must separately identify maintenance termination.

Relevant elements include:

Maintenance Provider

Maintenance Scope

Corrective Update Availability

Compatibility Maintenance

Security Maintenance

Maintenance End Condition

Remaining Support Capabilities

Continuing Operational Use

End of maintenance may occur before, after, or simultaneously with
other support changes.

Support and Maintenance Distinction

ESMM must preserve the difference between support and maintenance.

Support may involve assistance, diagnosis, guidance, recovery, and
communication.

Maintenance may involve software modification, correction, updating,
and continued technical adaptation.

A software product may retain technical assistance while no longer
receiving ordinary maintenance updates.

Conversely, a software component may continue receiving community
maintenance without a formal support service.

Support Capability ≠ Maintenance Capability.

Security Update Availability

ESMM must identify the availability of security-related corrections.

Relevant elements include:

Security Update Provider

Supported Versions

Update Eligibility

Known Vulnerability Coverage

Update Distribution Channel

Update Frequency or Conditions

Security-Only Support

Update Termination Condition

Known Limitations

Security update availability must not be inferred solely from a
general support label.

Critical Correction Availability

Some support arrangements may preserve limited critical corrections
after ordinary maintenance ends.

Relevant elements include:

Critical Defect Criteria

Eligible Software Versions

Correction Provider

Applicable Conditions

Correction Availability

Approval Requirements

Delivery Restrictions

Evidence

Critical correction availability must remain distinct from
comprehensive maintenance support.

Support Status Verification

ESMM must establish the actual support condition through appropriate
evidence.

Potential evidence includes:

Vendor Lifecycle Notices

Support Contracts

Service Agreements

Provider Statements

Maintenance Records

Update Availability Records

Technical Support Records

Published Lifecycle Documentation

Internal Support Capability Assessments

Unverified support assumptions must remain classified as uncertain.

Support Evidence Applicability

Support evidence must be evaluated against:

Software Identity

Edition

Platform

Deployment Environment

Provider

Support Arrangement

Capability

Effective Time

Known Exceptions

Evidence that one version is supported does not establish support for
every version.

Support Transition Origin

A support transition may originate from:

Vendor Lifecycle Policy

Contract Expiration

Maintenance Termination

Provider Insolvency or Withdrawal

Technology Obsolescence

Security Capability Loss

Infrastructure Change

Software Retirement Decision

Organizational Restructuring

External Requirement

The origin must remain traceable to the resulting support status.

Support Transition Purpose

A support transition may serve different purposes.

Potential purposes include:

Terminate Obsolete Support

Move to Extended Support

Transfer Support Responsibility

Reduce Maintenance Scope

Prepare Software Retirement

Support Software Migration

Maintain Restricted Legacy Operation

Consolidate Support Providers

The purpose must remain distinguishable from the actual transition
outcome.

Support Transition Assessment

ESMM must evaluate the consequences of the proposed or occurring
support change.

Relevant dimensions include:

Operational Impact

Security Impact

Maintenance Impact

Dependency Impact

User Impact

Recovery Impact

Migration Impact

Economic Impact

Continuity Impact

External Obligation Impact

Assessment must reflect the software's actual operational role.

Continued Operational Use

ESMM must identify whether software remains operational after support
changes.

Relevant elements include:

Active Deployments

Operational Functions

Active Users

Dependent Systems

Scheduled Tasks

External Interfaces

Data Processing

Recovery Dependencies

Physical-System Functions

Operational Owner

Continued operation must remain an explicit governance condition.

Unsupported Software Operation

Unsupported operation exists when software remains operational without
the applicable support capability required or previously available for
its use.

ESMM must preserve:

Software Identity

Operational Environment

Unavailable Support Capabilities

Known Security Conditions

Operational Dependencies

Responsible Function

Applicable Restrictions

Retirement or Replacement Pathway

Review Conditions

Unsupported operation must not be concealed behind an obsolete
inventory status.

Unsupported Operation Classification

Unsupported operation may be classified as:

Unsupported — Operational

Unsupported — Restricted Operation

Unsupported — Migration Pending

Unsupported — Retirement Pending

Unsupported — Critical Dependency

Unsupported — Isolated

Unsupported — Under Exception

Unsupported — Status Unverified

Each classification must remain evidence-supported and scope-specific.

Support Dependency Assessment

ESMM must identify systems and processes affected by the support
condition.

Relevant elements include:

Dependent Applications

Operational Processes

External Customers

Integration Partners

Data Consumers

Infrastructure Components

Recovery Systems

Embedded Devices

Autonomous Systems

A support change may affect systems that do not directly interact with
the support provider.

Support Risk Recognition

ESMM must identify material risks associated with reduced or
terminated support.

Potential risks include:

Uncorrected Vulnerabilities

Unresolved Defects

Compatibility Degradation

Unavailable Technical Expertise

Recovery Limitations

Operational Instability

Dependency Failure

Data Accessibility Risk

Unsupported Infrastructure

Physical-System Consequences

Risk identification must not be mistaken for formal risk acceptance.

Security Exposure After Support Termination

ESMM must identify security exposure arising from support changes.

Relevant elements include:

Known Vulnerabilities

Missing Security Updates

Unsupported Cryptographic Components

Exposed Interfaces

Unmaintained Dependencies

Credential Risks

Monitoring Limitations

Compensating Controls

Retirement Requirements

Detailed vulnerability assessment and remediation remain governed by

applicable security mechanisms.

Operational Restriction Requirements

Unsupported software may require operational restrictions.

Potential restrictions include:

Network Isolation

Restricted User Access

Limited Functionality

Read-Only Operation

Reduced External Connectivity

Enhanced Monitoring

Controlled Execution Windows

Restricted Data Processing

Mandatory Review Conditions

Restrictions must be justified by the actual software conditions and
applicable authority.

Extended Support

Extended support may preserve selected capabilities beyond the
ordinary support period.

Relevant elements include:

Extended Support Provider

Covered Software

Covered Versions

Available Capabilities

Security Update Availability

Service Conditions

Effective Period

Exclusions

Termination Conditions

Extended support must not automatically be treated as equivalent to
full support.

Alternative Support

Alternative support may be provided by a different internal or
external function.

Potential sources include:

Internal Engineering Team

Third-Party Maintenance Provider

Community Maintainers

Specialized Legacy Support Provider

Successor Vendor

Managed Service Provider

Alternative support must be evaluated for capability, scope,
reliability, authority, and applicable obligations.

Support Provider Transition

Where support responsibility changes, ESMM must preserve:

Previous Provider

Successor Provider

Affected Software

Transferred Capabilities

Excluded Capabilities

Transition Conditions

Required Documentation

Operational Contacts

Evidence Transfer

Effective Responsibility State

A change of provider does not automatically establish continuity of
every support capability.

Support Capability Continuity

ESMM must assess whether required support capabilities remain
available during a provider or arrangement transition.

Relevant elements include:

Technical Knowledge

Source Code Access

Build Capability

Required Tools

Security Update Capability

Diagnostic Capability

Recovery Knowledge

Dependency Information

Operational Documentation

Responsible Personnel

Support continuity must be assessed against actual capabilities rather
than provider identity alone.

Support Responsibility

Every material support relationship must have an identifiable
responsibility reference.

Relevant elements include:

Support Provider

Operational Owner

Maintenance Responsible Function

Security Responsible Function

Incident Response Responsibility

Migration Responsible Function

Retirement Responsible Function

Escalation Responsibility

Responsibility assignment must remain distinguishable from capability
and authority.

Support Authority Boundary

ESMM must identify applicable authority conditions.

Relevant elements include:

Support Arrangement Authority

Maintenance Authorization

Security Update Authorization

Operational Restriction Authority

Support Transfer Authority

Retirement Decision Authority

External Approval Requirements

Delegation Conditions

Authority to terminate support does not automatically establish
authority to withdraw operational software.

Stakeholder Identification

ESMM must identify stakeholders affected by support changes.

Potential stakeholders include:

Software Owners

Operational Teams

Users

Customers

Support Providers

Maintenance Providers

Security Functions

Integration Partners

Data Owners

Infrastructure Operators

Stakeholder identification must reflect material operational and
contractual relationships.

Support Transition Communication

ESMM must establish communication requirements where applicable.

Relevant elements include:

Affected Software

Support Change

Effective Condition

Unavailable Capabilities

Continuing Capabilities

Operational Restrictions

Migration Requirements

Required Stakeholder Actions

Communication Responsibility

Communication Evidence

A support announcement must not be treated as evidence that affected
systems have completed their transition.

Support Notice Traceability

Support notices must remain traceable to the applicable software and
support relationship.

Relevant elements include:

Notice ID

Issuing Provider

Software Identity

Affected Versions

Support Change

Effective Time

Recipients

Required Actions

Evidence Reference

Notice Version

Material corrections or changes must preserve the relationship to
earlier notices.

Support Transition Timing

ESMM must identify material support transition timing.

Relevant elements include:

Announcement Time

Support Change Effective Time

Maintenance End Time

Security Update End Time

Extended Support Period

Migration Deadline

Retirement Target

Review Conditions

Different support capabilities may terminate at different times.

Support Transition Readiness

ESMM must assess readiness for a material support change.

Relevant elements include:

Affected Software Identified

Support Scope Established

Operational Use Identified

Dependencies Assessed

Security Implications Identified

Affected Stakeholders Identified

Communication Requirements Established

Continuing Responsibilities Assigned

Operational Restrictions Prepared

Retirement or Migration Pathway Identified

Readiness must remain distinct from the support transition's actual
effective state.

Support Transition Preconditions

Material support transitions may require preconditions.

Potential preconditions include:

Applicable Support Decision

Required Notice

Alternative Support Availability

Operational Restriction Readiness

Migration Preparation

Security Review

Continuity Arrangement

Responsibility Transfer

Evidence Preservation

Competent Authority

The applicability of each precondition depends on the support arrangement

and governed operational context.

Support Transition Execution

ESMM governs the recognition and evidence of support changes taking
effect.

Relevant elements include:

Transition Event

Affected Support Capabilities

Effective Condition

Provider Responsibility

Operational Consequences

Continuing Obligations

Status Verification

Transition Evidence

Support transition execution does not establish software withdrawal.

Support Status Monitoring

ESMM must support monitoring where support conditions remain relevant
to operational software.

Potential monitoring concerns include:

Support Expiration

Security Update Availability

Extended Support Changes

Provider Capability Changes

Unsupported Deployments

Operational Restrictions

Migration Progress

Retirement Progress

Newly Discovered Dependencies

Monitoring must remain proportionate to the software's operational
significance.

Support Condition Change

Support conditions may change after an initial classification.

Potential changes include:

Support Extension

Early Support Termination

New Security-Only Support

Provider Replacement

Support Scope Reduction

Support Capability Restoration

Contractual Modification

New Eligibility Requirement

Material changes must trigger reassessment where earlier conclusions
are affected.

Support Reassessment

ESMM must support reassessment when:

Support Evidence Changes

Provider Capability Changes

Software Version Changes

Operational Use Changes

Security Conditions Change

Dependencies Change

Migration Is Delayed

Retirement Is Deferred

Alternative Support Becomes Available

Reassessment must preserve the earlier support status and the evidence
supporting its revision.

Support Exception Governance

An exception may be necessary when ordinary support transition
requirements cannot be satisfied.

Relevant elements include:

Exception ID

Affected Support Condition

Reason

Applicable Authority

Alternative Control

Operational Restriction

Residual Risk

Validity Condition

Review Requirement

Evidence

An exception must not create an unsupported assumption that software
remains adequately supported.

Emergency Support Conditions

Exceptional operational circumstances may require temporary support
arrangements.

Potential conditions include:

Critical Security Incident

Operational Recovery

Unexpected Provider Withdrawal

Critical Software Failure

Migration Failure

Essential Service Continuity

Emergency support must remain subject to identifiable authority,
scope, evidence, and subsequent review.

Support Evidence Integrity

ESMM must preserve the integrity of material support evidence.

Relevant elements include:

Evidence Source

Software Identity

Provider Identity

Support Capability

Effective Time

Applicable Scope

Known Limitations

Verification Method

Record Version

Unsupported or contradictory evidence must remain identifiable.

Support Status Uncertainty

ESMM must explicitly represent uncertainty.

Potential conditions include:

Unknown Support Provider

Unverified Support Contract

Unclear Version Eligibility

Conflicting Vendor Notices

Unknown Security Update Availability

Unverified Extended Support

Unclear Maintenance Capability

Unknown Effective Date

Material uncertainty must not be converted into a definitive supported
or unsupported classification without evidence.

Support Status Classification

ESMM recognizes the following governance classifications:

Full Support

Standard Support

Limited Support

Security-Only Support

Extended Support

Alternative Support

Community Support

Support Transition Pending

Support Scope Changing

End of Maintenance

End of Support

Unsupported — Operational

Unsupported — Restricted

Unsupported — Migration Pending

Unsupported — Retirement Pending

Support Transferred

Support Terminated

Support Status Unverified

Exception Active

Reassessment Required

Unknown

Conflicted

Each classification must remain connected to its applicable software
object, capability, provider, scope, and time.

Support Transition Closure

A support transition may be closed when its applicable support change
has been established and its continuing obligations have been
appropriately addressed.

Closure must preserve:

Support Transition Identity

Previous Support Condition

Resulting Support Condition

Affected Software

Effective Transition Evidence

Communication Evidence

Continuing Operational Use

Residual Support Obligations

Responsible Functions

Closure Decision

Support transition closure must not be treated as retirement closure.

Continuing Support Obligations

Some obligations may continue after ordinary support ends.

Potential obligations include:

Contractual Assistance

Security Notification

Historical Documentation

Data Access Support

Migration Assistance

Incident Cooperation

Regulatory Requirements

Evidentiary Preservation

ESMM identifies and preserves these relationships without independently

determining their legal enforceability.

Support and Retirement Relationship

ESMM must preserve the relationship between support transitions and
software retirement.

Potential conditions include:

Support Active — Software Operational

Support Limited — Software Operational

Support Ended — Software Operational

Support Ended — Migration Active

Support Ended — Withdrawal Pending

Support Ended — Software Withdrawn

Support Obligations Continuing — Software Retired

These conditions must remain independently identifiable.

Support and Migration Relationship

Support conditions may materially affect migration.

Relevant elements include:

Migration Assistance Availability

Compatibility Guidance

Data Export Support

Technical Expertise

Migration Tool Availability

Security Update Coverage

Recovery Assistance

Provider Cooperation

The end of support may reduce migration feasibility without
eliminating the need for migration.

Support and Dependency Relationship

Support changes may affect software dependencies.

Relevant elements include:

Unsupported Libraries

Unsupported Runtime Platforms

Unsupported Operating Systems

Unmaintained Interfaces

Legacy Service Dependencies

Unsupported Firmware

Unmaintained AI Components

External Support Dependencies

Dependency consequences must remain visible to applicable dependency
and retirement governance mechanisms.

Support and Operational Reality

ESMM must distinguish declared support status from actual operational
conditions.

A software product may be officially unsupported but remain
operationally critical.

A product may be listed as supported while essential correction
capabilities are unavailable.

A vendor may announce extended support that applies only to specific
versions or configurations.

An internally maintained component may remain technically serviceable
without a formal external support contract.

Support governance must therefore evaluate the actual support
relationship and available capabilities.

Declared Support Status ≠ Verified Support Capability.

Governance Requirements

A conforming ESMM implementation must satisfy the following
requirements. Support Identity and Scope

Establish a stable support transition case identity
Identify the applicable software object
Identify the relevant software version or configuration
Identify the support provider
Identify the applicable support arrangement
Define support scope
Classify available support capabilities
Preserve support evidence

Support Transition

Identify support transition origin
Establish the applicable transition condition
Distinguish announced and effective support changes
Identify end-of-maintenance conditions
Identify end-of-support conditions
Identify security update availability
Identify continuing support capabilities
Preserve transition timing and scope

Operational Consequences

Identify continuing operational use
Identify affected dependencies
Identify affected users and systems
Identify material support-related risks
Identify required operational restrictions
Preserve migration and retirement implications
Identify continuing support obligations
Preserve relevant uncertainty

Responsibility and Communication

Identify responsible support functions
Identify applicable support authority
Establish stakeholder communication requirements
Preserve material support notices
Identify responsibility transfer conditions
Evaluate alternative support capability where applicable
Preserve applicable exceptions
Maintain support status traceability

Verification and Continuity

Verify material support status conclusions
Preserve support capability distinctions
Establish reassessment triggers
Preserve support status changes
Identify support transition closure conditions
Preserve residual support obligations
Prevent support termination from being treated as operational
Maintain continuity with retirement planning, migration,
dependency

withdrawal. management, and closure.

Governance Logic

Software Identity → Support Provider → Support Arrangement → Support Scope

→ Support Capabilities → Current Support Condition → Support
Transition Origin → Transition Assessment → Effective Condition →
Operational Consequences → Dependency Assessment → Security and
Maintenance Implications → Continuing Responsibilities → Communication
→ Transition Verification → Resulting Support Status → Residual
Obligations → Software End-of-Support Profile

Where support remains active:

Support Capability → Scope Verification → Operational Applicability →

Continued Support Classification

Where support is reduced:

Support Change → Capability Difference → Impact Assessment → Restrictions

/ Alternative Support → Updated Status

Where support ends but software remains operational:

End of Support → Continued Operational Use → Dependency and Security

Assessment → Responsible Function → Restrictions → Migration or
Retirement Pathway

Where support transfers:

Previous Provider → Successor Provider → Capability Assessment →

Responsibility Transfer → Continuity Verification

Where evidence is insufficient:

Support Claim → Evidence Gap → Unverified Classification → Further

Assessment

Where support conditions change:

Existing Support Status → New Evidence → Reassessment → Updated Support

Profile

ESMM must not equate support termination with software retirement.

Governance Outputs

The principal output is:

Software End-of-Support Profile

Supporting outputs may include:

Support Transition Case Identity

Supported Software Identity Record

Support Provider Profile

Support Arrangement Record

Support Capability Matrix

Support Scope Record

Support Lifecycle Status

End-of-Support Condition Record

End-of-Maintenance Condition Record

Security Update Availability Profile

Support Transition Impact Assessment

Unsupported Software Operation Register

Support Risk Record

Operational Restriction Record

Extended Support Profile

Alternative Support Assessment

Support Responsibility Transfer Record

Support Communication Register

Support Status Evidence Register

Support Exception Register

Continuing Support Obligation Record

Support Transition Closure Record

Minimum Implementation Framework

A minimum ESMM implementation must establish eight governance layers.
Layer 1 — Software and Support Identity

Identify the software object, applicable version, support provider, and

support arrangement. Layer 2 — Support Capability Definition

Establish which support and maintenance capabilities are available,
restricted, or unavailable. Layer 3 — Support Transition Recognition

Identify the origin, effective condition, scope, and timing of material

support changes. Layer 4 — Operational Consequence Assessment

Identify continuing software use, dependencies, affected stakeholders,

security exposure, and operational restrictions. Layer 5 —
Responsibility and Authority

Establish support responsibility, applicable authority, provider transfer

conditions, and continuing obligations. Layer 6 — Transition
Communication

Preserve material notices, affected recipients, required actions, and

communication evidence. Layer 7 — Support Status Verification

Verify the resulting support condition and preserve uncertainty,

exceptions, and reassessment requirements. Layer 8 — Support
Continuity and Handoff

Maintain the Software End-of-Support Profile and transfer relevant

requirements into migration, dependency management, and retirement
closure governance.

The framework may be implemented through software inventories, service
management systems, vendor lifecycle records, contractual registers,
automated monitoring, or AI-assisted assessment.

Implementation technology must adapt to the governed support reality.

Cross-Module Boundary

RPM → ESMM

RPM identifies support and maintenance conditions relevant to retirement

ESMM governs the detailed recognition, assessment, transition, and

continuing consequences of those support conditions.

ESMM → SMM

ESMM identifies support capabilities, limitations, and transition

conditions affecting migration.

SMM governs the actual migration of software functions, data, users, and

operational dependencies.

ESMM → RDMM

ESMM identifies unsupported software relationships and dependencies

affected by support termination.

RDMM governs residual dependencies that remain associated with
software retirement.

ESMM → RCCLM

ESMM establishes the resulting support status and continuing support

RCCLM evaluates whether these obligations have been appropriately addressed

within the retirement closure determination.

End-of-support governance establishes the support condition. It does
not establish that the software has ceased operating or that
retirement is complete.

Cross-Architecture Boundary

ESMM governs support and maintenance transitions within SRTS.

It may interact with other SLGA™ Parent Standards.

SRS — Software Requirements Standard

functionality, and replacement systems.

SCS — Software Creation Standard

Creation of corrective, replacement, or migration software.

SDS — Software Dependency Standard

Support-related dependency identity, continuity, and risk.

SCFS — Software Configuration Standard

Supported configurations, version identity, and configuration changes.

SQS — Software Quality Standard

Quality requirements and verification of maintained or replacement
software.

SSS — Software Security Standard

Security exposure, vulnerability management, and remediation.

SRLS — Software Release Standard

Release governance for updates and replacement software.

SDPS — Software Deployment Standard

Deployment and operational transition of updates or replacement
systems.

SCMS — Software Change Management Standard

Governance of software changes resulting from support transitions.

SLCS — Software Lifecycle Control Standard

Lifecycle state consistency, transition control, exceptions, and
continuity.

ESMM may also interact with applicable OOF® authority, accountability,
operational reality, identity, and autonomous systems governance
mechanisms.

It does not replace their specialized governance functions.

Practical Applications

Enterprise Software Support Lifecycle

Managing support expiration, extended support, and continued operation of

legacy applications.

Cloud Service Discontinuation

Governing support transitions and operational consequences when cloud
providers discontinue products or service capabilities.

Open-Source Software

Identifying the actual maintenance and security support available for

community-maintained components.

Software Supply Chains

Managing dependencies on libraries, runtimes, and platforms that no
longer receive maintenance or security updates.

AI Systems

Governing support transitions for AI models, inference services,

orchestration software, and dependent applications.

Autonomous Software Agents

Identifying continuing operational responsibilities when agent
software or its underlying components lose support.

Industrial and Embedded Systems

Managing firmware and software that remain operational within
equipment after vendor support ends.

Critical Infrastructure

Preserving visibility into unsupported software, operational restrictions,

and required replacement or retirement pathways.

Practical Use Case 1 — Unsupported Industrial Software

An industrial facility operates equipment controlled by software that
is no longer supported by its original vendor.

The equipment continues performing an essential production function.

A software inventory lists the product as obsolete, but the organization

has not established whether security updates, technical assistance, or
corrective maintenance remain available.

ESMM establishes:

Software Identity → Support Provider → Support Scope → Support

Capabilities → End-of-Support Condition → Operational Dependencies →
Continuing Responsibilities

The assessment identifies:

Ordinary vendor maintenance has ended
Security updates are no longer provided for the installed
version
The equipment remains operationally necessary
Immediate software replacement is not technically feasible
A third-party provider can supply limited diagnostic assistance
but
Continued operation requires explicit restrictions and a
governed

cannot provide comprehensive security corrections. replacement
pathway.

The resulting support classification is:

Unsupported — Restricted Operation; Alternative Diagnostic Support

The Software End-of-Support Profile preserves the actual support

capabilities, operational restrictions, responsible function, and
continuing retirement requirements.

Alternative Technical Assistance ≠ Full Software Support.

Practical Use Case 2 — AI Service Support Termination

An organization relies on an external AI inference service integrated into

several internal applications.

The service provider announces that support for the current model
version will end.

A successor model is available, but it uses a modified interface and
produces different output characteristics.

ESMM establishes:

Model Service Identity → Supported Version → Provider Notice → Support End

Condition → Affected Consumers → Security and Maintenance Implications
→ Migration Requirements

The assessment identifies:

The support announcement applies only to the older model version
Existing applications continue calling the old endpoint
Technical assistance will remain available temporarily, but
Several applications require compatibility assessment before
migration
The provider's announced support termination does not establish
that

model-specific corrections will stop. all dependent applications have
transitioned.

The resulting support classification is:

Support Transition Pending — Migration and Compatibility Requirements

ESMM preserves the transition conditions and directs the applicable

migration and dependency requirements to subsequent governance.

Successor Model Available ≠ Existing Integration Ready for Retirement.

Critical Distinctions

Support Announcement ≠ Effective Support Termination.

Support Available ≠ Support Sufficient.

Support Provider Identified ≠ Support Capability Verified.

Support Contract Active ≠ Every Software Version Supported.

Vendor Support Ended ≠ All Support Capability Eliminated.

Support Capability ≠ Maintenance Capability.

End of Maintenance ≠ End of Support.

Security-Only Support ≠ Full Maintenance.

Extended Support ≠ Standard Support.

Alternative Support ≠ Equivalent Support.

Community Maintenance ≠ Contractual Support.

Support Terminated ≠ Software Withdrawn.

Unsupported Software ≠ Inactive Software.

Support Status Declared ≠ Support Status Verified.

Support Notice Delivered ≠ Operational Transition Completed.

Support Responsibility Assigned ≠ Support Capability Established.

Support Transfer Recorded ≠ Support Continuity Verified.

Support Transition Closed ≠ Retirement Closed.

Support Termination ≠ Elimination of Operational Responsibility.

Canonical Boundary

End-of-Support Management Module (ESMM) governs the identification,

classification, transition, verification, and continuing consequences
of software support and maintenance conditions throughout the
retirement lifecycle.

It establishes the governance relationship between identifiable software

objects, support providers, available capabilities, effective support
conditions, affected operational dependencies, and continuing
responsibilities.

ESMM does not determine that software is retired merely because
support has ended.

It does not independently execute software migration, resolve residual
dependencies, withdraw software from operation, or establish
retirement closure.

It does not replace contractual interpretation, legal determination,
security remediation, or specialized lifecycle governance.

Its principal governance output is the:

Software End-of-Support Profile

This output establishes the evidence-supported support condition of the

software and the obligations that remain relevant to its continued
operation, migration, or retirement.

Canonical Closing Statement

The end of software support is not the end of the software's
consequences.

An unsupported application may continue processing essential
information.

A discontinued library may remain embedded within active systems.

An industrial controller may depend on firmware that no longer
receives security updates.

An AI service may remain integrated into operational applications
after its provider announces the end of support.

And an organization may continue relying on software whose available
maintenance capabilities are substantially narrower than its declared
support status suggests.

ESMM establishes the governance structure required to make these conditions

It identifies the actual support capabilities available for each software

object and applicable configuration.

It distinguishes maintenance termination from broader support
termination.

It preserves the consequences of continued unsupported operation.

It governs transitions between support providers, extended support

arrangements, and restricted operational conditions.

It connects support changes to migration, dependency management, and

retirement requirements.

And it ensures that the disappearance of a support service does not
erase the operational responsibilities associated with software that
remains in use.

Support governance must follow the capabilities that actually exist,
the software that actually operates, and the obligations that actually
remain.

End-of-Support Management Module (ESMM) transforms support termination

from an administrative lifecycle announcement into a verifiable
governance condition that preserves operational awareness,
responsibility continuity, and the basis for controlled software
retirement.