An AI infrastructure contract can appear portable while the physical deployment tells a different story. A customer may control its models, data, and compute hardware. Yet that hardware may depend on cooling conditions that another site cannot immediately provide. Dense AI systems make this dependency harder to ignore. Liquid-cooled racks can include cold plates, tubing, quick disconnects, manifolds, coolant distribution units, and secondary cooling loops. Facility water systems and heat-rejection equipment can sit farther along the same thermal path. Each interface creates requirements that a destination must understand before accepting the equipment. Physical portability can therefore differ sharply from the contractual right to move.

That distinction changes how customers should approach exit planning. Moving workloads may require data transfer, network changes, storage replication, and replacement capacity. Moving the underlying hardware introduces another set of constraints. The destination must provide the thermal conditions that the equipment requires for operation. Cooling design does not automatically prevent a migration. It can, however, add engineering work beyond moving workloads and conventional IT equipment. Customers need to know which requirements travel with their hardware. That knowledge can determine whether an exit takes the expected path or requires additional infrastructure preparation.

The Exit Problem Starts Below the Software Layer

Traditional migration planning tends to focus on the logical layers of infrastructure. Teams examine data movement, application dependencies, network connectivity, storage, security, and replacement compute. Liquid-cooled AI equipment adds a physical operating dependency to that list. Servers cannot operate without a thermal system capable of removing their heat within specified conditions. Open Compute Project documentation illustrates how extensive that system can become. A cold-plate cooling chain can include IT equipment, tubing, quick disconnects, manifolds, secondary loops, and a CDU. It can also connect to facility water and heat-rejection systems. A relocation plan must account for the relevant parts of that chain.

Available rack space alone does not establish that a destination can host the equipment. Electrical capacity alone does not settle the question either. The destination may need compatible coolant conditions, connections, flow characteristics, materials, monitoring, and heat rejection. Requirements can vary between hardware platforms and cooling implementations. A facility that supports one liquid-cooled configuration may not automatically support another. Engineering teams must compare actual operating requirements with the receiving site’s design. That comparison turns thermal compatibility into part of migration planning. Discovering a mismatch early gives the customer more options than discovering it during relocation.

Rack-Scale AI Makes Cooling Part of the System

Rack-scale AI platforms show why this distinction matters. NVIDIA describes the GB200 NVL72 as a liquid-cooled rack-scale system. Its design connects 36 Grace CPUs and 72 Blackwell GPUs through the NVLink architecture. NVIDIA documentation also shows how cooling enters the rack itself. A DGX Grace Blackwell rack includes compute trays, NVLink switch trays, power shelves, a bus bar, and liquid-cooling manifolds. The rear of the rack provides access to liquid manifold inlets and outlets. Cooling therefore reaches directly into the equipment architecture. It is not simply a room-level service surrounding otherwise independent servers. That integration changes what teams must evaluate before relocating the system.

A receiving facility needs more than enough physical space for those racks. It must support the documented installation and operating requirements of the equipment. Mechanical preparation may sit alongside electrical and network preparation. Commissioning work can also become part of the relocation schedule. Customers should not assume that physical removal represents the difficult part of the move. The receiving environment may require more preparation than the hardware itself. Migration planning becomes a coordinated infrastructure exercise under these conditions. Cooling engineers, facility teams, hardware specialists, and customer operations staff may all have roles. The exit timeline needs to reflect those dependencies before equipment leaves its original site.

Cooling Compatibility Can Become a Portability Constraint

Liquid cooling does not describe one universally interchangeable architecture. Cooling environments can use cold plates, CDUs, immersion systems, door heat exchangers, and other approaches. Direct liquid cooling also contains important variations within the category. Designs can differ in coolant chemistry, temperatures, pressures, flow requirements, materials, connections, and controls. Facility integration can differ as well. OCP work addresses interfaces across cold plates, tubing, manifolds, quick disconnects, and CDUs. Those interfaces matter because hardware and facility infrastructure must work together within defined conditions. A generic claim that a site “supports liquid cooling” does not prove compatibility with a specific system. Customers need the technical detail behind that description.

Compatibility analysis should compare the destination with the equipment’s actual operating envelope. Engineers may need to examine coolant conditions, connection requirements, flow limits, materials, and distribution arrangements. Differences do not necessarily make relocation impossible. They can require engineering review or changes at the receiving facility. Those changes can affect the order in which migration work occurs. They can also alter commissioning requirements before workloads return to production. Moreover, compatibility needs to remain specific to the equipment being moved. A facility’s support for liquid cooling in general offers only part of the answer. The more useful question is whether it supports the customer’s exact deployment requirements.

The CDU Creates an Important Infrastructure Boundary

The coolant distribution unit creates a significant boundary within many liquid-cooling systems. A CDU can sit between facility infrastructure and the technology cooling system. OCP requirements describe units that may contain pumps, heat exchangers, reservoirs, valves, controls, monitoring, and sensors. Those sensors can track variables such as temperature and flow. The architecture can separate the technology cooling system from the facility water system. This separation creates an important consideration during migration. Customers need to know which components belong to their deployment. They also need to know which components remain part of the host facility.

Ownership and responsibility can affect what the customer must recreate at another site. A compute rack may leave while parts of its supporting thermal infrastructure remain behind. The receiving site then needs equivalent functionality that meets the equipment’s requirements. Technical demarcation can also shape testing responsibilities during recommissioning. Documentation becomes valuable at this point. It should describe relevant facility-side and technology-side cooling conditions. CDU arrangements and rack distribution details can also support destination planning. Without this information, a customer may know where its servers are moving without knowing how the new site will cool them. That uncertainty can turn a planned relocation into an engineering investigation.

Standardization Matters Because AI Hardware Keeps Changing

Data center infrastructure and compute hardware do not always change on the same schedule. Facilities can operate across several generations of IT equipment. Uptime Institute noted in September 2026 that sites may experience overlapping hardware technology cycles from different vendors. That pattern creates a challenge for liquid-cooling infrastructure. Facility systems need enough flexibility to accommodate changing IT requirements where the design allows it. A customer moving equipment may encounter a destination built around another hardware generation or supplier. Direct liquid-cooling capability alone does not establish compatibility. Engineers still need to verify the requirements of the incoming rack configuration. Standard interfaces can reduce unnecessary differences, but they cannot eliminate system-level validation.

Coolant chemistry adds another dimension to that validation. Wetted materials must remain compatible with the liquid used inside the cooling system. Flow, temperature, pressure, filtration, and connection requirements also remain relevant. However, customers do not need to treat every difference as an automatic barrier to migration. The important task is to document the differences and determine what the receiving environment must provide. Detailed interface records make that work more manageable. They allow teams to compare technical requirements instead of relying on broad cooling labels. Procurement teams can use the same information while assessing alternative capacity. Portability becomes easier to evaluate when the infrastructure requirements are known before a move begins.

Quick Disconnects Help Serviceability, Not Automatic Portability

Quick disconnects illustrate the difference between serviceability and portability. OCP guidance describes them as components that allow cooling-fluid tubing and cold plates to disconnect for servicing. That capability can simplify maintenance and certain removal procedures. It does not make the equipment independent of its cooling environment. Hardware disconnected from one loop still needs a suitable cooling system at its destination. The new environment must provide appropriate thermal conditions and compatible fluid infrastructure. Connections and heat-removal capability must also meet the equipment’s requirements. A quick disconnect solves a connection and serviceability problem. It does not solve every facility compatibility question.

Fluid condition and material compatibility may also require attention when equipment changes environments. Engineering teams need to understand the conditions expected by the cooling system. Well-maintained interface documentation can make those checks more predictable. It gives teams a defined set of parameters to validate before commissioning. Customers should therefore avoid treating serviceable cooling hardware as proof of unrestricted mobility. A rack can be straightforward to disconnect yet still require careful preparation elsewhere. This distinction matters when businesses estimate an exit schedule. Removal time represents only one portion of the process. The larger question is how quickly the equipment can safely return to operation at its destination.

Cooling Capacity at the Destination Must Match the Workload

Finding vacant floor space does not prove that a destination can support a departing AI cluster. The site also needs suitable electrical, network, structural, and cooling capability. Cooling requirements can influence how much equipment a particular configuration can support. Intel’s liquid-cooled rack guidance links system configuration with variables such as coolant flow and ambient conditions. Component heat production also affects the cooling requirements of a rack. Rack-scale GPU systems make these checks especially important. Their thermal architecture can form an integral part of the installed system. The destination must therefore support the specific configuration that the customer intends to operate. Generic capacity figures cannot answer every deployment question.

Facility preparation may extend beyond the data hall itself. A destination could need suitable CDU capacity, distribution infrastructure, piping, monitoring, or facility-side heat rejection. The exact requirements depend on the selected architecture. Therefore, nominal data hall availability should not equal deployment-ready liquid-cooled capacity in planning assumptions. Customers need engineering confirmation before treating a site as ready for migration. That confirmation should address the requirements of the actual equipment. It should also identify any facility work needed before installation. A mismatch does not mean the destination can never support the cluster. It means the migration schedule must include the work required to make the destination suitable.

Migration Has a Thermal Commissioning Phase

Physical relocation does not end when technicians place the racks in their new positions. The cooling system must operate within the conditions required by the equipment. OCP documentation addresses temperature, pressure, flow, fluid selection, filtration, material compatibility, and monitoring. Those parameters provide useful categories for engineering verification. Connections also deserve inspection because liquid travels close to electronic components. OCP cold-plate guidance identifies leak detection as a highly recommended capability. Quick disconnects support servicing, but teams still need to verify the cooling path after installation. Thermal commissioning therefore sits alongside electrical and network validation. Production workloads should return only after the relevant operating conditions have been established.

Commissioning can introduce coordination requirements that do not appear in a simple shipping schedule. The destination operator may need to work with cooling specialists and hardware teams. Customer operations staff may also need to participate before workloads resume. In addition, the team may need to validate monitoring and operating parameters across the installed cooling path. These activities do not mean every migration will face a lengthy delay. They do mean that relocation planning should account for thermal readiness. A schedule based only on packing, transportation, rack placement, and cabling can miss this work. Customers need a migration plan that extends through operational readiness. Exit speed ultimately depends on how quickly the destination can support safe production operation.

Cooling Ownership Should Appear in Exit Planning

Infrastructure agreements can assign responsibilities for servers, networking, storage, customer data, and facility systems in different ways. Liquid-cooled deployments add thermal infrastructure to that responsibility map. Customers need clarity about which party controls each relevant part of the cooling chain. The customer may control compute hardware while the operator controls facility water infrastructure. Distribution equipment or parts of the CDU arrangement may sit under another responsibility boundary. Deployments can structure those relationships differently. A universal assumption about ownership would therefore create unnecessary risk. Exit planning should identify the physical demarcation before relocation becomes necessary. That boundary helps teams understand what leaves and what must exist at the next site.

Documentation access matters alongside ownership. Customers may need equipment requirements, coolant information, interface specifications, and operating parameters. Maintenance records or commissioning information can also prove useful where applicable. These records allow the destination team to evaluate what the incoming hardware requires. They can also expose missing information before the migration window opens. Contracts can address access to relevant technical documentation without dictating every engineering decision. The objective is not to move every cooling component with the servers. It is to understand which functions must be recreated, replaced, or supplied elsewhere. Clear boundaries make that question easier to answer.

Exit Readiness Should Be Tested Before the Exit

The safest time to identify a thermal dependency is while the current deployment remains stable. Customers can maintain an interface record for the compute environment. That record can describe cooling architecture, connection requirements, coolant parameters, and facility-side dependencies. It can also include specified temperature and flow limits where relevant. Procurement teams can use this information when assessing alternative sites. Engineers can compare the record against a destination design before migration begins. That process helps distinguish hardware requirements from choices made at the existing facility. It also reduces reliance on broad descriptions such as “liquid-ready.”

Standardization may make these comparisons easier as specifications mature. Cold plates, fluids, CDUs, manifolds, and facility interfaces all remain active areas of technical development. Customers should still validate each deployment against its actual equipment documentation. A broad compatibility label cannot replace that review. Exit testing can also expose missing records or unclear responsibility boundaries. Teams may discover assumptions that remained invisible during normal operations. Finding those gaps early creates time to resolve them without an active relocation deadline. Physical portability becomes more credible when the customer can describe what the hardware requires at another site.

Cooling Architecture Is Becoming Part of Commercial Portability

AI infrastructure buyers deploying liquid-cooled systems need to evaluate portability beyond software and contractual terms. Physical operating requirements matter because liquid distribution can extend directly into racks and processor cooling assemblies. The U.S. Department of Energy describes direct liquid cooling as moving heat from IT equipment into a recirculating liquid loop. In one representative architecture, a CDU transfers heat onward toward the facility-side system. OCP work covers technical areas that sit within this broader path. These include cold plates, cooling fluids, CDUs, and facility integration. None of those components makes customer exit inherently difficult. Problems arise when required interfaces or operating conditions remain unclear until relocation begins.

A customer can reduce that uncertainty before signing or renewing infrastructure arrangements. Technical teams can document cooling requirements alongside electrical, network, and space requirements. Procurement teams can ask prospective destinations whether those conditions can be supported. Operations teams can maintain records as hardware and cooling configurations change. Contract teams can clarify access, ownership, and responsibility around infrastructure needed during an exit. These actions do not guarantee that every destination will accept every rack without modification. They create a clearer basis for judging what a move would require. Migration rights carry greater practical value when the destination can meet the hardware’s physical operating conditions. For high-density AI deployments, thermal preparation can become a material part of how quickly equipment returns to service after an exit.