Part I: Build Your Own Servers? What the Hyperscaler Model Really Requires of Enterprise IT

Cloud providers' cost structures grew out of operating models built around cheap hardware, homogeneous workloads and a handful of hardware configurations across the whole fleet. Their software treats a dead server as something the scheduler handles without waking anybody. They keep firmware engineers on staff and have enough scale to carry their own warranty risk on a spreadsheet.

A few enterprise IT organizations have the resources to mimic hyperscalers and source components directly. Most do not. The unprepared may find that the bill of material (BOM) savings are real but small, and what they save is spent several times over on obligations that used to sit with a vendor but now sit with them.

So, when does it make sense for an enterprise to buy directly from the original manufacturers and build its own servers? 

Rarely, and only when the organization already has the operating model that makes it work. The rest of this note explains why and gives you 10 questions to test your operating model. Part II of this series covers AI and HPC clusters in depth.

Key takeaways

• The component shortage sits upstream of both original equipment manufacturers (OEMs) and original design manufacturers (ODMs). Buying direct puts you further back in the memory queue, not closer to the front.
• Whitebox hardware costs 20% to 30% less than the tier-one list price. But the savings arrive once, while eight costs move from the OEM onto your books and six of them recur every year.
• Owning a silicon root of trust means funding a permanent security function, and the bar for that work is rising as AI makes firmware flaws cheaper to find.
• Open Compute Project (OCP) and ODM-derived hardware often assume rack, power and cooling standards that enterprise data centers and colocation cages are not equipped to provide.
• Tariffs, export controls and component bans keep changing, so sourcing your own components requires continuous monitoring and requalification to stay current. Your OEM does that work today. Assembling servers can also make you or your integrator the manufacturer and importer of record.
• Some workloads suit this model well. AI and high-performance compute (HPC) clusters are the clearest case, but they're also the ones most likely to be misread as proof that the rest of the estate should follow.
• There is a lot of room between paying list price and building your own servers. In our experience, most organizations have not fully explored this space.

Why is this question suddenly everywhere?

The pressure is real, and your vendors aren't inventing it.

In the first quarter of 2026, worldwide server spending rose 30.4% year over year to $122.6 billion(opens in new window), while unit shipments grew just 3.3%, according to IDC. Spending is climbing at roughly 10 times the rate of shipments. Enterprises aren't buying much more infrastructure. They're paying a lot more for about the same amount.

The cause sits several layers below your purchase order. Memory manufacturers are shifting wafer capacity from commodity DRAM to high-bandwidth memory (HBM) for AI accelerators, and HBM uses roughly three times the wafer area of DDR5 for the same capacity. Every increase in HBM production squeezes general-purpose server memory.

The results show up in every quote. DRAM and NAND prices have risen by more than 200% since early 2025. SK Hynix sold out its 2026 output before the year began. Enterprise DRAM lead times have stretched from about 25 weeks to well past 40, and Micron's key customers are getting only half to two-thirds of what they need.

A CIO looking at a quote that expires in 72 hours, a 40-week lead time and a price well above last year's hardware refresh has every reason to ask whether there is a way around the OEM.

If your OEM's memory pricing is well above the open market, that is a fair thing to challenge. 

The fix is better visibility and better terms. Going direct won't fix either problem, because what separates you from a hyperscaler has very little to do with how you buy.

Will buying directly from ODMs get your servers to you faster?

No. Most of the time, buying direct makes delivery slower and harder to predict. 

The constraint lies in three memory fabs, a small number of foundries and a set of long-term supply agreements you're not part of. Together, Samsung, SK Hynix and Micron make most of the world's DRAM. The hyperscale operators are locked in multi-year priority access through contracts signed at premium prices. A January 2026 Tom's Hardware report estimates that data centers will consume up to 70% of the memory produced worldwide in 2026, with the rest of the world splitting what's left. That decision was made long before your order existed, and it doesn't matter whether your order materializes through Dell or through an integrator in Fremont.

Allocation follows the committed forecast, and the OEMs are the ones with the forecast. Dell, HPE, Lenovo, Cisco and Supermicro place enormous multi-quarter commitments with memory and CPU suppliers, and those commitments buy priority. An enterprise placing a 2,000-unit order has no standing in that queue. You'd be bidding for whatever is left after the hyperscalers and the OEMs have taken their allocations, putting you two positions further back than where you started.

The ODMs are supply-constrained too, and they've said so on the record: Inventec, one of Taiwan's largest server motherboard manufacturers and a significant supplier to US hyperscalers, warned in July 2026 that memory and CPU supply gaps were widening and might cut its server shipment volumes into the third quarter. That's an ODM describing the same constraint your OEM faces. There's no separate unconstrained supply chain hiding behind the OEM logo.

Memory is increasingly not sold on its own: As allocation tightened, suppliers and OEMs moved toward selling DIMMs as part of complete server configurations rather than as loose components. Assembling your own systems means sourcing memory independently, which right now is the single hardest part of the bill of materials to source and the place where you have the least bargaining power.

A narrow exception: When a particular OEM SKU is backlogged and a tier-two or ODM-derived platform with a different component mix is available, substituting can sometimes beat the queue. This is opportunistic sourcing rather than a procurement strategy, and a decent partner should already be bringing those substitutions to you.

Somebody has to watch the rules

Component sourcing sits inside a policy environment that changes every few months. Under the OEM model, almost none of that lands on your desk. If a tariff schedule changes, the OEM either absorbs the cost or passes some of it along. If a component gets restricted, the OEM will qualify an alternate source and keep shipping under the same part number. Often, you never find out. That work is already included in the prices you were comparing.

Sourcing your own components makes that work yours. A supplier you've already qualified can be added to the entity list overnight. Every rule change means asking whether it touches parts you have bought, parts on order or a platform you were about to standardize on, then re-sourcing, re-qualifying and updating classification and country-of-origin records. Sanctions changes, and regional conflict add freight cost and extra transit weeks. 

Your general counsel is likely to raise five issues:

1. Manufacturer of record and product liability: Assembling a server, or having a third party assemble it under your direction, can make you or your integrator the manufacturer for regulatory purposes. FCC, CE, UKCA and UL certifications attach to the finished product, not the motherboard, so someone must hold that conformity. When a thermal or electrical event causes damage, liability runs to the manufacturer. Under the OEM model, that is a large insured counterparty. Under self-assembly, it is you or an integrator considerably smaller than Dell.
2. IP indemnification: Major OEMs indemnify customers against patent claims. Component vendors and integrators generally offer nothing equivalent. Read your integrator's indemnity clause and its liability cap, which is often a multiple of fees paid rather than anything proportionate to your exposure.
3. Importer of record and tariffs: Buying directly from overseas suppliers usually makes you the importer of record, responsible for tariff classification, country-of-origin determinations and customs processes. Misclassification carries penalties, and Section 301 duties on China-origin components have changed repeatedly, potentially erasing a bill-of-materials advantage.
4. Export controls and federal rules: Servers with high-performance accelerators operate under a control regime that has tightened repeatedly, with license requirements that depend on destination, end-user and technical thresholds. Selling to the federal government or its contractors brings Section 889 of the 2019 NDAA and Trade Agreements Act origin rules into scope, and NIST SP 800-161 sets supply chain risk expectations. Under the OEM model, provenance attestation is a contractual deliverable.
5. Warranty and environmental obligations: Self-warranting means holding reserves against failures with no actuarial history. WEEE, RoHS, conflict minerals reporting and packaging directives attach to whoever places the product on the market.

None of this makes self-assembly impossible. It does mean that these obligations need to be priced and assigned before a purchase order is signed. The people who need to weigh in sit in legal, trade compliance, risk and finance, not infrastructure.

Who does this work in your organization today? Most enterprise IT departments have no trade compliance function at all, and where one exists in finance or legal, it has never had to reason about a server bill of materials.

Getting procurement, engineering and compliance to work together at the same cadence as rule changes is a capability most companies would need to build from scratch, and it belongs in the cost model next to the firmware headcount.

Will buying direct cost less?

Maybe. We expect the shortage to last at least through 2028, which is a reason to avoid long-term commitments to a self-built fleet. A fleet you assemble today will outlast the shortage by years, and the firmware, qualification and compliance obligations outlast it too.

Savings from buying direct do exist, but they're smaller than the business case usually shows. Most of the money doesn't vanish. It relocates.

In the engagements we price, whitebox and ODM-sourced hardware commonly lands 20 to 30% under tier-one OEM list pricing on comparable configurations. 

The gap is real. It comes from differences in margin structure, channel cost, engineering amortization, warranty reserve and support infrastructure. But consider everything sitting in that list. You pay the OEM to do this work on your behalf. Removing the OEM doesn't remove the work, as the graphic below shows.

An illustrative example

Each number below is a placeholder, and yours will be different. What matters is the pattern. Consider a 2,000-server refresh over five years. That's typical for a large enterprise, but well below the tens of thousands of units a year at which buying direct starts to make sense.

If you staff it with six people instead of eight, the net improves to −$1.0M. Avoid the outage as well, and you reach breakeven. It takes an even leaner team, five people and no outage, to come out about $1.0M ahead. 

What doesn't change is the timing. Savings arrive once at purchase and are capped by the discount amount. The costs beneath it recur every year for as long as you run the fleet, and they grow with headcount rather than hardware.

Volume cuts both ways. A larger fleet spreads the same engineering team across more servers.

The example prices four of the eight migrated costs: firmware, qualification, spares and level 3 support. It leaves out platform validation, integration, ISV exposure and regulatory risk, so treat the net position as optimistic. The $200,000 annual cost per engineer is also conservative for firmware and security specialists.

The Uptime Institute's 2026 Annual Outage Analysis found 57% of operators report their most recent major outage cost more than $100,000. And, for the second year running, one in five put that cost above $1 million. Hardware failure isn't the leading cause of outages; power problems and human error dominate that list. What happens to your mean time to repair (MTTR) when the diagnostic path runs through your own engineers and a component vendor with no contractual relationship with you at all?

Will your data center even take the hardware?

This compatibility question is often asked late, usually after someone has already built a business case. The physical assumptions baked into OCP and ODM-derived designs come from hyperscaler facilities. That's a problem, as the vast majority of enterprise data centers weren't built to hyperscaler specs or assumptions.

• Racks: A lot of OCP hardware is built for 21-inch racks rather than the 19-inch EIA standard racks on your floor today. Power distribution frequently assumes a rack-level busbar fed by DC power shelves, replacing the per-server power supplies and PDUs your facility is wired and metered around. Denser configurations push floor loading beyond what older raised floors are rated for and beyond what some colo providers will permit in a leased cage. Rack-level power draw on current-generation designs regularly exceeds what a standard enterprise cabinet is provisioned to deliver.
• Cooling: Higher-density platforms increasingly assume direct-to-chip liquid capabilities, which need a coolant distribution unit, facility water, leak detection and a maintenance discipline that most enterprise operations teams have never had to build. Retrofitting an existing hall for liquid is a capital project with its own timeline, and that timeline is usually longer than the server lead times that started this conversation.
• Colocation tenants: Colocation tenants have an even narrower path. Your contract specifies power density, cooling method and often cabinet dimensions, and the provider has no obligation to accommodate hardware that falls outside it. Some will. Renegotiating that is a commercial conversation, not a technical one, and it takes months.

None of these rules out the "buy direct" approach on its own. Facilities questions belong at the front of the evaluation, not after the platform decision, because the answer might invalidate everything upstream. 

Ask what rack, what power topology, what floor loading and what cooling the candidate hardware assumes, then ask your facilities team whether those specifications are available in any of the buildings you occupy. If the answer is no, retrofit costs should be included in the same model as your BOM savings.

What hyperscalers do differently

The enterprises asking about ODMs are right that the model works. What they're missing is what makes it work, because procurement is the visible part and also the smallest part. The table below compares the two.

Failure is a statistic rather than an event

Hyperscaler applications get written on the assumption that any node can disappear at any moment, so losing a server is uninteresting. That assumption is what makes cheap hardware rational for them. When the software absorbs failure, you can accept a higher failure rate in exchange for a lower unit cost and come out ahead on the trade. 

Most enterprise applications assume the opposite. They were built when infrastructure was reliable. Put your ERP system, EMR or trading platform on a single node with a clustered failover partner, and the reliability characteristics of that node stop being a statistic.

Memory mirroring and sparing, correctable error thresholding, predictive failure alerting, machine check architecture recovery, redundant firmware images and granular hardware telemetry. All of that exists because enterprise applications cannot absorb failure higher up the stack. It's also where OEM platform engineering concentrates its effort, and where component-level assembly tends to fall short in ways nobody notices until something breaks.

The hyperscalers built custom BMCs, root-of-trust silicon and standing firmware teams, so a disclosed vulnerability means they ship their own fix. Under an OEM, you get a validated patch. In a self-assembled fleet, you inherit the questions covered in the security section below.

The security work you take on

Every server runs its own code before it runs yours: silicon initialization, UEFI or BIOS, the baseboard management controller, option ROMs on network and storage adapters, and microcontrollers in power supplies. All of it sits beneath your operating system, your hypervisor and every security control you have bought. A chain of trust lets you say something definite about that code. Most enterprise security programs stop above that line, and zero-trust architectures quietly assume the platform is what it says it is. Under the OEM model, you are buying that assumption from the OEM.

What the OEM model gives you: A tier-one OEM is the single signing authority. It holds the keys, signs the firmware, validates the combination and puts its name on the result. You get an immutable root of trust, a signed update path with coordinated advisories and attestation you can hand to an auditor. One accountable party spans the chain. When a vulnerability lands across the motherboard and a third-party network adapter, the OEM's product security team is contractually obliged to sort out who patches what.

What changes when you assemble it yourself: The chain fragments, and reassembly becomes your job. Your motherboard vendor, BMC (possibly OpenBMC, which you or your integrator builds) and network adapter, HBA and SSD vendors each sign their own firmware on their own schedules. Programmable logic and management microcontrollers often sit outside any signed chain. Nobody validates the combination, because it belongs to you. A disclosed vulnerability produces open questions. Which vendor owns this? When will they publish? Will the fix be validated against your combination of parts? Who regression-tests it before production?

That produces obligations most business cases never price:

• Key custody and signing infrastructure: Building BMC firmware entails running a code-signing operation that includes hardware security modules, key rotation and separation of duties.
• Golden measurements: Measured boot and TPM attestation need a known-good baseline for every hardware revision, and component vendors change revisions without telling you.
• Component authenticity upon receipt: Without a platform certificate, you design and staff an inspection process.
• An extended trust boundary: Your integrator's facility and firmware staging process are now inside your chain of trust.
• Evidence on demand: The OEM's answer to an auditor is a document you request. The self-assembled answer is a program you should already be running.

A root of trust is a permanent security function, and its demands are rising.

What frontier-class AI models change

Obscurity used to protect the parts nobody looked at, because auditing closed firmware took scarce specialist labor. Frontier-class AI models have made firmware reverse engineering and vulnerability discovery far cheaper, and DARPA's AI Cyber Challenge has produced systems that find and patch flaws in real codebases without human intervention.

This shifts the balance without creating a new class of attack. A tier-one OEM's product security team can point the same tooling at its own firmware ahead of an adversary. In a self-assembled fleet, that work belongs to whoever owns the combination, which is you. The question is whether now is a sensible moment to start building that practice from scratch, in a discipline where the required depth keeps rising, and specialist talent is scarce. That is a large commitment to make in exchange for a discount on DRAM.

Gray market and counterfeit components

Scarce parts at high prices on urgent timelines pull counterfeit and relabeled components into the channel: memory remarked to a higher speed grade than the die supports, processors relabeled as a higher SKU, parts re-balled from decommissioned equipment and worn flash sold as new. OEMs spend real money keeping this out through authorized distribution, incoming inspection and serialization. 

Sourcing yourself, especially through brokers when parts are on allocation, puts you closer to where these parts circulate, with thinner traceability. Detection is the hard part. A remarked DIMM passes POST and runs a workload, then produces correctable errors months later or fails under thermal stress in a way that reads like a platform problem. By then, the parts are installed everywhere, and the broker relationship is several transactions old.

A quick counterpoint

The building blocks are more accessible than they were five years ago. Caliptra, SPDM, OpenBMC and NIST SP 800-193 are all open. But building blocks are not a program. The hyperscalers still staff silicon and firmware security teams to run theirs. Settle one question before committing: Will you fund that function every year, for as long as the fleet runs?

The 10-question test

Skip the argument over whether buying direct is optimal. First, work out whether your organization has the preconditions that make it safe. Answer these honestly: 

1. Volume: Do you buy enough servers each year, on a cadence predictable enough to commit to a multi-quarter forecast, to spread a permanent engineering team across the fleet and earn supplier allocation? In our experience, that means tens of thousands of units per year.
2. SKU discipline: Can you standardize your entire estate on five or fewer hardware configurations, and hold that line against every application team that wants an exception?
3. Workload homogeneity: Is the majority of your compute consumed by a small number of horizontally scalable services whose source code you control?
4. Application-layer resilience: Can your critical applications lose a node, without warning, without generating an incident?
5. Firmware and root of trust: Do you employ engineers who can own BIOS, BMC and device firmware qualification, integration and security patching as a permanent function, including key custody, attestation baselines and component verification at receipt?
6. Qualification capability: Do you have a lab and the staff to requalify a platform whenever a component vendor makes a silent revision?
7. Facilities: Can the buildings you occupy accept the rack format, power topology, floor loading and cooling method the candidate hardware assumes?
8. Sparing, logistics and diagnostics: Can you stock and deliver spares at the depth your service levels require and root-cause an intermittent memory or PCIe or thermal fault across four vendors with no design documentation and nobody to escalate to?
9. ISV independence: Are your business-critical applications free of hardware certification requirements? Check SAP, Oracle, Broadcom and VMware, Nutanix, your EMR vendor, your core banking platform and your backup software before answering.
10. Risk appetite: Is your organization prepared to become the manufacturer and importer of record, to self-insure the warranty, absorb product liability and proceed without intellectual property indemnification?

Score one point for each yes. The four highlighted rows are gates, because each takes years to build and cannot be bought with a quarter. A no on any of them means you are not ready to build, whatever your total. Eight or more yeses, with all four gates cleared, means build it. Three or fewer means the path costs more than it saves. Everything else means the case is unsettled and needs costing, not a decision.

Across the large enterprise environments we work in, most organizations get to yes on two or three of these. Risk appetite is the most common and matters least, since an executive can decide it in an afternoon. Application-layer resilience, firmware ownership, qualification capability and ISV independence are the hard ones, because each needs a capability that takes years to assemble. 

Where the ODM model works

There is a good version of this. Whitebox and ODM sourcing fit well, sometimes obviously better than the alternative, for a particular set of workloads:

• Single-purpose scale-out storage: Ceph, MinIO, HDFS and their relatives, where the software layer handles replication, rebuild and node loss because it was designed to. The hardware is a brick, and the software knows it.
• High-performance computing and rendering: Long-established whitebox territory, with an operating culture that already includes in-house hardware skills and job-level fault tolerance.
• Log analytics and observability tiers: Elastic and Splunk indexer tiers and similar shard-and-replicate architectures.
• Non-production and dev/test: Where an extended outage is an inconvenience rather than an incident.
• Edge, kiosk and purpose-built appliances: High unit counts, low per-unit criticality and physically constrained form factors that OEM catalogs serve poorly.
• Air-gapped and sovereign environments: Where OEM support cannot reach the equipment anyway, so the support differential shrinks toward zero.

What ties these together is that failure gets handled somewhere other than the hardware.

AI and HPC clusters deserve their own answer

Large GPU clusters sit much closer to HPC than to your general-purpose estate, and the ODM case there is strong enough. Schedulers already absorb node loss because these clusters run batch training and inference workloads with checkpointing built in, so a failed node is a restart rather than an incident. 

Leading AI reference architectures have taken over much of the platform engineering that an OEM would otherwise handle. They specify topology, power and thermals in enough detail that the differentiation between an OEM build and an ODM build narrows considerably. ODM Direct still accounts for just over half of worldwide server revenue, though its share fell from 64% to 50% year over year in the first quarter of 2026 as branded OEMs won more AI infrastructure work. Buying an AI cluster through an ODM or an ODM-derived line is a defensible decision on its own terms, and plenty of sophisticated operators make it.

Two cautions:

1. New GPU supply is running at three- to seven-month lead times on current-generation parts, with allocations shifting week to week, and a self-assembled cluster gives you no priority in that queue. Replacement parts for accelerators can run to many weeks. When a training run depends on a specific node count, an extended RMA is not an inconvenience. It's idle capacity you already paid for, and the calculation should include how many spare GPUs you intend to hold on a shelf against that. For a large fleet, that spare pool is itself a substantial capital commitment.
2. The second caution is the more dangerous one. AI fleet economics should never be used to justify an ODM strategy for the rest of the estate. The two environments do not resemble each other. A GPU training cluster is homogeneous, scheduler-managed, checkpointed, staffed by people who understand it, and often physically separate. Your general-purpose estate is heterogeneous, runs purchased software with certification matrices and sits underneath applications that treat a lost node as an outage. A successful AI cluster build proves that your organization can do this for a homogeneous fault-tolerant workload, which is worth knowing. It proves nothing about the ERP platform, and we have seen that inference drawn more than once.

The line between OEM and ODM is blurrier than this framing suggests. Supermicro has always occupied the middle ground, building to ODM-like configurability and price while still providing a warranty, a support organization and a named counterparty. Several OEMs now sell hyperscale-derived lines with reduced features and pricing to match. 

The third path: What to do instead

You have more than two options. In our experience, most organizations have plenty of room between list price and self-assembly before building becomes the last lever.

Commercial levers

• Multi-year commitments: Forecast is the currency in this market. Committing volume across several quarters gets you pricing and allocation that spot purchasing cannot reach, and it is the same mechanism the hyperscalers use. Pair the commitment with a negotiated discount off list. Fewer configurations ordered in larger batches are easier for a vendor to fulfill and cheaper for you to support, so configuration sprawl is costing you twice over. Unlike a self-built fleet, a vendor commitment transfers warranty, firmware and support obligations to the vendor and can be sized to forecast demand.
• Hyperscale-derived OEM lines: Ask specifically about ODM-derived and cloud-optimized product lines, where you get a stripped feature set at a lower price while keeping the warranty and the support relationship.
• Tier-two vendors with a support wrapper: A middle tier exists between tier-one OEMs and raw ODM components, and a partner can often assemble a credible support model around it. What needs to be established is whether a named counterparty owns break-fix and holds the warranty.
• Consumption and leasing models: Where component price volatility is the actual problem, moving it onto a vendor's balance sheet may be worth more to you than a unit discount.
• OCP-compliant procurement: Buy to Open Compute Project specifications through vendors that support them, capturing design efficiency without owning the design. Check the facilities implications first.
• Bill-and-hold agreements: Lock in current pricing on inventory you need later, with the vendor holding the stock. This turns a forecast into a price commitment without requiring you to take delivery before you can use the hardware.
• Independent memory price tracking: Memory is the one line where an OEM premium can be large. WWT's research notes that OEMs have charged nearly double open-market pricing when buyers lack visibility. Track open-market DRAM and NAND pricing yourself, and use that data in negotiations. You can benchmark the price without buying components.

Architectural levers

• Lifecycle extension: When new hardware costs materially more than last year's and arrives 40 weeks late, extending healthy assets is often the highest-return decision on the table. Start with 12 to 18 months for platforms with clean reliability data. WWT's research suggests that some organizations extend lifecycles for up to 7 years, typically with third-party maintenance once OEM support ends. Be careful there. Once the OEM stops supporting a platform, you stop receiving validated firmware patches, which reinstates the security obligation described in this note. It needs honest reliability data, a firmware patch plan and a real risk assessment rather than a depreciation schedule.
• Consolidate, and watch what it does to your licensing: This is the lever most often undersold. Oracle, Broadcom and VMware, and Microsoft all price against hardware configuration, whether by core, by socket or by physical host, so the configuration you choose sets a software bill that can dwarf a 25% hardware saving in either direction. Fewer, denser hosts running at higher utilization cut the number of machines you buy and the number of licensed cores you pay for annually. The reverse holds too: a cheaper server with a higher core count can raise your Oracle or VMware bill by more than the hardware saved, and that outcome shows up every year rather than once. Model licensing alongside hardware, because for many enterprises, it is the larger number.
• Tier the memory: Memory is the constrained and inflating component, so paying close attention to actual utilization has an unusually high payoff right now. Some organizations are buying at reduced capacity, with plans to expand once pricing settles. Memory tiering puts a smaller DRAM tier in front of a larger, cheaper capacity tier, NVMe today and CXL-attached memory as it matures, keeping hot pages in DRAM while cold pages fall back. For consolidation-driven workloads with large but cold working sets, this can cut DRAM per host exactly when DRAM is the line item inflating fastest. It is not free. Latency-sensitive and in-memory database workloads will not tolerate it, and ISV support matrices are still catching up, so verify before planning capacity around it.
• Secondary market for non-critical tiers: Certified pre-owned hardware is a mature option for dev/test, non-production and lower-tier workloads.
• Selective placement: Not every workload needs new on-premises hardware, and not every workload belongs in a cloud. What matters is making the sourcing decision and the placement decision together rather than sequentially.

This is the work we would rather do with you. Less dramatic than building your own servers, and it usually recovers a good share of the savings without creating new obligations.

How WWT works with clients

If you want to evaluate this, we can help. 

Our support and services

We work with clients to:

• Run a structured evaluation in our Advanced Technology Center, testing OEM, tier-two and ODM-derived platforms head-to-head against your actual workloads rather than against a specification sheet.
• Build a full lifecycle cost model with you, covering the migrated costs described above and the software licensing consequences, so the business case reflects the whole picture.
• Work through the facilities question early, so rack format, power topology and cooling get settled before a platform decision rather than after one.
• Develop reference architectures and configuration standards, and help you bring SKU sprawl back under control.
• Design and negotiate the commercial and architectural alternatives described in the previous section.

Where OEM support is still needed

WWT cannot substitute for everything an OEM offers. Services such as a hardware warranty, a spare parts depot, field break-fix and ongoing firmware and BMC maintenance all depend on manufacturer relationships, entitlement data and engineering documentation that exist only within the OEM model. That's a structural limit that applies to self-assembled and ODM-sourced systems, no matter how an engagement is scoped.

Independent software vendor (ISV) support is a key issue to talk through early. We can help you map which of your applications carry hardware certification requirements and where the exposure sits, though we cannot create a certification or an escalation path that the software vendor does not offer. What that means in practice depends on your application estate, and it's a conversation worth having before a purchase order is placed.

Where a genuine middle path exists (e.g., a tier-two platform with a named warranty counterparty or an integrator relationship carrying real support obligations), we will help you find it and pressure-test what is being promised. Those arrangements vary widely, so examine each one.

Conclusion and next steps

Server costs are up, and lead times are long because three memory manufacturers shifted capacity toward AI, and the world's largest buyers locked up what was left. We expect that to persist through at least 2028.

Going directly to ODMs does not solve this problem. It only puts you further back in the same queue and moves eight obligations, six of them recurring, from a vendor's balance sheet onto your own. The hyperscalers who run this model successfully do it on the strength of an operating model that took them a decade and enormous investment to build.

Take our 10-question test above. If you meet the preconditions, build it. If you don't, the savings you're looking for will come from commitment structures, standardization, lifecycle extension, licensing and utilization.

Before anyone commits budget, test the answer against your own workloads.