Data center consolidation moves infrastructure from many sites into fewer, usually to cut leases, power contracts, and the cost of staffing and securing each site. It is not one migration but several that share a destination, a deadline, and finite receiving capacity, and the interactions between them are where consolidation projects lose their schedule.
Those savings are real and they are the easiest part of the business case to defend. What the business case tends to underweight is the cost of the interactions between the migrations.
Why Is the Destination the Main Constraint?
Because it has to absorb every source site, in an order that never exceeds what it can hold at any given moment. A single-site relocation sizes the destination for one source; a consolidation has no such margin.
Model destination capacity over time rather than at completion. Power, cooling (against the ASHRAE thermal guidelines your facility designs to), space, and network capacity all need to be sufficient at every intermediate state, not merely at the end. A plan that fits perfectly when finished can exceed cooling capacity in month four, when three sites have arrived and consolidation of duplicate systems has not yet happened.
This is particularly acute where the destination is an existing production facility rather than a new build. It is already running something, and the incoming equipment competes with the existing load for the same power and cooling envelope.
Build in headroom deliberately. A destination at ninety percent of capacity on the day the project completes is a facility with no room for the growth that will arrive next year.
Which Site Should Move First?
There is no single right answer. Site order is a real decision with real consequences, and there are several defensible strategies.
Simplest first builds team experience and delivers early wins on a site where failure is survivable. It defers the hard problems, which is either prudent sequencing or accumulating risk depending on how the schedule holds.
Lease expiration order is frequently imposed rather than chosen. Where a lease end date is fixed and expensive to extend, that site's timing is not negotiable and everything else arranges around it.
Dependency order moves tightly coupled systems together regardless of which sites they live in. This is the technically correct approach and the one that most often conflicts with the others.
Highest cost first captures savings earliest, which matters when the business case is being tracked quarterly.
Most real programs blend these under a constraint set where lease dates dominate. Make the tradeoffs explicit rather than letting them emerge — the site that gets deferred repeatedly is usually the difficult one, and deferring it does not make it easier.
Duplicate Systems and the Consolidation Inside the Consolidation
Multiple sites accumulate multiple versions of the same thing: several directory services, several monitoring platforms, several storage platforms, several ticketing tools, each with its own owners and its own history.
The consolidation project has to decide whether to rationalize these or simply relocate them all. Rationalizing is where much of the actual value lives and it is your IT team's application work, not logistics work — different skills, different timeline, different risk profile.
Deciding this early matters because it changes the migration. Systems being rationalized may not need to move at all; their data needs to migrate into a surviving platform, which is a different project. Systems being relocated as-is move on the normal path.
The failure mode is deferring the decision. Everything moves, the duplicates arrive at the destination, and the rationalization that justified the business case never happens because the project closed when the last truck arrived.
Why Is the Network the Underestimated Piece?
Consolidation collapses traffic that used to be local into traffic that crosses a wide area network.
Users at former site locations now reach applications remotely. Site-to-site replication that ran on a local network now runs on circuits. Bulk data copies that stayed inside a building now traverse a link that has to be sized for it.
Model this before the first move. Application performance for remote users is the most common post-consolidation complaint, and it is entirely predictable from the design — latency that was under a millisecond becomes tens of milliseconds, and applications that were never designed for that behave badly.
Where remote sites remain occupied after their infrastructure leaves, those sites need circuits sized for their new dependence on the central facility, and they need them before their equipment departs rather than after.
Running It as a Program
Consolidation runs long enough that staff turn over, priorities shift, and the organization changes around it. That duration is a management problem as much as a technical one.
Run it as a program with repeatable waves rather than as a series of independent projects. The value of the second site is the lessons from the first, and that value is only captured if the process is documented and carried forward — a runbook that gets refined each wave, an inventory format that stays consistent (the CIS asset inventory control is a useful baseline), a validation checklist that grows.
Track the business case throughout. Facility costs that were supposed to disappear only disappear when leases actually terminate and equipment actually leaves, and a site that is ninety percent empty still costs what it costs. The last ten percent of a site — the stragglers nobody will let you move — is where consolidation savings quietly go to die.