Legacy Catalyst Replacement Checklist: Match Components and Preserve Services

Use this checklist for a bounded replacement in an installed Catalyst environment. It is not a recommendation to deploy every legacy platform for new projects. The goal is to restore a defined service with a documented component match and a known operating horizon.

1. Record the installed configuration

Capture exact switch or chassis identifiers, supervisors, line cards, power supplies, fans, stack accessories and software. Record which interfaces and functions the affected service uses. Do not assume a current inventory label reflects every component inside a modular system.

Catalyst 3750-X, 6500 and 6800 are different system families. Documentation for a particular supervisor or chassis combination must be read within its stated scope. R26

2. Identify the replacement type

Request	Qualification needed
Same-identifier spare	Condition, relevant revision and installed-system match
Superseding part	Manufacturer substitution evidence and any new dependencies
Different module with similar ports	Complete compatibility and service-capability review
Complete switch replacement	Interface, configuration, feature and migration review
Stack or power accessory	Exact host and accessory-system support

A replacement with more ports is not necessarily equivalent if it changes supported media, power or software behavior.

3. Separate the evidence categories

Record physical condition, seller testing, manufacturer compatibility and support eligibility separately. “Refurbished” does not automatically establish a particular test process or entitlement. “End of sale” and other lifecycle milestones also require product-specific interpretation.

Use the exact product’s lifecycle notice for dates. The general Cisco policy explains the process but does not determine the remaining support period of an unidentified part. R19

4. Prepare a representative restoration test

Confirm that the candidate boots, is recognized and supports the interfaces and functions the service actually uses. Test configuration restoration on a suitable staging system where practical. Retain the tested software image and relevant prerequisites through an authorized process.

An illustrative spare qualification should state that the part restored a named role under a recorded configuration. A seller’s generic power-on statement answers a much narrower question.

5. Define change and rollback boundaries

Preserve management access and the existing configuration. Identify which service owners must approve the maintenance window. Avoid combining an urgent part replacement with unrelated firmware, topology and policy changes unless they are necessary and separately validated.

Define what happens if the replacement is not recognized, an interface cannot establish the required mode or a critical feature behaves differently. Record the point at which the previous state can no longer be restored immediately.

6. Update the installed and spare inventories

After acceptance, record the new component serial or identifier, configuration baseline and test outcome. Remove failed items from serviceable stock and retain return or repair records.

The final decision should be marked approved, conditionally approved with explicit requirements, or unresolved. That status is more useful than an unqualified compatibility label and keeps a legacy maintenance action connected to a controlled replacement strategy.

Engineering illustrations

These figures illustrate the design concepts discussed here. They are not measured results, certified configurations or a supplied-equipment list.

Related reading

• Legacy Catalyst Maintenance: Exact Replacements and a Controlled Exit Plan
• Used, Refurbished and End-of-Life: Three Different Buying Questions

References

• R26: Catalyst 6500/6800 Supervisor Engine 6T Architecture
• R19: End-of-Life Policy