The channel decided the return, not the refit - Dell PowerEdge T420
Published
A client owned a 2012 Dell PowerEdge T420 and wanted to know what it was worth refitting it to sell to a dental practice. Four budgets, from $155 to $1,040, each costed against components actually for sale that week. The interesting answer was not which build to pick.
The channel moved the return more than the build did
The four budgets are all economically viable, but the sales channel matters as much as the configuration. On the eBay channel the margins are tight; on the direct channel to the practice they are healthy. Warning about the eBay channel: budgets 2, 3 and 4 have low ROI, 35 to 50%, in their minimum scenario.
The same machine returned 158% or 368% on the cheapest build depending only on who bought it. Spend more and the spread widens rather than narrows: the middle budgets are the ones that stop making sense on a marketplace, because the buyer there is comparing against every other listing and does not pay for a specification they cannot evaluate. A build costed without a buyer in mind is a number with no denominator.
Decide the channel before the specification, because the channel sets what the specification is worth. Price the same build against both exits and compare the pair, not the totals: a low absolute profit with the capital back in three weeks often beats a high one that sits in a chassis for four months. Where the direct sale is uncertain, the honest move is the smallest build that still sells, since it is the one whose downside is a slower sale rather than a loss. The anti-pattern is speccing to what the hardware can take, which is how a machine ends up too good for the only market that will actually buy it.
The existing memory could not be kept, at any capacity
8GB total, Kingston K1N7HK-ELC, 2GB 1Rx8 PC3-10600U, DDR3-1333 UDIMM unbuffered. The existing UDIMM memory CANNOT be mixed with RDIMM. Total replacement is obligatory. Maximum RAM with 16GB RDIMM: 192GB across 12 slots.
This is the trap that turns a memory upgrade into a memory replacement, and it is invisible until the parts arrive. Unbuffered and registered modules are not interchangeable on this platform: install both and the server does not post, and there is no capacity at which mixing becomes acceptable. Every budget therefore carried the full cost of new memory rather than the difference, and the 8GB already in the chassis was worth nothing to the project.
Read the module label before costing anything: the U or R in the part code decides whether existing memory is an asset or scrap. Check the platform's ceiling in the same pass, because it is set by module type rather than by slot count, and the cheapest route to a target capacity is usually fewer, larger modules rather than filling every slot. Where a build needs more than the registered ceiling, load-reduced modules exist and cost enough to change the answer. The anti-pattern is budgeting for an upgrade and discovering a replacement.
Background: on-premise servers.
The RAID controller was optional, and the reason to buy one was not speed
Yes, RAID can be implemented in software, through mdadm on Linux, without a physical RAID controller such as the PERC H710. This option reduces the refit cost by $35 to $55. Battery-backed cache: yes on hardware, protecting against a power cut during writes; no on software, but enterprise SSDs with Power-Loss Protection serve a similar function.
The controller is usually sold on performance, and on modern SSDs that is the weakest argument for it. What it actually buys is a battery behind the write cache, so a power cut mid-write does not leave the array inconsistent. Drives with power-loss protection cover the same failure from the other end, which means the decision is about which component holds the capacitor and not about throughput. The cost of getting it wrong is not slowness; it is an array that needed a rebuild after an outage.
Pick the layer that holds the power-loss guarantee, and buy it once. Software RAID on drives with power-loss protection is a complete answer and costs nothing beyond the drives; a hardware controller with a healthy battery is also a complete answer and costs the controller. What is not an answer is a controller with a dead battery, which is most of the used ones, or consumer SSDs behind either. Software arrays carry a second advantage on used hardware: the array is readable in any machine, where a controller-specific array needs that controller, and a spare for a 2012 card is its own shopping trip. The anti-pattern is buying the controller for speed and inheriting a battery nobody checks.
The platform accepted two CPU generations and nothing else
The T420 platform supports exclusively the Xeon E5-2400 and E5-2400 v2 series. The E5-2440 v2 and E5-2470 v2 CPUs are natively compatible. Recommended BIOS: update to the latest version available from Dell before installing the v2 CPUs. The second CPU socket is empty.
A socket that physically accepts a chip is not the same as a platform that will run it, and the gap between those two is a server that powers on and posts nothing. The v2 parts need firmware that predates neither them nor the board, which is why the BIOS update belongs before the CPU rather than after the failure. The empty second socket is the other half: filling it needs a heatsink and an air duct that do not come with the processor, and a power supply nobody had yet confirmed could carry both.
Update the firmware while the machine still boots, because the window to do it closes the moment the unsupported chip goes in. Confirm the supported list against the board rather than the socket, since a shared socket across generations is what makes this mistake easy. Budget the parts a second processor drags with it - heatsink, shroud, and the headroom in the power supply - and verify the supply before committing, not after. The anti-pattern is buying the fastest chip the socket takes and finding out which of those three was missing.
Used hardware was costed with a contingency, not with optimism
Age of the equipment: the T420 is a 2012 platform, roughly 14 years old, outside Dell's official support. Component failure: consider a contingency fund for unforeseen replacements, $300 to $500. Used components from a marketplace: condition varies. Buy from sellers with good ratings and a returns policy. Current power supply: not confirmed from the photographs. Verify before loading the platform with dual CPUs.
A contingency of $300 to $500 sits on top of a $155 build, which says something the budget table alone does not: on the cheapest option the reserve is larger than the spend. That is not an argument against it, it is the actual risk profile, and a plan that omits it is not cheaper, only less honest. The unverified power supply is the same point in miniature, since it is the one component that turns a dual-CPU build from an upgrade into a second purchase.
Write the contingency into the budget rather than into the conversation, because a number in a table gets approved and a caveat in a meeting gets forgotten. Burn in every used part before it reaches a customer: the failures that matter arrive in the first days, and finding them on your bench costs a return rather than a relationship. Keep the purchase records, since documented components resell for more than undocumented identical ones. The anti-pattern is treating used-hardware savings as margin, when part of it is the reserve that makes the saving safe.
What was already correct
The platform itself was a sound thing to keep. A T420 takes two sockets, twelve DIMM slots and up to sixteen 2.5 inch drives, and the CPUs worth fitting to it are natively supported rather than needing a hacked BIOS. The client already owned it, which is the part no upgrade path can buy back: the chassis, the backplane and the power supply were sunk cost, and every dollar in the budgets went into parts that raise the resale price.
Bottom line
Four builds were viable and the spreadsheet picked a different winner depending on where the machine sold. That is the finding: on used hardware the sales channel is a bigger variable than the configuration, and costing the build without costing the channel answers half a question.