A field-replaceable unit (FRU) is any circuit board or part that a technician can pull and swap on-site, rather than shipping the whole system back to a repair facility, per TechTarget's definition of the term. That single distinction — field swap versus depot repair — is what keeps a server, switch or storage array running once standard manufacturer support has lapsed. The catch is that vendor service manuals often split one chassis into dozens of separately numbered FRUs, each with its own part code and replacement procedure, so knowing the concept is only half the job. For UK teams managing kit past its OEM end-of-support jargon milestones, the real work is matching the exact FRU code to a genuine, compatible part before a failure becomes an outage.
View the data behind this chart
| Layer | Detail |
|---|---|
| CPU module assemblies | Eight positions documented as CMOD0 through CMOD7 |
| Processor and heatsink modules | Separate FRU nested within each CPU module |
| Storage drive backplanes | Classified as CRU rather than FRU in the manual |
What Exactly Is a Field-Replaceable Unit?
TechTarget defines an FRU as a circuit board or part that can be removed and replaced by a user or technician without sending the system to a repair facility. Lenovo's glossary frames it similarly: a component or module designed to be easily replaced in the field, without extensive technical expertise or specialised equipment, and it lists power supplies, memory modules and hard drives as typical examples across computers, servers and networking devices.
Oracle's ILOM management documentation puts it more tightly still, defining a FRU as a system component that is replaceable at the customer site. This isn't marketing language — it's operational terminology baked into how systems track themselves. IBM documents FRU 'buckets' in its AIX operating system documentation specifically so that administrators can identify which physical parts need replacing when a fault is logged.
Underneath the definition sits a data standard: the DMTF's FRU Data Specification (version 1.0.1) defines FRU data as a structure for vital product data — essentially a digital record, often stored in an onboard EEPROM read by the baseboard management controller, that identifies exactly what the component is. As training material on BMC essentials notes, a technician typically needs that associated part number to order the correct replacement — guessing from a device family name isn't enough.

FRU vs CRU: A Distinction With Real Financial Consequences
Not every replaceable part is classified the same way, and the difference matters for who does the work and how fast it happens. Oracle's own X8-8 server service manual illustrates this inside a single chassis: CPU module assemblies are documented as FRUs, but in at least one section the storage drive backplane is classified as a CRU (customer-replaceable unit) rather than a FRU. The label isn't cosmetic — it signals a different expected service route, and potentially a different warranty or support-contract condition attached to who is authorised to touch the part.
Enterprise management tooling treats this as a distinct inventory category too: Dell's OpenManage documentation includes a dedicated Field Replaceable Unit group in its SNMP reference guide, separate from general hardware inventory. That confirms FRU identification is something vendors expect IT departments to track systematically, not just something for a technician to notice mid-repair.
The practical implication for a UK IT department is straightforward: before assuming a failed part can be swapped by in-house staff, check whether the vendor's manual actually lists it as a FRU, and cross-reference that against your support contract. A part labelled CRU in one section of a manual and FRU in another, within the same chassis family, is exactly the kind of detail that turns a routine swap into a contract dispute if it's missed.
Common FRUs Inside a Modern Chassis
Vendor service manuals rarely treat a server as one indivisible box. Oracle's X8-8 manual separates the chassis into CPU module assemblies (eight positions, labelled CMOD0 through CMOD7), processor and heatsink modules as a distinct sub-assembly within each CPU module, and storage drive backplanes as a further separate component. Lenovo's glossary adds power supplies, memory modules and hard drives to the list of items commonly treated as FRUs across computers, servers and networking equipment.
The pattern that matters for sourcing is this: one chassis can contain dozens of distinct replaceable subassemblies, each with its own part identity and its own service instructions. A generic model number or device family name won't get a technician the right component — the exact FRU code, tied to that specific module position, is what determines compatibility.
Warm-Serviceable vs Cold-Serviceable: What Hot-Swap Really Means
Oracle's X8-8 service manual classifies some FRUs as warm-serviceable and others as cold-serviceable — a distinction that describes the outage condition required for replacement, not a different family of part. A warm-serviceable FRU can typically be pulled and replaced while the system remains running in some capacity; a cold-serviceable one requires the system to be powered down first.
This classification is where FRU strategy meets real operational planning. If a critical component in your estate is documented as cold-serviceable only, no amount of spare-parts availability changes the fact that replacing it means a scheduled outage. Knowing which category each FRU falls into — before a fault occurs — is what allows a UK operations team to plan maintenance windows realistically rather than discovering the requirement mid-incident.
Mastering FRU Inventory: Tracking, Logistics and Obsolescence
TechTarget's description of the standard FRU workflow is instructive: a defective FRU is usually found through standard troubleshooting, then removed and either discarded or shipped back to the factory for repair. That workflow assumes the OEM repair channel is still active and economical — an assumption that breaks down once a platform is past standard support.
This is precisely where TechTarget notes that independent parts sourcing becomes more valuable as hardware ages: FRU-based service documentation can remain available and usable long after the OEM's own repair route becomes less economical or less accessible. In other words, the manual doesn't expire even when the support contract does — but finding a genuine, compatible part to match that manual's FRU code is the harder half of the job.
Good FRU inventory management for an ageing estate typically means treating part-number-level tracking — not just device-level tracking — as the baseline. Using the FRU vital product data structure defined by the DMTF specification (or equivalent vendor tooling such as Dell's OpenManage FRU group) gives a technician a machine-readable identity for each component, rather than relying on manual cross-referencing under time pressure during an incident.
- •Keep vendor service manuals archived even after OEM support lapses — Oracle's and Lenovo's documentation shows FRU tables remain the definitive reference for part identity and replacement method.
- •Track by FRU part number, not device model, since a single chassis can contain many distinct FRUs (as the X8-8's eight CMOD positions demonstrate).
- •Distinguish warm-serviceable from cold-serviceable components in your own asset records so maintenance windows can be planned rather than improvised.
- •Treat independent sourcing verification as a compatibility exercise, not just a price comparison — the part number must match, not just the device family.
FRUs, Warranties and SLAs
Oracle's ILOM documentation defines a FRU as a component replaceable at the customer site — language that sits directly inside the vendor's support model. Whether a given FRU is covered under warranty, and what response time an SLA can realistically promise for it, depends partly on that component's documented service classification.
This is the detail IT managers most often miss: an SLA promising rapid restoration is only as good as the serviceability class of the FRU actually involved. A warm-serviceable power supply can support an aggressive uptime commitment; a cold-serviceable component buried deep in a chassis cannot, regardless of how quickly a replacement part arrives. Reviewing FRU classifications against SLA commitments — ideally before signing a support contract, not after an outage — is what keeps expectations realistic. For hardware where OEM contract terms no longer make sense, third-party maintenance solutions can align coverage more closely with the actual serviceability of the FRUs in the estate, rather than paying for blanket OEM terms on parts that are commodity-level to replace.
The UK Sourcing Decision: OEM vs Independent Parts
Consider a UK-based operator running a server platform equivalent in structure to Oracle's X8-8 architecture, now past standard OEM support. One of the eight CPU module assemblies (a CMOD position) fails. The manual identifies it precisely — this is a documented FRU, not a CRU — and specifies the replacement procedure and serviceability class.
The decision point isn't whether the part is field-replaceable; the manual already answers that. The decision is where to source a genuine, compatible replacement now that the OEM's standard depot-repair economics may no longer apply. An independent parts channel can supply refurbished server components at a lower cost and faster lead time than a lapsed-support OEM route — but only if the exact FRU code is verified against the failed module before ordering. Get that verification wrong, and a low-cost repair becomes an outage caused by an incompatible part, plus the cost of doing the job twice.
This is why the UK procurement challenge around FRUs is rarely about understanding what a field-replaceable unit is — it's about traceability and compatibility discipline at the point of sourcing. Building that discipline into procurement, whether through in-house processes or specialist IT procurement services, is what actually extends the affordable working life of end-of-support hardware.
Sources
Every figure in this article traces to the sources below.
- •TechTarget — FRU definition and field-swap-versus-depot-repair workflow
- •Lenovo — FRU glossary definition and common examples (power supplies, memory, drives)
- •Oracle — X8-8 service manual FRU table, CMOD positions, warm/cold-serviceable classification, CRU distinction
- •Oracle — ILOM documentation definition of FRU as customer-site replaceable component
- •DMTF — FRU Data Specification defining vital product data structure
- •IBM — AIX documentation on FRU identification in enterprise systems
- •Dell — OpenManage documentation showing dedicated FRU inventory group
- •LinkedIn Learning — BMC/EEPROM FRU data and part-number ordering requirement
