For the clients we already manage, a server usually gets replaced because it’s reaching end of life, and when they need something new, like another application, it can usually fit on the servers they already have. Businesses that come to us for the first time often tell a different story. The operating system on their server is about to lose support, or the old server has become the thing holding up some other project they want to do, and by then the project is usually already late.
A small business server replacement means deciding where each workload on that server should live next, whether that’s new hardware in your office, the cloud, or a mix of the two, and then moving everything over without stranding your staff. This guide covers how we make that call, what tends to make the move harder than expected, and how to plan the switch so the business keeps running.
The data and line-of-business software on your server decide where it should go next, and any switch with user impact should get a scheduled window and a back-out plan.
Signs the Project Should Have Started Already
The first sign is a support date on the calendar. Microsoft’s lifecycle page for Windows Server 2016 shows extended support ending on January 12, 2027, which means no more security updates after that date. Running past it carries risk: CISA’s list of bad practices puts unsupported or end-of-life software first, and calls it especially dangerous on systems reachable from the internet.
The second sign is quieter. A new phone system, a software upgrade, or a move to a new office keeps getting pushed back because “we need to deal with the server first,” so every month the server waits, those plans wait with it.
Work backward from the date and the timeline gets tight fast. Planning, vendor conversations, ordering hardware, building the new environment, and scheduling the move each take time, so a server that loses support in January can’t wait until December to start. If you want the broader picture of what keeps a network dependable day to day, we’ve covered what makes small business IT infrastructure reliable separately.
New Server, Cloud, or a Mix: What Decides It
We start with two questions: what data lives on the server, and which line-of-business applications run on it. Line-of-business apps are the programs your company runs on, such as accounting, practice management, ERP, or design software.
| What’s on the server | What we usually advise | Why |
|---|---|---|
| Large files, such as CAD drawings | Keep them on a server in the office | CAD shares are often several terabytes. In the cloud, staff either download files one at a time, which is slow when a single file runs to gigabytes, or sync the whole share to each computer, and putting multi-terabyte drives in every user’s machine isn’t practical. |
| Line-of-business apps with a SQL database behind them | Usually keep these on-site as well | These apps talk to their database constantly, and putting distance between the two tends to make them sluggish. |
| Line-of-business apps whose vendor offers a cloud-native version | A good candidate to move to the vendor’s cloud version | The vendor runs and maintains it, so it no longer needs a server of yours. |
For an app that has no database to worry about, the first call goes to the software vendor to ask whether they have a cloud-native version. Most servers we look at hold more than one of these rows, which is how a mix happens: some applications move to their vendor’s cloud and the rest stay on a smaller server in the office.
The Part People Underestimate
Owners tend to brace for the cost of licensing or the hassle of moving data. In our experience, the bigger surprise is how much effort the project takes when nothing is virtualized, and how much more risk it carries.
In a virtualized setup, each server runs as a virtual machine, a self-contained copy of a server that lives as files on a physical host server. Microsoft’s overview of Hyper-V, its own virtualization software, describes using it to consolidate servers and get more out of the hardware. When a business is already virtualized, moving to new hardware can be as simple as adding the new host to the existing setup and moving the virtual machines onto it.
When everything runs directly on physical machines, there’s an extra stage. Our approach is to convert each physical server into a virtual machine first, lifting it off its original hardware as it is, and then do any operating system rebuilds or new server setups once everything is virtual. That order makes the work much easier to manage, but the conversion is added work and added risk that a virtualized business skips.
A Recent Replacement: Four Servers Down to Two Hosts
One server project we’re in the middle of now started with four underpowered physical servers running all of a client’s applications, and there were quite a few of them. Replacing all four one for one would have meant four new machines to buy, power, and maintain.
We planned a move to a virtualized environment instead. The client bought one new server with heavy specs, and we upgraded one of their existing physical servers so it could be reused. Together, those two hosts will run about 13 virtual machines in place of the original four boxes, and each host is sized to carry the full load of all of them by itself. That setup makes better use of the hardware, and it’s generally more cost-effective and flexible over the long run, since adding a server later means adding a virtual machine rather than buying another computer.
Planning the Cutover
Every migration has some downtime. What you control is when it happens. Here’s how we plan around it:
- Schedule anything users will feel. If a step is guaranteed to interrupt people’s work, we pick the time together with the client instead of springing it on them.
- Write a back-out plan first. Before the switch, we decide how to return to the old setup if things don’t go to plan, starting with good, current backups. On a virtualized system, a checkpoint taken just before a change can be the way back. When a physical server is being converted, the back-out is usually turning the original server back on, either in person or through its remote management controller.
- Work after hours when it matters. Moves that would disrupt the business can happen in the evening or on a weekend so staff aren’t affected.
What to Gather Before You Talk to Anyone
You can answer most of the planning questions yourself, or with your IT person, before any provider is involved:
- Which version of Windows Server each server runs, and its end-of-support date on Microsoft’s lifecycle pages
- Every line-of-business application on each server, and which ones keep their data in a SQL database
- An answer from each software vendor on whether they offer a cloud-native version, and what switching would involve
- Where your biggest files, like CAD drawings, are stored, and roughly how much space they take up
- Whether your servers are physical machines or virtual machines running on a host
- The projects waiting on the replacement, and the hours or days when each system can’t go down
Once these are written down, the new hardware, cloud, or mix question usually answers itself, and the first conversation with a provider can go straight to the plan.
Where Micro Solutions Fits
Our managed IT services include server monitoring and lifecycle visibility, so support dates show up long before they become urgent. Technology planning is part of the agreement too: lifecycle planning, replacement priorities, budget conversations, a technology roadmap, and project planning. The replacement project itself, including new hardware and any after-hours project work, is scoped and priced separately.
Plan Your Server’s Next Move
If a support date is coming up or the server is holding up other work, see how our managed IT services handle lifecycle and project planning.
Frequently Asked Questions
More on Keeping Your Systems Running
These pick up where a server project leaves off.

