A refresh is a continuity project
Replacing servers looks like a hardware purchase, but what is really at stake is whether applications and data stay available while it happens. Migration windows, backups, platform compatibility and support capacity all decide whether a refresh goes smoothly. Treat it as a one-off purchase and those dependencies get missed.
Agree at the start what success means beyond price and delivery date: a stable migration, and support that is ready when the new systems go live.
Start with what you have
Before talking about replacements, get a clear picture of the current estate: what runs where, how old each platform is, when support coverage ends, where performance is already tight and what still depends on legacy systems.
Then find where the risk sits. Some systems can be replaced in stages; a few cannot take any delay at all. Sort everything into three groups (replace now, replace next, keep watching) and most of the RFQ is already written. Suppliers can respond better too, because they can see what is urgent.
Buy in phases that follow the migration
Plan the purchasing and the migration together. Good unit pricing doesn’t help if the hardware doesn’t fit the migration plan, and a migration plan that ignores the budget ends in late scope cuts.
Large refreshes work better as a few RFQs than as one big one. Start with the systems that carry the most risk and use them to prove the process, then move the main volume, then clear the remaining items. Each phase learns from the one before it.
For each phase, agree how much price movement, lead time and substitution you can accept. Decisions are then made against limits everyone has already signed up to, instead of being argued case by case.
Match quality checks to how critical the system is
Infrastructure your core business runs on deserves more than standard goods-in checks. Verify condition, match every item to its line and check the documents against your own acceptance criteria. For the most sensitive phases, add a validation step before the hardware is handed over for deployment.
Finding a fault in the middle of a migration window costs far more than checking first.
Hardware is rarely the late part
Refreshes usually slip because internal readiness was overestimated: site access, change approvals, test environments, migration staff. Tie delivery dates to readiness checkpoints and mark each phase as ready, ready with conditions, or at risk.
If readiness changes, tell your supplier early. The delivery order can usually be adjusted before it costs anything.
On budget, the cheapest option is not always the cheapest once migration effort and support are counted. Put a line next to each option describing the work it will create, so finance and the technical lead are comparing the same thing.
Sort out support before you sign
Ask how warranty claims and RMAs work, what documentation they need and who you call when something fails during a migration. These details decide how quickly you recover when there is a problem.
Updates to leadership can stay short: where each phase stands, what changed and why, the main risks and who owns them, and which decisions are needed. When a risk comes up, bring two or three options with it. After each phase, review what went right and what didn’t, and carry that into the next one.