Running a Server Refresh Project End to End: A Working Plan

A server refresh looks simple from the outside: buy a new one, move things over, turn the old one off. In practice it touches every application, every backup job, every firewall rule and every user who has a mapped drive. The projects that go badly are the ones where somebody found out about a dependency during cutover.

Here is the plan we follow, phase by phase, for a typical small-business server refresh: a file and application host, often also a domain controller, moving to new hardware or to a hypervisor.

Phase 1: know exactly what the old server does

Before sizing anything, inventory the roles. Domain controller, DNS, DHCP, file shares, print server, the line-of-business application and its database, a scheduled task someone wrote years ago.

Then find the consumers. Who maps which share, which workstations print through it, which applications have its name or IP in a config file, which vendor has a VPN into it. The old address and hostname are the most common hidden dependencies; keep both if you can, or list every place they appear.

Roles: AD, DNS, DHCP, file, print, application, database, backup target, certificate services
Shares and permissions, exported with a script so nothing is retyped
Scheduled tasks, services set to Automatic, and anything running as a named account
Firewall rules, NAT entries and vendor VPNs that reference the server
Backup jobs that protect it and backup jobs that run on it

Get-SmbShare | Where-Object {$_.Special -eq $false} | Select-Object Name, Path
Get-ScheduledTask | Where-Object {$_.State -ne 'Disabled'} | Select-Object TaskName, TaskPath
Get-Service | Where-Object {$_.StartType -eq 'Automatic' -and $_.Status -ne 'Running'}

Phase 2: design and buy

Decide the shape first: one physical server, a hypervisor with the roles split into separate VMs, or some roles moved to cloud services. Splitting roles into VMs is almost always worth it; a domain controller that is not also the file server is easier to patch, back up and replace.

Size from measured data, not guesses. Pull CPU, memory and disk growth from the old server's monitoring over a few months. Add headroom for the planned lifetime and for the roles you are moving in. Order hardware with the vendor's next-business-day support and write the support end date into the inventory the day it arrives. Order the OS, hypervisor and backup licences at the same time, because a server waiting on a key is a server not being built.

Choose physical, virtual, or hybrid, and which roles move to cloud services
Size from monitoring data with headroom for the support lifetime
Order hardware, licences and any new backup capacity together
Book the rack space, power and network ports, and confirm the UPS can carry the load
Write the cutover window and the rollback window into the project plan now

Phase 3: build, migrate, and rehearse

Build the new host alongside the old one on the production network with a new name and address. Patch it, join the domain, install the backup agent, and add it to monitoring before any data moves. If it will be a domain controller, promote it now and let replication settle for days, not hours; move the FSMO roles and confirm DNS and DHCP are serving from the new host before you touch anything else.

Copy file data with a tool that preserves permissions and can run again to pick up changes: robocopy with mirror and security options, or the storage vendor's replication. Do a full copy days ahead, then a final incremental during cutover. For the application, install fresh on the new host, restore the database from a backup, and have the vendor or the client's power user test it against the copy. That test is the rehearsal; a failure there is a problem found while the old server still works.

robocopy \\\\OLDSRV\\Data D:\\Data /MIR /COPYALL /R:2 /W:5 /MT:16 /LOG:C:\\Temp\\data-copy.log

Phase 4: cut over, verify, and decommission

Cutover happens in the agreed window with the client notified twice. Stop the application on the old server, run the final data sync, restore the final database backup, and repoint: DNS records, DFS namespaces or mapped-drive scripts, printers, firewall rules, the vendor's VPN. If you kept the old name and IP by renaming the old server first, most of this is one DNS change. Then test from a workstation as a real user.

Leave the old server powered on but disconnected from the network for the rollback period. If nothing is missed after a week or two, wipe it, record the wipe, and update the documentation. Close with the acceptance checklist signed and a restore tested from the new host.

User can log in, reach shares with the same paths, and print
Application opens, reports run, and the vendor integration works
Backups of the new host completed and a test restore succeeded
Monitoring shows the new host healthy and the old one retired
Documentation, inventory and firewall rules reference only the new host

Frequently asked questions

Can we keep the old server name and IP?

Yes, by renaming and re-addressing the old server just before cutover, then giving the new one the original identity. It removes most repointing work but needs careful ordering for domain controllers; rehearse it if you can.

How long should the old server stay available?

Long enough to cover a month-end or whatever cycle the business runs, typically a couple of weeks to a month. Disconnected from the network, not powered off, so a forgotten file can be retrieved quickly.

Should we move to the cloud instead of buying a server?

Often for file storage and email, sometimes for the application, rarely for everything at once. Decide per role during design. A refresh is the right time to move what moves easily and keep on hardware what does not.

Takeaway

Inventory the roles and their consumers before you size anything, build the new host alongside the old one, migrate with tools that can re-run, rehearse the application on the copy, and cut over in a window with a real user test. Keep the old server offline but intact for a rollback period, then wipe it and fix the documentation. The dependency you find in phase one is the outage you avoid in phase four.