Resources · 93
Software inventory: prepare for end of support
Turn a tool list into maintenance, replacement and retirement decisions.
· 3 min
What this guide helps achieve
- Start with actual services
- Verify supplier conditions
- Map business dependencies
- Prepare a decision
- Close with operational evidence
Quick check
- Must all old software be replaced?
- What if support dates are unknown?
- Does an exception remove risk?
Step-by-step method
- 01
Start with actual services
Inventory software, hosted services, versions, environments and essential uses. Reconcile discovery with procurement. CSF 2.0 connects inventories with lifecycle management; a paid subscription does not establish maintenance of a deployed version.
Output: Instance and usage inventory.
- 02
Verify supplier conditions
Retain official link, edition, version, maintenance type and consultation date. Distinguish security fixes, standard support and extended contracts. Label unknown conditions explicitly; never invent an expiry date.
Output: Sourced support conditions.
- 03
Map business dependencies
Record owners, integrations, data and tasks that would stop working. An internal, unexposed component can still be critical. Prioritise exposure and impact rather than age alone.
Output: Business dependency map.
- 04
Prepare a decision
Compare upgrade, replacement, removal and controlled temporary retention. Test compatibility, restoration and data exit. Give exceptions a reason, owner and review deadline.
Output: Plan and owned exceptions.
- 05
Close with operational evidence
Verify deployed version, business journey and retirement of old instances. Reconcile register, monitoring and contracts. Buying a new licence does not prove migration.
Output: Version and retirement evidence.
Fictional acceptance-test scenarios
These proposed cases are not client observations. Adapt data, permissions and acceptance criteria to your authorised environment.
| Situation to exercise | Result to check | Evidence to retain |
|---|---|---|
| An inventory contains only a product name. | Identify version, edition, deployment and owner before determining support status. | Installed reference and official policy for that edition. |
| A vendor changes a previously recorded support date. | Update the dated reference, dependencies and plan; distinguish announced dates from observed state. | Policy URL, consultation date and revised decision. |
| An upgrade works but rollback fails. | Test restoration, data compatibility and dependencies before declaring migration controlled. | Test timeline, backup used and recovery outcome. |
Reusable worksheet
Complete with your authorised observations. These fields are a working template, not observed results.
| Field | Information to record |
|---|---|
| Product | Edition, version, environment and owner |
| Support | Official source, conditions and review |
| Impact | Dependent services and data |
| Action | Decision, evidence, deadline and exception |
Worked example
Illustrative situation
Fictional example: a support notice covers a different edition of a module from the one deployed.
Decision and expected evidence
The team verifies its contract, tests a compatible version and retires the old instance after business acceptance.
Distinguish the mechanisms
| Mechanism | Purpose | Check or limitation |
|---|---|---|
| Installed version | Describe operational state | Observe actual systems |
| Support contract | Define commitments | May cover specific editions only |
| Migration plan | Organise change | Validate with an executed task |
Management indicators
| Indicator | What it measures | First action |
|---|---|---|
| Identified versions | Instances linked to versions | Resolve unknowns |
| Verified support | Editions with supplier evidence | Review stale records |
| Proven retirements | Old instances actually closed | Reconcile inventory with use |
Common pitfalls
- Observe actual systems
- May cover specific editions only
- Validate with an executed task
Frequently asked questions
Must all old software be replaced?
No. Assess maintenance, exposure, usefulness and dependencies. Age alone does not determine priority.
What if support dates are unknown?
Record the gap, contact the supplier and set a review. Do not borrow dates from another product.
Does an exception remove risk?
It makes the decision explicit. Record controls, ownership and duration, then reassess it.
Official references
References consulted: . The method and worksheet propose checks to adapt to your context; they do not constitute certification.
Continue exploring
Related analysis
