Do You Still Need an On-Premise Server?

The question worth asking before the next hardware refresh

Somewhere in a lot of small businesses is a server. A physical box, probably in a comms cupboard or under a desk, that has been running since before anyone currently on the team joined. It still works. Nobody wants to touch it. And every year it goes untouched, the question of whether you still need it gets more expensive to answer.

This isn't an argument that every business must be 100% cloud. It's a framework for a decision most small businesses are putting off: what that box is actually doing today, what replaces each of those jobs, and the specific cases where keeping some local infrastructure is still the right call.

What the server in the closet is actually doing

Before deciding whether to keep it, it helps to separate the roles bundled into one physical machine. A typical small-business server on-premise is usually doing some mix of:

• File storage - a shared drive everyone maps a letter to.
• Identity - a local Active Directory domain controller that checks passwords and hands out permissions.
• Backup target - the destination other machines write their backups to.
• A line-of-business app - older accounting, practice-management, or industry-specific software that was installed directly on the server years ago.
• Print management - a shared queue for the office printer.

Most small businesses never wrote this list down. They bought "a server" once and it grew into doing whatever needed doing at the time.

What replaces each job in the cloud

Once the roles are separated, most of them have a direct cloud equivalent that a small team can run without anyone on-site managing hardware.

Identity is the one worth being precise about. Microsoft Entra ID is a genuine cloud identity and access management service, and for most small businesses it can take over what a domain controller did - checking who someone is and what they're allowed to touch. But Microsoft's own positioning for Entra ID describes centralised management "whether they're in the cloud or on-premises" rather than a flat claim that it replaces a domain controller outright^[1]. In practice: a small business with nothing unusual running (no legacy app that authenticates against local AD) can usually go cloud-only. A business with one piece of software that still needs a domain-joined machine keeps a much smaller, scoped setup instead of retiring nothing.

Backup is the one where "replace" undersells it. A local backup box sitting on the same network as the server it protects is reachable by anything that reaches the server - the same ransomware, the same electrical fault, the same theft. Moving the backup destination off-site by default doesn't just modernise it. It removes the single point of failure that a local backup device is, by definition, sitting right next to.

The clock already running on old hardware

If that server is running Windows Server 2012 or 2012 R2, extended support ended on 10 October 2023. Microsoft's own guidance is blunt about what that means: no further security updates unless you buy Extended Security Updates, which are free for three years only if you migrate the workload to Azure, and a paid, time-limited option if it stays on-premises^[2].

Windows Server 2016 has a later but equally real deadline: extended support ends 12 January 2027, and Microsoft is already pointing customers toward upgrading, Extended Security Updates via Azure Arc, or migrating to Azure^[3]. If your server is running either of these, "it still works" and "it's still supported" are two different sentences, and only one of them is getting less true by the day.

Why "someone local to plug into" isn't the safety net it used to be

A common reason small businesses keep a server around is a version of "if something breaks, someone can just walk over to it." That instinct is worth examining rather than dismissing, because the way small businesses are actually managed today has already moved past it.

Remote monitoring and management (RMM) tooling is how a managed IT provider watches and fixes devices without being in the building - it's the platform running in the background of every device we manage, including the ones that never touch a local server at all. That's not a reason to be cavalier about it: Microsoft's 2025 threat research found that an RMM tool was present in 79% of the ransomware cases its incident-response team investigated that year, and that over 40% of ransomware attacks had a hybrid component spanning both on-premises and cloud infrastructure^[4]. The lesson isn't "avoid remote management" - it's that RMM access itself needs the same controls as anything else with reach into every device: multi-factor authentication on the console, scoped technician access, and alerting on anything unusual. A locally-run RMM platform, tightly access-controlled, is not the same risk as a legacy remote-access tool nobody has audited in years - and it's already how most small-business IT gets managed, server or no server.

What keeping the box actually costs, versus retiring it

The honest comparison isn't hardware price versus subscription price - it's total cost including the parts that don't show up on an invoice. From our own work retiring on-premise servers for small teams, the recurring costs of keeping one running tend to be:

• A hardware refresh every 4-6 years, plus the Windows Server and Client Access Licences that come with it.
• A UPS and, in some offices, dedicated cooling, so the box survives a power blip.
• Someone's time when it needs a reboot, a driver update, or a disk swap - usually at the worst moment.
• The downtime risk of a single machine that, if it fails outright, takes file access, sign-in, or both down with it until it's fixed or replaced.

Against that, Microsoft 365 Business plans are priced per user, per month, with no hardware to refresh:

For a ten-person team, Business Premium at current pricing works out to a predictable monthly line rather than a lump sum every few years^[5]. That's not automatically cheaper for every business - a server that's fully paid off, still supported, and doing one narrow job can be the cheaper option for another year or two. It stops being cheaper the moment it also needs a hardware refresh or has crossed its support end date.

When keeping some local infrastructure is still the right call

This isn't a case for retiring every server on principle. There are genuine reasons to keep some local infrastructure:

• Line-of-business software that only runs locally. Older accounting, legal case-management, or industry-specific tools sometimes have no cloud-hosted version. If the vendor doesn't offer one, the honest move is to shrink the server to just that one job rather than retire it - not to keep the file share and the domain controller and the backup target running alongside it out of habit.
• Genuinely unreliable internet. If a connection drops for hours at a time, moving every function to the cloud trades one single point of failure for another. This is uncommon in most of the markets we work in, but it's a real reason where it applies.
• Very large local file libraries. Video, CAD, or imaging files in the multiple-terabyte range are still awkward and expensive to keep fully synced to the cloud for a small team. A local store with cloud backup can be the pragmatic middle ground.

None of these are arguments for keeping the file share, the domain controller, and the backup target all running on one general-purpose box "just in case." They're arguments for keeping exactly the piece that still needs to be local, and moving everything else off it.

How the move actually happens

1. 1Inventory every role the server performs - file storage, identity, backup, any installed line-of-business app, printing. Nothing gets decommissioned until every role has a named replacement or a documented reason to stay.
2. 2Stand up the cloud equivalent in parallel. SharePoint libraries, Entra ID, cloud backup, and the RMM/Intune management layer all get configured and tested before anything moves.
3. 3Cut over role by role, with a rollback window. Files first, then sign-in, then backup. The old server stays reachable but read-only for a defined period in case something was missed.
4. 4Decommission and wipe. Once nothing depends on it, the server is securely wiped and retired rather than left running "just in case" - which is usually how a second forgotten server ends up in the same closet five years later.