Multi-Site Infrastructure Review & Consolidation Planning

The Situation

A mid-size holding company, multiple acquired entities, each with its own IT stack, needed to replace a failing server at one of its locations. The hardware was aging, had recent outages, and was a single point of failure for an office of 26 workstations running tax preparation and e-filing software.

Simple enough on the surface: buy a new server, migrate the VMs, move on. But the reality was more complicated. This client’s infrastructure was fragmented across three hosting environments, on-prem hardware at one site, hosted VMs in our datacenter for two other entities, and Azure VMs for a legacy application being sunset. Nobody had a single document that showed the full picture.

Without that picture, the server replacement question couldn’t be answered properly. Was it smarter to replace the hardware in place? Consolidate everything onto a single new server at one location? Move workloads to the cloud? The answer depended on understanding what actually existed, what it cost, and what depended on what.

The Approach

I built the infrastructure summary from scratch, pulling data from our RMM tools, cloud consoles, and engineering team knowledge into a structured document that the client’s COO could actually read and use.

What the Document Covers

Infrastructure at a Glance, a single table showing every hosting environment, VM count, and monthly cost. Three rows that tell the whole story before you read another word.

Per-Environment Breakdown, every VM listed with its role, resources, OS version, current state, and intended disposition. Not just what exists, but what should be kept, shut off, or deleted.

Per-Entity Summary, which acquired company uses which infrastructure, where their users connect from, and what they depend on. Critical for understanding the blast radius of any change.

Infrastructure Diagram, a Mermaid diagram showing the relationships between environments, VMs, and user populations. One picture that makes the fragmentation visible.

Risks & Issues, every known problem cataloged: aging hardware, end-of-life operating systems, unbilled VMs consuming resources, memory pressure on overloaded servers.

Key Decisions, the core of the document. Each decision framed as options with pros, cons, cost estimates, and downstream dependencies. Not a recommendation disguised as analysis, genuine options that the client and engineering team could evaluate together.

Monthly Cost Summary, what the client is actually paying for infrastructure today, and what it looks like if specific decisions are made.

The Decisions We Framed

The primary question, replace the server or consolidate, turned out to have three viable paths:

1. Replace in place, simple, fast, low risk, but doesn’t address the fragmentation problem
2. Full consolidation, eliminates hosting fees and creates a single management point, but requires an internet upgrade, complex migration, and concentrates risk
3. Replace now, consolidate later, gets the failing hardware stable immediately while buying time to plan the consolidation properly

Each option came with specific cost estimates, prerequisites (like verifying fiber internet availability before committing to consolidation), and dependency chains (which VMs could move, which couldn’t, and why).

The document also surfaced a secondary decision about legacy SQL servers running end-of-life software for acquired entities. Those servers each required their own domain controller and jumpboxes, a chain of dependencies that multiplied the VM footprint. We framed three options: consolidate the workloads onto new hardware, keep them isolated indefinitely (with a 3-year cost projection), or pay the software vendor to extract the data into an archive format and decommission everything.

What Made This Work

The document was a concise bridge between the technical and the business. It wasn’t just a list of machines, for every server and VM, we made sure three things were clear:

• What runs on it, the actual applications and services, not just the OS and specs
• What depends on it, which users, which other systems, which business processes break if it goes down
• What its future is, some machines could be planned for retirement by the business, while others needed to remain for the long term. Making that distinction explicit meant the COO could participate in the decision instead of deferring to engineers

That clarity is what turned a technical inventory into a decision-making tool. Our engineering team reviewed the document with the client COO, and instead of a meeting where an engineer explains infrastructure while an executive tries to follow along, everyone was looking at the same reference and discussing the options it framed.

The whole thing, creation and review, took half a day.

The Meta-Point

This is a pattern I keep coming back to: the hardest part of IT operations isn’t the technology, it’s the clarity. Most infrastructure decisions are hard not because the options are technically complex, but because nobody has assembled the information needed to evaluate them in one place.

A half-day documentation effort prevented a potentially expensive consolidation mistake (the internet at the target site couldn’t support the load), surfaced 10 unbilled VMs consuming resources for no reason, and gave the client a reference document they can use for future planning, not just this one decision.