For years, an aging server set off a simple sequence. Get a quote, wince, buy the replacement, migrate over a weekend. The only open question was when.
In my experience that reflex no longer holds. When a server ages out today, the first question to answer is whether the jobs that machine does still need a machine in your building at all.
Sometimes the honest answer is yes. Often it's partly. The worst outcome is answering by reflex in either direction, because both mistakes are expensive and both run for years.
First, find out what it actually does
Servers pick up extra jobs over the years. The one facing replacement is rarely doing only the thing it was bought for. It holds the shared files, runs an application or two, handles sign-ins, maybe drives the label printers, and quietly performs some task nobody has thought about since the person who set it up moved on.
I'd start with an inventory before asking for any quote. Write down everything the machine does. This is unglamorous work, and it decides everything after it, because each job on the list can have a different best home.
The file shares often belong in the cloud storage you already pay for with Microsoft 365. Check whether the accounting application has a cloud version now; it can also be the one thing that still needs local hardware. The mystery task needs identifying before it turns into a mystery outage.
The honest case for each direction
Cloud is the right home for the workloads that fit it. The hardware refresh cycle disappears, the building stops being a single point of failure, and capacity becomes something you adjust month to month. But it isn't automatically cheaper, and anyone who tells you otherwise is selling something. The monthly cost runs forever and some applications work worse at a distance. I've also seen a business with modest internet service find the cloud is only as good as the connection to it.
Local hardware is still the right answer more often than the marketing admits. That includes manufacturing systems that talk to machines on the floor, applications whose cloud versions are immature, workloads where the five-year arithmetic favors owning, and operations that have to keep running when the internet doesn't. I've recommended a new server plenty of times, because sometimes it's the correct answer.
Most businesses we take through this land in the middle. Some workloads go through a cloud migration, and some stay on a smaller and simpler machine than the one being replaced. The proportions differ every time, and they come from the inventory.
Timing a server replacement
The other lesson I've learned repeatedly is that this decision goes badly under deadline pressure. A server that dies before the decision gets made removes most of the good options, because a migration done during an outage is planned for speed. The window for a calm decision opens years before the hardware fails, and it closes abruptly.
We wrote a plain-language guide on exactly this, when to replace a server and when not to, which covers the timing signals in more detail. The wider decision fits inside our IT consulting work, with the cloud side handled by the same people. That keeps the recommendation honest, because we do the work in either direction and have no reason to push one.
If there's a machine in your building with a birthday you'd rather not think about, schedule a call. Bring nothing but a rough idea of what it does. The inventory is the first step anyway, and in my experience, starting it while everything still works is the whole trick.