Find out what the server really does
Old servers accumulate jobs. Besides the shared drive, one machine might handle user logins, hand out network addresses, run the accounting database, host a print queue, store scanned documents, run a scheduled backup script and act as the licence server for a design package. Some of those roles are invisible until they stop working on the Monday after the move.
Before planning anything, have someone document every role, every shared folder with its size and owner, every installed application, scheduled tasks, mapped drives and printers set up through group policy. Check which staff and devices connect to it. This inventory is the most important part of the project and the part most often rushed.
Decide where each role goes
Shared documents usually move to SharePoint and Teams if you use Microsoft 365, or to shared drives in Google Workspace. User accounts and passwords move to Microsoft Entra ID or the Google equivalent, and laptops are joined to the cloud directory rather than the old domain. Network address handling is normally passed to the router or firewall. Printers can be installed directly on each PC or managed through a cloud print service. Applications are the hard part. Ask the vendor whether they offer a cloud version of the product, whether they support running it on a hosted server, and what that costs. Their answer often decides the whole project.
Clean up before you copy
A ten-year-old shared drive is full of duplicates, abandoned project folders, personal photos and files nobody can open. Copying all of it makes the new system as messy as the old one and slows the migration. Agree a retention approach with the business owner, archive old material to a separate read-only location, and remove obvious junk before migration starts.
This is also the moment to fix permissions. Old file servers often have folders open to everyone because it was easier at the time. Decide who should see payroll, HR and client records, and build the new structure to match. It is far easier to set permissions correctly on day one than to untangle them later.
Plan the cutover
Most file migrations run in two stages: a bulk copy in the background over several days, followed by a final sync of changes over a weekend or evening. Staff work as normal during the bulk copy, then start Monday morning in the new location. The old shares are set to read-only rather than deleted, so nothing is lost if something was missed.
Moving laptops from the old domain to the cloud directory needs more care, because each person's profile, saved passwords and settings can be affected. Doing it one device at a time, or replacing laptops at the same time, avoids a morning where nobody can sign in. Book short training sessions so people know where their files have gone and how to sync them.
Mind the internet connection
Once the server is gone, every file opens across the internet. Check the office connection can handle it, particularly upload speed when several people save large files together. Consider a backup connection so a fibre fault does not stop work. Sync clients store copies of frequently used files on each laptop, which helps, but only if the files people need are actually set to sync.
Run a simple test before cutover: have three or four people open, edit and save their largest typical files from the new location during a busy morning, and time it. A drawing set that took two seconds to open from the old server and now takes forty will cause complaints from day one. If that happens, the fix might be a faster plan, a second line, better Wi-Fi inside the office, or keeping one heavy folder on local network storage while everything else moves.
Keep the old server for a while
Do not wipe the old machine straight away. Keep it powered off but intact for a few weeks, with a final full backup stored separately. When you are confident everything is in place, have the drives securely wiped or destroyed and keep a record of how and when. If the server held personal information, that record matters under the Privacy Act 2020.
Use the quiet weeks after cutover to tidy loose ends. Remove the old server from backup jobs, cancel its software maintenance and support contracts, update your network documentation, and check that the new cloud data is being backed up independently. Ask staff after a fortnight what is still awkward; small fixes such as a missing shortcut or a folder in the wrong place are easy to sort while the move is fresh, and much harder to notice six months later.
In short
- Inventory every job the old server does before choosing where anything goes.
- Ask application vendors in writing whether they support cloud or hosted versions.
- Clean up files and fix permissions before migrating, not afterwards.
- Keep the old server intact for a few weeks, then wipe it securely and record it.