01
Find out what the server actually does
Before you can move anything you need an honest inventory. The dangerous items are never the obvious ones - it's the scheduled task that emails a report to a client every Monday, or the printer driver share nobody has thought about since 2019.
- File shares: which ones, how big, who uses them and how often.
- Applications installed locally, including anything a single department depends on.
- Databases, and which applications talk to them.
- Authentication - is this the domain controller people log in against?
- Print services, licence servers, backup jobs and scheduled scripts.
- Anything with a hardware dongle or a licence tied to the machine itself.
Ask each department what breaks if the server is off for a day. You'll uncover dependencies no technical audit finds.
02
The three honest options
Keep it going
Sometimes right, usually temporary. It makes sense when a genuine change is coming within the year - a move, a system replacement, a merger - and you need to bridge the gap. Be honest that it's a bridge, and agree when it ends.
Replace with new hardware
Still the right answer more often than cloud vendors suggest. If you have large files being edited all day, a line-of-business application that needs to sit next to its data, or connectivity that can't be relied on, local hardware wins. Budget for the whole picture: hardware, licences, installation, backup and the next refresh in five years.
Move to the cloud
Usually the best long-term answer for file storage and identity, and the point at which hybrid working stops being a compromise. It's rarely cheaper month to month; the value is in resilience, access and not owning a box that ages. Check the applications first - some genuinely don't move well, and hosting a server in the cloud to run one legacy app is a decision to make consciously, not by accident.
Cost the options over five years, not one. A cheap replacement server with an expensive support contract can outspend a cloud migration by year three.
03
Sequencing the move
The mistake is doing everything in one weekend. Split it into stages with a working state at the end of each, so you can stop, breathe and roll back if something surprises you.
- Stage one: clean up. Archive dead data before you move it. Most organisations shift thirty to fifty per cent less than they expected.
- Stage two: identity. Get logins working the new way while the old server is still there as a safety net.
- Stage three: files, department by department, starting with the least critical so the process gets rehearsed on low stakes.
- Stage four: applications, one at a time, each with a tested fallback.
- Stage five: printing and the odds and ends, which always take longer than planned.
- Stage six: decommission - only once nothing has called on the old server for a full month.
04
What disruption to expect
- Signing in will change, and some people will need help on the first morning. Plan for that rather than hoping.
- Shortcuts and mapped drives will break. Fix them in advance where you can and expect a handful of stragglers.
- The first week after a file move feels slower to people, even when it isn't, because things are in unfamiliar places.
- One department will discover a dependency nobody documented. Leave slack in the plan for it.
Tell people what's changing, when, and who to contact. A short note beforehand prevents more support calls than any amount of technical preparation.
05
After the move
- Confirm backups cover the new location, and do a real restore from it.
- Review who has access now that permissions have been rebuilt - migrations are a rare chance to tidy this up.
- Wipe and dispose of the old hardware properly, with a certificate if you're regulated.
- Cancel the maintenance contract, the licences and the power you're no longer using.
- Write down what the new setup looks like while it's still fresh.