
Most businesses that still have a server in the office have exactly one, and it's doing several jobs at once: files, an old application, maybe printing and user logins. Retiring it is a good idea in most cases — but it goes wrong when nobody wrote down what it does. Use this checklist before you talk to anyone about migrating.
1. Inventory what the server actually does
- Which applications run on it, and which vendor supports each one?
- Which devices talk to it — printers, label printers, scanners, EFTPOS, machines on the workshop floor?
- Does it run user logins (Active Directory)? Group policies? DNS and DHCP?
- Where do backups go today, and when was the last time anyone restored one?
2. Decide where each job goes
Files usually belong in SharePoint/OneDrive or a hosted file server. Email is almost always Microsoft 365. Line-of-business applications are the fork in the road: some have a cloud version, some will run happily on a hosted server, and some only run locally. Identity (logins) can move to Microsoft Entra ID with Intune managing devices, or stay on a hosted domain controller if an application demands it.
3. Check the internet before the plan
Hosted desktops and applications need a business-grade connection with a decent upload speed and, ideally, a second link for failover. If your site can't get that, a managed private cloud on site is a better answer than a slow public one.
4. Ask about licensing early
Windows Server, SQL Server and Remote Desktop licences have specific rules about where they can run. Find out what transfers and what needs to be re-licensed before the quote, not after.
5. Insist on a written cutover plan
Data replicated in advance while you keep working; a test with real staff; a cutover outside business hours (usually a weekend); the old server kept powered but offline for an agreed fallback window; and a named person responsible for each step. If the plan is "we'll copy it across on Saturday", ask for a better plan.
6. Prove the backups on the other side
Cloud doesn't mean backed up. Confirm what's backed up, how often, how long it's kept, how quickly it can be restored — and do a test restore in the first month.
When to keep the server
Poor connectivity, a legacy application that only runs locally, or equipment on the floor that needs a local system to talk to are all legitimate reasons to keep — or replace — an on-site server. A hybrid design (cloud for email and files, local for the one stubborn application) is common and perfectly sensible.
If you'd like a second opinion on your own server, our cloud hosting page explains how we approach it, and the office is on (02) 9053 0915.