Skip to content
Client login

Free Audit

IT & infrastructure

Windows Server: what you actually buy when you buy a server

The machine is bought once, the right to use it is paid per person. And it carries a written end date, which is the only certain one in this pillar.

Published on 22 June 2026 — Algeria Agency

A server is not one purchase but three: the machine, the system running on it, and the right for each person to connect to it. The quotations we get shown nearly always carry the first, often the second, rarely the third.

That is the commonest reason a server project costs more than planned, and it is not a nasty technical surprise: it is a line that was never counted, and it counts per person rather than per machine.

This page sets out the three purchases, what a server actually does in a twenty-person business, and the only date in this whole pillar you can plan anything against.

It also carries this family’s most expensive refusal for us: a substantial share of the businesses asking us for a server do not need one, and section 7 says how to recognise it.

A server is three purchases

The first purchase is the machine, and it is the one everybody talks about: disks, memory, a redundant power supply, a warranty. It is visible, it compares, and it usually represents half the real spend.

The second is the system. It is licensed by processor core count, with a minimum billed even if the machine has fewer — a detail that surprises people, because it disconnects the price from the power actually used.

The third is the right to connect, a licence per person or per device reaching the server. That is the one that goes missing, and its size grows with your headcount while the machine does not change.

Those three purchases do not share a rhythm. The machine gets replaced every five to seven years, the system follows a written end date, and connection rights follow your hiring. A budget that conflates them is wrong from the second year.

The practical consequence fits in one demand to make before any comparison: require the quotation to separate the three lines and to state how many connection rights are included. Two proposals at the same total can differ by half on that line alone.

Connection rights, the invisible half

This line deserves its own section because it is the most regular source of the gap between the signed quotation and the invoice in use, and because leaving it out is perfectly legal — nothing obliges a seller to count your employees on your behalf.

The principle is simple: the server is licensed to exist, and every person connecting to it is licensed to use it. The count runs on users or on devices, your choice, and the right choice depends on a ratio only you know.

The deciding rule: if your employees each use several devices — a desktop, a laptop, a phone — count by person. If several people take turns on the same machines, as in a workshop or a production room on three shifts, count by device. The gap between the two calculations is often a factor of two.

What escapes the count most often: people who never open a session on the server but whose software connects to it. A till, a barcode reader, a network printer, a lookup terminal. They reach it, so they count.

The check to run before signing rather than after: ask the supplier to write down the number of rights included and the counting assumption used. A quotation that does not write it leaves regularisation at your expense, and it arrives at the most unpleasant moment — an inspection, a renewal, or a support desk refusing to act.

The only certain date in this pillar

Almost nothing in this pillar can be planned against a reliable calendar. A failure has no date, nor does a theft, and the moment a disk gives up is known to nobody. There is one exception, and it is published in advance.

Every edition of the system carries an end of security fixes that is written down and committed to by the publisher. It is not a forecast: it is a date on which fixes will stop being issued, known years ahead, and it does not move.

Counted in months from today rather than in years, it changes character. "Supported until 2027" reads as far away; five months reads as a budget quarter, and that is exactly what it is for a machine installed in 2018 and never brought up to date.

What the end of fixes means concretely: the machine keeps running normally. It does not stop, it displays nothing, nothing visibly changes. It simply stops receiving corrections for flaws found after that date, and those flaws keep on being found.

So it is the one line in this pillar that goes into a forward budget with an exact date. Use it: a replacement decided twelve months ahead gets negotiated, planned out of season and tested; the same replacement decided after the deadline happens in a hurry and at the price of a hurry.

Months of security fixes remaining, by edition
  • 2016 edition5months
  • 2019 edition29months
  • 2022 edition62months

Microsoft fixed lifecycle policy, consulted 2026

What a server actually does in a small business

Before sizing it, what it does has to be named, because the real list is short and does not resemble what a catalogue describes.

In the great majority of twenty-person businesses we see, the server does four things: it holds shared files, it keeps the user accounts, it runs one line-of-business package — accounting, sales management, production — and it acts as a shared printer.

Three of those four demand hardly any power. File sharing is limited by the network, the directory by nothing at all, printing by the printer. The only one that genuinely consumes is the business package, and its consumption depends on its publisher rather than on your headcount.

The consequence is a systematic imbalance in quotations: the processor and memory get sized for a use that does not exist, and the disks get under-sized, which is the only thing that will genuinely run short in three years.

The question to put to your business software publisher, and to nobody else: what are its written requirements, and how many simultaneous sessions do you really have. Its answer replaces the whole rest of the hardware conversation, because it is the only constraint that cannot be worked around.

The directory is what you actually buy

If one function had to be kept, it would be this one, and it is the least spectacular: a single place where people’s accounts exist, with what each of them is allowed to open.

Its value is invisible at installation and visible when an employee leaves. Without a directory, somebody leaving leaves behind eight accesses to close on eight systems, and the company’s audit will find at least one forgotten. With one, it is a single action.

That is precisely the finding the audit article describes as the commonest: a former employee still active. The directory is what makes that finding impossible, and it is the only honest commercial argument on this page.

It brings a second thing people underestimate: a single policy. Password length, automatic locking, what a machine is allowed to install. Decided once, applied everywhere, without a technician visiting each machine.

The limit to state: a directory is useless in a five-person outfit where everybody uses one device and one package. It starts paying at around ten to fifteen users, or sooner if there is staff turnover, and that threshold decides rather than the size of the turnover.

Virtualising changes the replacement arithmetic

Running several logical servers on one physical machine is not a saving trick; it is what decouples the software’s lifespan from the hardware’s, and that is where the real benefit sits.

Concretely: the day the physical machine dies, a virtualised server comes back up on another machine, including one of a different brand and generation. Without it, the same incident demands a full reinstallation, and a reinstallation demands passwords and media nobody can find.

It also changes how an update gets tested. Duplicate the server, apply the update to the copy, see whether the business package survives, throw the copy away. Without that option every update happens in production, which is why so many servers never get updated.

The cost of that flexibility is real and has to be stated: one more layer to understand, an extra licence in some cases, and a different backup point — whole machines now get backed up, which is simpler and bulkier.

Our default position: virtualise even when there is only one server, precisely because there is only one. That is the arrangement where a hardware failure hurts most, so it is the one where being able to restart elsewhere is worth most.

The machine does not die, it leaves support

The scenario directors dread is abrupt failure. The scenario we meet is slower and more expensive: a perfectly functional machine that is simply no longer backed by anybody.

Three kinds of support end on different dates and they have to be told apart. The manufacturer’s hardware warranty, which decides who comes to repair it. The system’s support, which decides security fixes. And the support of your business software publisher, which decides whether anybody answers the phone.

The third is what genuinely triggers replacements, and nobody watches it. A publisher announcing that its new version requires a more recent system has just set your renewal calendar, whatever the health of your machine.

There is an honest intermediate answer, rarely offered: isolation. A machine out of support running an old business package can be cut off from the internet, reduced to its strict local use, and kept two more years while the replacement is prepared properly.

That answer carries one non-negotiable condition: it does not apply to a machine that receives mail, browses the internet, or hosts anything reachable from outside. Isolate means isolate, otherwise it is leaving a door open while writing that it is shut.

The server that should not have existed

The sentence that costs us most in this family has to be written down: a substantial share of the businesses asking us for a server do not need one, and it is the largest single invoice in the whole pillar.

It is recognised by four signs. Nobody opens a session on the server itself. No business package requires a local database. The shared files fit in a few hundred gigabytes. And headcount is below about ten stable people.

In that arrangement, a shared storage box with its copies, hosted mail and properly managed workstations do the same job, cost markedly less to buy, and above all carry neither access licences nor an end-of-support date.

The switch happens when one of the four conditions falls. A business package requiring a database on site, a headcount past a dozen with turnover, or a need for common policy on the workstations: at that point the server becomes the right answer, and not before.

What we refuse is the direct consequence: we will not sell a server to a business ticking all four signs above, even if it asks us explicitly, without having written down in plain terms what it is buying in excess and why.

The room, the heat and the dust

The infrastructure article handles electricity, and we are not reopening it here. Two other physical constraints nonetheless decide a machine’s real lifespan, and they belong to where you put it.

Heat is the first. A server placed in a closed cupboard, in a room with no ventilation, or in a south-facing office in summer, runs permanently at a temperature that shortens the life of its disks and its power supply. It does not stop; it ages faster, which is harder to see.

Dust is the second, and it is particularly underrated in premises near a workshop, a road or a building site. Filters clog, fans strain, temperature rises, and we are back to the previous paragraph.

Three measures are enough and none is technical: a room that is not the hottest in the building, clear space in front of and behind the machine, and an annual clean written down somewhere. Those are the three things no quotation contains and that decide the fifth year.

The fourth, less obvious, is the door. A server in a corridor or in a room open to everybody is a server that is physically reachable, and physical access cancels most software protections. A door that closes is a security measure, and the cheapest of all of them.

Updates that break things, and the window they get done in

The root of the problem has to be acknowledged rather than denied: updates sometimes break things, and an old business package is exactly what they break most often. That is why so many servers receive none at all.

The answer cannot be to apply nothing, because a machine without fixes is the only case in this pillar where the risk grows on its own, with nobody doing anything. Nor can it be to apply everything, immediately, in the middle of the day.

The practice that works fits in three rules. Defer by a week rather than applying the same day, because the problems with an update are publicly known within days. Apply to the virtualised copy first. And fix a window — one specific evening a month — rather than waiting for a quiet moment that never comes.

One case deserves separate handling: critical security fixes, which do not get deferred by a week. They are distinguishable from the rest, they are few, and the supplier maintaining you has to be able to say which fall into that category without hesitating.

Finally, the rule that avoids half the damage: before any update, a recent and verified copy. Not a backup in general — a copy made that evening, restorable, whose presence was checked before clicking. An update applied without that is a bet on software you do not control.

What to obtain on handover

A server installation ends with a handover, and that handover is the part most often skipped because the machine already works. It contains five things, and their absence is only noticed on the day of an incident.

The administrator password, written down, given to management, and changed if the supplier changes. It is the item the audit describes as the most frequently lost, and a server nobody holds administrator access to is a server that will get replaced on the day it fails.

The licence evidence: the certificates, the numbers, the count of connection rights acquired and the purchase date. Those documents are useless for years and then absolutely necessary, at an inspection, in a dispute, or during a migration.

One page describing what is installed and why: which roles, which shares, where the data sits, where the backup goes and at what hour. One page, not a report — the audit article explains why the long format is never updated.

Finally, two tests performed in front of you: a file restored from the backup, and a full shutdown and restart of the machine. The second always surprises somebody, because it is the moment the services that do not come back on their own get discovered.

What we do, and what we will refuse to do

What we will refuse: selling a server to a business that does not need one by the four signs in section 7. It is the highest invoice in this family and we would rather write it here than defend it later.

We will refuse to hand over a quotation that does not separate the three purchases and does not write the number of connection rights included. A single total is comfortable for the seller and unreadable for the buyer, and the gap gets discovered twelve months later.

We will refuse to install a machine in a closed cupboard or an unventilated room, and to let an installation leave without the administrator password being in your hands rather than ours.

What we do: sizing decided by your business publisher’s written requirements rather than by a catalogue; virtualisation even on a single machine; the end-of-fixes date written into your forward budget twelve months ahead; the five-point handover, with both tests performed in front of you; and an update window fixed in the calendar rather than left to chance.

And what you can do this week without us: find out which edition of the system runs on your server, look up its end-of-fixes date, and convert it into months. Then count how many people and devices actually connect to it. Those two numbers decide the rest of the conversation.

Frequently asked questions

Why does a server quotation grow afterwards?

Almost always because of connection rights, which count per person or per device rather than per machine. Require the quotation to separate the three purchases — machine, system, access — and to write the number of rights included.

Should we count by user or by device?

By person if each one uses several devices; by device if several people take turns on the same machines. Do not forget what connects without opening a session: a till, a barcode reader, a network printer.

What happens at the end of support?

Nothing visible: the machine keeps running. It simply stops receiving fixes for flaws found after that date. It is the only dated deadline in the whole pillar, so the only one that can be planned twelve months ahead.

Do we really need a server?

Not if all four signs hold: nobody opens a session on it, no business package requires a local database, the shared files fit in a few hundred gigabytes, and headcount is below about ten stable people.

Should a single server be virtualised?

Yes, and especially in that case. It is the arrangement where a hardware failure hurts most, so the one where being able to bring the logical machine up elsewhere is worth most. It also allows an update to be tested on a copy.

How do we handle updates without breaking the business package?

Defer by a week, apply to the virtualised copy first, and fix a monthly window rather than a quiet moment that never arrives. Critical security fixes are the exception and do not get deferred.

Where we come in

End of patching converted into a number of months is a hard figure, and usually closer than people think. It does not say what your line-of-business software needs.

  • We start from your vendor’s written requirements, not from a sales sheet.
  • We separate the three purchases on the quote and write the number of licences.
  • We check the room, its ventilation and its access before discussing a machine.

None of the four signs present: you do not need a server, and buying ahead would cost more than waiting for the first one.

Read next

Let us talk about your project

A free audit, no commitment: we look at your online presence and tell you what is holding it back.

We measure how this site is used with Google Analytics, to learn which pages actually help. You can stop that measurement at any time from the footer. Cookie policy