A migration spreadsheet can show a workload leaving the cloud, arriving at a private facility, and reducing infrastructure costs within a planned quarter. The calculation becomes less convincing when the destination rack supports only 12 kW, while the workload design assumes 20 kW of continuous capacity. That shortfall affects more than server placement because it changes the number of racks required, the power available to each deployment, and the schedule for bringing workloads into service. A facility may have enough aggregate electrical capacity on paper while its distribution paths, cooling arrangements, maintenance procedures, and physical layout prevent the intended configuration from operating. Repatriation planning therefore needs evidence about the building’s actual operating limits rather than an assumption that purchased space can accommodate the target architecture. The financial case remains incomplete until engineering verification establishes what the site can install, energize, maintain, and recover under the conditions the workload will encounter.

Your Rack Fits the Drawing. It Doesn’t Fit the Service Aisle

A rack layout can satisfy the dimensions on a drawing and still fail when technicians attempt to install, operate, or service the equipment. The equipment footprint captures only one part of the physical requirement, while cable bend radii, overhead tray congestion, door movement, and working clearances consume space around the cabinet. A higher-density rack can also require different cable routes, heavier power connections, and cooling infrastructure that the original room arrangement never accommodated. When those requirements collide, installers may struggle to open equipment doors fully, remove components safely, or access isolation points without moving neighboring hardware. Containment creates another constraint because rack placement must preserve the intended airflow path rather than merely fill the available floor area. A site that appears to accommodate a full row on paper may therefore support fewer operationally usable racks once engineers account for installation, maintenance, and airflow requirements.

The financial impact can begin when the original rack count no longer reflects the capacity the site can actually deliver. A workload planned for 20 kW racks but placed in a zone limited to 12 kW per rack may require additional rack positions, electrical or cooling upgrades, or workload redesign, depending on available capacity and the feasibility of those changes. The workload would require more rack positions to distribute its demand, assuming the hardware, network topology, and application architecture permit that distribution. However, additional cabinets also consume floor space, increase cable and power-distribution requirements, and may introduce more network hops or operational dependencies. A simple capacity ratio suggests that 20 kW divided by 12 kW equals approximately 1.67 rack-equivalents, but that calculation does not establish whether the workload can actually operate across that arrangement.

Your Cloud Assumes Workload Flexibility. Your Building May Require a Shutdown.

Cloud operating models often treat hardware replacement as a routine intervention within a larger pool of distributed capacity. Engineers can sometimes drain a host, shift workloads, replace a component, and return the machine to service without interrupting the application. A private facility may impose a different sequence because technicians must isolate electrical circuits, verify safe working conditions, coordinate cooling-system interventions, and obtain authorization before touching shared infrastructure. The actual procedure depends on the installed topology, equipment instructions, safety requirements, and the site’s approved operating procedures. If a maintenance task requires the team to remove a shared distribution component from service, the available redundancy may determine whether the affected workload can remain online. Consequently, a migration plan that assumes unrestricted hardware replacement can promise a service model the building cannot sustain.

Maintenance restrictions also change the schedule that finance and application teams should use when evaluating repatriation. A planned server replacement may require advance coordination, a workload drain, a maintenance window, post-work testing, and a controlled return to normal operation. Each step consumes time, and dependencies between facilities personnel, network teams, hardware vendors, and application owners can extend the intervention beyond the physical repair itself. Moreover, a procedure that works during normal operation may require additional steps when a redundant power path is already unavailable or a cooling component needs maintenance. These conditions can turn an apparently routine upgrade into a scheduled service event that delays a migration milestone or hardware refresh. The project plan should therefore model maintenance windows, approval lead times, staffing availability, and recovery validation rather than assigning every intervention a generic repair duration.

The Failure You Planned For Is Not the Failure the Building Will Give You

A rack’s rated capacity says little about how the facility will behave when an upstream component fails or maintenance removes a distribution path. The engineering question is whether the remaining infrastructure can support the connected load under the specific operating condition that follows the fault. A redundant power path may exist, yet its usable capacity may fall below the workload’s requirement when the system transfers to an alternate source. Cooling distribution presents a similar challenge because a failed pump, unavailable heat exchanger, or isolated pipe section can limit heat removal even when the room’s nominal cooling capacity appears adequate. The location of isolation valves, circuit breakers, transfer equipment, and control dependencies determines which assets lose service during an intervention. These relationships define the facility’s practical failure boundaries, and engineers need to map them against the workloads that depend on each boundary.

Recovery assumptions deserve the same scrutiny as normal operating capacity because workloads do not respond identically to interruptions. A stateless service may restart on another host, while a distributed training job can lose progress or require coordinated recovery across multiple nodes. Applications that depend on local storage, tightly coupled accelerators, or synchronized network operations may not recover simply because spare compute capacity exists elsewhere. The facility assessment must establish which failures trigger automatic transfer, which require human intervention, and which demand a workload restart or restoration from a checkpoint. Testing should also verify that monitoring identifies the failure, operators can locate the affected infrastructure, and the recovery sequence restores service within the workload’s actual tolerance. These findings belong in the repatriation business case because recovery engineering can require additional hardware, different workload placement, more staffing, or a revised service-level commitment.

Your Scheduler Thinks Density Is Available. Your Floor Zones Say Otherwise

A scheduler can identify available processors, memory, storage, and network capacity without understanding whether the destination facility can support the required physical arrangement. Its placement decision may look valid while the target rack sits in a zone with insufficient power headroom, restricted cooling capability, or no practical route for additional distribution equipment. Structural bays, ceiling heights, floor loading, containment boundaries, and maintenance access can narrow the set of locations suitable for a particular hardware configuration. Those constraints matter when a workload depends on nearby accelerators, low-latency networking, or a specific arrangement of interconnected racks. Spreading the deployment across more distant zones may satisfy an aggregate capacity calculation but change network performance, cable requirements, and the failure domains that the application experiences. The site needs a verified map of deployable capacity at rack and zone level, not simply a total number of kilowatts remaining in the building.

MEP verification should translate those physical and electrical limits into information that infrastructure planners can use before they commit to a migration date. The verified model should identify each zone’s usable power, cooling capability, rack positions, distribution dependencies, access restrictions, and approved operating configurations. Engineers should reconcile that model with as-built drawings, equipment schedules, commissioning records, and current measurements rather than assuming the original design still describes operating conditions. The resulting capacity map can then inform workload placement rules, rack reservations, upgrade sequencing, and the amount of spare capacity the site must retain. A scheduler does not need to control every building system, but it does need accurate constraints that prevent it from treating unavailable or incompatible capacity as deployable. Maintaining that connection between engineering verification and orchestration reduces the risk of approving a migration that the physical site cannot execute.

Repatriation Is Not a Move, It’s a Taxonomy Test

The decision to repatriate workloads should rest on the building’s ability to support their complete operating lifecycle, not the number of cabinets a floor plan can accommodate. A credible assessment connects workload requirements to physical access, electrical distribution, heat rejection, maintenance procedures, failure behavior, and recovery capability. Each requirement needs a defined limit, a responsible owner, and evidence that the facility can meet it under the intended operating conditions. Where the site falls short, the investment case should identify the necessary upgrade, the associated cost, the implementation lead time, and any residual operating constraint. Where the facility already meets the requirement, verification provides a defensible basis for workload placement and migration scheduling. This approach makes facility taxonomy a practical investment tool that connects engineering capability with the commercial commitments attached to repatriation.

A useful pre-investment review should leave decision-makers with more than a rack count and an estimate of available megawatts. It should establish which workloads the site can host today, which require infrastructure changes, and which cannot meet their service requirements within the proposed schedule. The review should also define how operators will keep that assessment current as equipment changes, electrical loads increase, cooling configurations evolve, and maintenance requirements shift. This ongoing process matters because a site that supports one hardware generation may not support its replacement at the same rack density or under the same operating assumptions. Treating verification as a continuing operational responsibility gives finance, facilities, and technology teams a shared basis for evaluating capacity and migration risk.