Mitigate memory price increases with components harvested from retiring devices

Memory and graphics cards pulled from retiring devices can keep in-service devices running past their refresh date.

The circular economy just picked up one of its strongest business cases yet, and it didn’t come from a sustainability mandate. It came from a memory shortage. An AI-induced memory shortage has pushed the price of new devices up, causing organizations to recalculate their repair-vs-replace threshold, and to look again at what a decommissioned device is still worth.

Rather than proceeding with typical 3 to 4-year refresh cycles, many IT and procurement teams have shifted to preservation mode, holding devices longer where they can and stretching the cycle. Another trend gaining ground: internal component harvesting. Instead of treating retiring or broken laptops as something to dispose of, forward-thinking organizations are treating them as sub-component mines. This means pulling the working memory and graphics cards out of a device too old to redeploy, and putting them into devices that can.

Procurement can buy memory at the new price, or pull it from a device it just decommissioned. The rest of this article covers the three main steps that make the second option work.

First, get the devices back

Recovered devices are the harvesting supply, so the first thing to know is your recovery rate, which is how many devices you can count on getting back, and when.

To accurately measure your recovery rate, you need to track three things:

• The eligible pool
• The return rate
• The yield

The eligible pool is every device that should be coming back in a given window. A device enters the pool for one of four reasons:

• A scheduled refresh or lease end. These are the most predictable returns, because every device has a date. The purchase or deployment date in the asset record, plus the refresh policy, gives the refresh date. The lease contract gives the lease end. Most asset management systems can produce that list on demand, so count every device whose date falls inside the window. Lease returns carry penalties for late or missing devices, so they tend to be the best-tracked group already.
• An employee departure. HR’s exit list is the trigger, and the asset record says which device that person holds. The device is due back on their last day or within the return window that follows. Remote departures are where most returns go wrong, so note the person’s location and how the device will travel.
• A role change that comes with a different device. A move into a role with a different device class, such as a field role that needs a lighter laptop or an engineering role that needs a workstation, puts the old device in the pool. It’s the easiest trigger to miss because nobody leaves. The request that issued the new device is the record to count from.
• A break/fix swap where a replacement went out and the failed device is owed back. The service desk ticket is the record. A failed device still belongs in the pool as a harvest candidate, because a cracked screen or a dead keyboard says nothing about the memory inside it.

To count the pool, pull the numbers from the systems that already track those events: the asset record and refresh policy, HR’s list of departures and role changes, and the service desk’s record of swaps.

There will always be exceptions, and checking device management tools, such as Intune or Jamf, for devices that haven’t checked in for 30 to 60 days may help locate a few more for the pool.

The return rate is the percentage of the eligible pool that actually came back:

Return rate = devices received ÷ eligible pool × 100

For example, if 100 devices were due back this quarter and 80 were scanned into inventory, the return rate is 80 percent. A device only counts as received once it’s scanned in, not when the return label is printed.

Two more numbers belong next to the return rate:

• Days to return. How long each device took to come back, from the day it entered the pool to the day it was scanned in. This is dwell time. Average it, and also count how many came back inside your target window, because a few very late returns can hide inside an average.
• Leakage rate. The percentage of the pool that didn’t come back at all. Keep two counts: devices still outstanding when the window closes, which may yet arrive, and devices written off, which won’t. Remote workers who miss return windows are the usual cause.

Track all three by reason. A departing employee’s laptop and a swapped one rarely move at the same pace, and a lease return with a penalty behind it moves faster than either.

The yield is the percentage of returned devices that turn out to be usable, either as a device that goes back to a user or as a donor of working parts:

Yield = usable devices ÷ devices received × 100

Of the 80 devices that came back in the example above, if 60 can be redeployed or harvested, the yield is 75 percent. Physical possession doesn’t automatically equal usable supply, and the next section covers how to set the standard that decides it.

Put the three together and you have the forecast:

Forecast = eligible pool × return rate × yield

In the example, 100 devices due back, at an 80 percent return rate and a 75 percent yield, is 60 usable devices. Once that number is known, devices in transit can be treated as inventory. If ten devices are due back within the usual window, that’s ten candidates for harvest, and a request to buy memory at the new price can wait until they’ve been sorted. The forecast only works as the official timeline if purchasing decisions and return tracking both treat it that way. That timeline only holds if the return stays open until the old device is received. A return closed when the replacement ships leaves the old device untracked in a drawer, and out of the count.

Next, decide which devices give and which keep going

Every device that comes back from the field ultimately lands in one of three distinct outcomes: it goes back to a user, it gives up its parts, or it leaves the organization entirely. The first two are what the yield counts. To route every device to the correct outcome, run two checks in order:

Does the device still meet the standard for redeployment?

To pass, it typically needs to satisfy four rules: how old the device can be, measured in processor generations behind the current one; how much memory it has to have, such as 16 GB; what condition it has to be in; and whether any repair costs less than the device is worth. A device that passes all four goes back to a user. One that passes but is close to the age limit usually isn’t worth redeploying. Imaging, shipping and another handoff cost more than the few months it would give, so it moves to the second check.

Does the device hold what in-service devices need?

A device too old to redeploy often carries the same memory and graphics cards a newer device would take, and memory is the part whose price just went up. Suppose the redeployment standard is 16 GB of memory. A device with 8 GB won’t go back to a user, but its memory can go into one that will. A healthcare client’s radiology workstations are the same case: too old for a new user, with working memory and graphics cards inside.

Running the second check means knowing what’s inside each device, which most asset records don’t say. The part number does: it says what the device was built with, and a provider that handles ITAD will usually know the configuration from that before the device is opened. The erasure tool used on a retiring device adds a triage report that lists each component and whether it still works. Record memory and graphics configuration per device from those two sources, and a retiring device can be matched to the in-service devices that need its parts.

A device that fails both checks exits: sold if a secondary buyer will pay for it, recycled if not. In the example from the first section, the 60 usable devices out of 80 received are the ones that passed one of the two checks, and the other 20 are the ones that exited.

Finally, pull the parts and put them to work

A device that failed the first check and passed the second is a donor. Turning it into savings takes three steps:

Pull and test. The memory and graphics cards come out, get tested beyond what the triage report says, and go into storage until a device needs them. This is the step organizations usually need help with, because safe removal, testing and storage take equipment and handling few keep in-house. MCPC does this work inside IT asset disposition (ITAD), the processing of devices leaving an organization, and uses the recovered memory and graphics cards to extend in-service devices that would otherwise have been refreshed.

Match and install. The configuration record from the second check says which in-service devices need what the donor gave up. Memory is the simplest part to match. Graphics cards and the accessories around a device carry more of the compatibility work. A device that receives a donor’s memory stays in service past the refresh date it would otherwise have hit.

Count the savings. A harvested part shows up in a budget as a purchase that didn’t happen, which is harder to see than one that did, so count it:

Cost avoided = harvested parts installed × price of the same part new

Add reclaimed devices at their original purchase price. In the example, if 20 of the 60 usable devices were donors, that’s 20 memory purchases at the new price that didn’t happen, and the number that tells leadership a request was filled from stock the organization already owned. The savings only show up if reclaimed stock is used first. A new request should go to the shelf before it goes to a purchase order.

What’s left of a donor still has a resale value, lower than it had whole. The time to price it is before the refresh decision, not after. A provider with its own ITAD operation can take an inventory list and come back with the resale value and the credit it would produce, which turns the decision from a guess into a comparison. How that value comes back matters. A check goes to central finance and registers as a small line in a large budget. A credit applied to services stays with the budget owner, with no requisition or purchase order to get through.

One thing to know about whoever handles your retiring devices: a disposal vendor earns when a device sells, so its incentive favors selling the device whole over pulling parts from it. A single question shows how a current provider treats this: when a retiring device holds working memory that could extend one of ours, what happens to it, and does the sale of the device affect that choice?

Whether to sell a device whole, recycle it, or harvest it is a finance decision, and it needs three numbers side by side: what the device earns sold whole, what it earns recycled, and what its harvested parts save against new purchases.

How MCPC does this

MCPC runs this process end to end for clients, and has for some time. It starts with the return. MCPC handles the logistics of getting a device back from a user, tracks every return as an open item until the device is scanned in, and reports dwell time against each client’s average so an overdue return stands out before the window closes.

Each client has a routing guide, written with MCPC, that sets the generation limit, the memory minimum, the condition standard and the repair threshold. When a device arrives, MCPC already knows its configuration from the part number, and the erasure process produces a triage report on whether each component works. The device goes to redeployment, harvest or exit on that basis, the same way every time.

Harvesting happens inside MCPC’s ITAD operation. Working memory and graphics cards are pulled, tested, stored and categorized, then matched to in-service devices in the client’s fleet that need them, with compatibility checked before anything ships. Devices that redeploy go back out as complete kits, with the power supply, cables and webcam matched to the device class, because a laptop without its charger does nobody any good.

Before a refresh decision, MCPC prices the client’s retiring inventory through its ITAD facility and shows what it would return as resale value, and what that would be as a credit against services. Reclaimed inventory is used first: when a new request comes in, MCPC’s client success and operations teams fill it from the client’s reclaimed stock before anything is bought. Every reclaimed device is reported at its original purchase price, so the client can show leadership the cost that was avoided, quarter by quarter.

For some clients the program pays for itself. The credits earned by remarketing retiring devices cover the cost of the services, so the harvested memory, the redeployed devices and the purchases that never happened come on top. One client has called it the most effective procurement hedge in their program, and it was built rather than bought.

If your organization is planning its device budget around memory prices, MCPC’s guide to the memory shortage, Corporate Memory Loss: A Practical Guide to Navigating AI-Driven Memory Constraints and Device Strategy, is a place to start. If you’d like to work through your own redeployment standard and donor rules with someone, we’d welcome the conversation, and you can talk with an expert here.