Data center IT equipment rack-and-stack deployment and migration field guide

What rack-and-stack is

Rack-and-stack is the physical deployment of IT equipment into racks: bolting servers, storage, and network gear into the rails, wiring the power, patching and labeling the cabling, and bringing it all up. It happens after the facility is built, which is why the gear goes in last. The power, the cooling, and the structured cabling have to be live before a single server lands.

Going in last does not make it low-stakes. A sloppy deployment haunts the room for its whole life. The elevation that put heavy storage at the top, the A and B cords that both land on one strip, the cabling nobody labeled, the empty U with no blanking panel: none of it fails on day one. It fails the day someone has to service the rack, balance a circuit, or trace a cable under load, and by then the cabinet is full, live, and owned by operations.

Do it right and the room stays serviceable for a decade. Plan the U-space and the weight, wire redundant power that is actually redundant, patch and label to a standard, mind the airflow, and run every migration off a tested runbook. The cabinet-types guide covers choosing the frame, and the rack-readiness guide covers getting the facility and the empty cabinet ready. This guide is the IT-equipment install that happens once both are done.

Rack-and-stack, defined: the IT side, not the facility

Rack-and-stack is the IT side of the build, not the facility side. The line matters because two different crews, two different scopes, and two different sign-offs sit on either side of it. The facility scope delivers the room: the power path, the cooling, the raised floor, the empty cabinets placed and bonded, and the structured cabling pulled to the rack. The rack-and-stack scope takes that ready room and loads it with live equipment.

People blur the two and then argue about who owns a defect. A missing bond is a facility item. A server racked over its weight limit is an install item. Keep the scopes clean and the hand-off has a defined edge: the facility crew turns over a ready cabinet, the deployment crew loads it, and each owns its own punch list. The rack-readiness guide is the gate that closes the facility scope. Everything past that gate is this guide.

Why the facility has to be ready first

The gear goes in last because everything it depends on has to exist first. A server needs a powered, breaker-traced receptacle or busway tap on both its A and B sides, conditioned air moving front to back, a bonded cabinet, and a tested patch field to land its uplinks. None of that is the deployment crew's to build. It is the readiness gate the facility side signs before load-in starts.

Load gear into a cabinet that is not ready and you inherit problems you did not make. An unbonded rack under live equipment is a shock and ESD hazard. An unsealed floor cutout leaks the cold air the gear needs. A receptacle that was never traced means nobody knows which breaker drops the rack. The rack-readiness and floor-load guide covers that gate in detail: placement, leveling, anchoring, power, bonding, and containment on the empty cabinet. Confirm it is signed before you bolt anything in.

Receiving and staging the gear

Receive and stage the equipment before it goes anywhere near the data hall. Inspect every box on arrival for shipping damage, check the packing list against the purchase order, and record the make, model, and serial of each unit. Damaged gear gets flagged before it is installed, not after it fails the burn-in, because a freight claim is easy on day one and impossible once the unit is racked and powered.

Stage in a dedicated area, not in the hot aisle. Unboxing in the aisle dumps cardboard and foam into the airflow, blocks the row for the crew working it, and leaves packing debris that gets pulled into intakes. A real staging area gives you room to unbox, inventory, asset-tag, and pre-configure where the work allows, so the gear that travels to the cabinet is clean, logged, and ready to mount. Some shops pre-rack and pre-cable whole cabinets off-site and roll the finished cabinet in, which is the stacking half of rack-and-stack.

Asset tagging and the DCIM record

Asset tag and record every unit as it is staged: the asset ID, the serial, the make and model, the rack and U position it will occupy, and the owner. Scan the serials rather than hand-typing them, because a transposed digit is a warranty claim that does not match and an audit that never reconciles. The tag on the steel and the row in the database have to agree.

That record lives in the DCIM or CMDB, keyed to the rack coordinate the readiness gate assigned. Capture it in a field tool like FieldOS as you tag, so the asset, its location, and its photos are logged at the point of install instead of reconstructed from memory weeks later. A cabinet loaded with untagged gear is a cabinet nobody can audit, and the first move-add-change starts with a flashlight and a guess.

How do you plan the rack elevation?

The rack elevation is the U-by-U map of what goes where in the cabinet, drawn before anything is mounted. Plan it and you control three things at once: the weight, the airflow, and the cable runs. The rule that does not change is heavy at the bottom. UPS modules, large storage shelves, and big chassis go low to keep the center of gravity down and the cabinet planted; lighter gear goes up top.

Past that, the layout follows the work. Patch panels and frequently serviced gear sit at a workable height, switches go where the uplink topology wants them, and you leave U for growth instead of packing the cabinet solid. The specifics are a design call: the elevation should follow the project drawings, the equipment manufacturer's mounting and clearance requirements, and the airflow plan, not shop habit.

A cabinet loaded without an elevation plan ends up top-heavy, cable-tangled, or thermally uneven, and you find out when it is already full. Draw it first, confirm the heavy gear lands low, and check the planned weight against the rack and the floor before the first unit goes up.

Rack weight and floor load

A loaded cabinet is heavy enough that how you fill it is a structural question, not just a stability one. Concentrate the mass and you can exceed what an access-floor panel takes, especially the rolling load while the cabinet moves on its casters. Keep the weight low and balanced front to back so the frame does not rack and the doors still latch.

The floor side of this belongs to the rack-readiness and floor-load guide, which covers the static, rolling, and concentrated ratings and how to verify them. The install side is simpler to state and easy to skip: do not load a cabinet past its rated capacity, do not roll a fully loaded cabinet across a floor that was rated for the empty one, and rack the heaviest gear after the cabinet is in position and on its feet where the plan allows. The number that bites is the rolling load, and it cracks the panel during the install, not in service.

Mounting the gear: rails, cage nuts, and the lift

Mount each device on its rail kit, not on its front ears alone. A server carried only by the four front screws hangs all its weight and the long cantilever of its depth on the front rail, which sags the gear and strips the holes over time. The rail kit lands the load front and rear the way the cabinet is built to take it. Match the rail kit to the cabinet's rails, square-hole with cage nuts for modern tool-less kits, and adjust the rail depth to the actual device before it goes up.

Cage nuts snap into the square holes and accept the screw. Seat them fully or they spin and chew. Heavy gear is a two-person lift, or a lift tool, every time. One person muscling a 60 lb chassis onto rails at head height is how gear gets dropped, rails get bent, and backs get hurt. Slide the unit in level, confirm it seats on both rails, then secure it. Do not slam a server home and trust the rails caught.

What is dual-cord A/B power?

Dual-cord A/B power means each piece of equipment plugs one power cord into the A feed and one into the B feed, so it keeps running if either feed drops. The two feeds have to trace back to genuinely separate sources: separate PDUs, separate upstream panels or UPS, ideally separate paths all the way up. That is the whole point of dual-corded gear, and it is the thing most often gotten wrong.

The classic mistake is plugging both cords into the same rack PDU, or into two PDUs that land on the same upstream breaker. It looks redundant at the cabinet and is one feed wearing two plugs. Lose that breaker and the gear goes dark with both cords still connected.

Route the A cords down one side of the cabinet and the B cords down the other, land them on PDUs fed from separate sources, and confirm the separation upstream rather than assuming it. Single-corded gear that has to stay up goes on a transfer switch so it still sees both feeds. The redundancy topology is the design's to set, so build the feeds to the power schedule, not to whatever outlet is closest.

The rack PDU

The rack PDU is the strip the equipment plugs into, usually mounted vertically as a 0U unit in the rear channel so it takes no rack space. It comes in grades. A basic PDU just distributes power. A metered PDU reports current and power so you can watch the rack load. A switched PDU adds remote outlet control. Colocation and managed deployments commonly specify metered or switched so the operator can bill and watch each rack.

Size the PDU to the load and the receptacle, with enough outlets of the right type for the gear plus headroom for growth. Two PDUs per cabinet, one per side, feed the A and B cords without crossing the airflow. The exact model, outlet count, and input plug are a design and manufacturer call, so build to the rack power schedule and the PDU's own ratings rather than a remembered figure. Route the cords in the side channel so they stay out of the rear airflow and the rear door still closes.

Balancing the power load

Balance the load across the phases and across the A and B feeds as the cabinet fills, not after. Three-phase power feeds the rack, and if the single-phase loads pile onto one phase, that leg overloads while the others coast. Spread the gear across the phases and record the circuit and phase for each connection so the row stays balanced.

Leave breaker headroom on purpose. The trap in a dual-feed design is loading each feed past half its capacity. When one feed drops, the survivor has to carry everything that was on both, and a PDU already past 50 percent of its rating trips the breaker the moment it tries. So the working target on a redundant pair is to keep each feed under about half its rated load, which is the design's and the manufacturer's number to confirm, not a universal law.

Watch the inrush too. Powering a full cabinet up all at once draws a surge that can trip a breaker that handles the steady load fine, so bring the gear up in stages rather than throwing it all on at the same moment.

Structured cabling: ToR, EoR, and patching

Patch the gear into the structured cabling rather than running point-to-point links across the room. Structured cabling lands on a fixed, tested, labeled patch field, and the equipment patches to that field with short cords, so a device swap is a patch change instead of a new pull. The two common architectures decide where the switch lives. Top of rack puts a switch in each cabinet and keeps the server copper inside the rack, with fiber uplinks out. End of row puts aggregation switches at the row end and runs more copper from each cabinet to them.

Cut the patch cords to length with a little slack, not a coil of excess. A cabinet full of three-meter cords on one-meter runs is a tangle that blocks airflow and hides the labels. Copper is commonly Category 6 or 6A for the speeds and distances in play, with fiber for the higher rates and longer runs.

The cabling design controls the architecture, the media, and the lengths, and the structured cabling guide covers the termination, testing, and certification the patch field has to pass before you patch into it. Patch into a field that has been tested, not one someone promises is good.

Why label every cable to TIA-606?

Label both ends of every cable, label the ports, and keep the patch record, because the unlabeled tangle is the future pain that never goes away. TIA-606, the cabling administration standard, gives the framework: a consistent identifier scheme for cables, panels, ports, and spaces so both ends and the records agree. An identifier reads like a path, naming the building, the room, the rack, the panel, and the port, so a tech can trace a link without following the cable hand over hand.

This is where deployments are quietly won or lost. A rack cabled and patched without labels works the day it goes in and becomes a guessing game the first time something breaks under load. Label as you patch, not at the end, because a cabinet full of unlabeled cordage cannot be labeled accurately after the fact.

The exact scheme is the project's to set, so follow the cabling administration plan and TIA-606 rather than inventing a convention per cabinet. Tie the labels to the same rack coordinate the asset record and the DCIM use, so the steel, the cable, and the database all read the same name.

Cable management and airflow

Manage the cable as you go, with vertical managers in the side channels and horizontal managers at the panels, so the runs have a defined path and the slack has somewhere to live. Respect the bend radius on copper and especially on fiber. A fiber kinked tighter than its rated radius loses signal or breaks, and it fails intermittently, which is the worst kind to chase. Dress the bundles neat but not strangled.

Use hook-and-loop straps, not zip ties, on data cable. A zip tie cranked down deforms the cable and changes its performance, and it has to be cut to add or remove a run, which invites a nicked cable next to it. Velcro adjusts and reuses.

The other job cable management does is protect the airflow. Cable dumped in the rear of a cabinet dams the very air the perforated doors are pulling, traps heat against the gear, and turns the next change into untangling. Keep the bundles to the sides and out of the exhaust path. A cabinet that looks fine empty chokes the day it is loaded if the cable was never managed.

Front-to-back airflow and blanking panels

IT gear cools front to back: cool air in the front, hot exhaust out the rear. The deployment has to preserve that path. Fill every empty U on the front of the cabinet with a blanking panel, or hot exhaust loops through the open space back to the front and into the intake of the gear above and below. That recirculation shows up as inlet temperatures higher than the supply air should ever produce, and blanking panels are the cheapest fix in the building.

Mount gear so its airflow matches the cabinet, intakes to the cold side. A switch that pulls side to side, or one installed backwards, dumps its heat where the next device breathes. Do not block the intakes with cable or doors that do not match the perforation.

The containment that ties the cabinet into the hot or cold aisle is a facility and readiness item, covered in the rack-readiness guide. The install job is to not defeat it. A contained aisle with open U and blocked intakes is theater, because the air finds the gaps and the hot and cold mix right where you cannot see them.

Bonding and grounding the gear

Bond the rack and the equipment to the data hall's grounding system. The cabinet ties to the common bonding network with its own dedicated conductor, and gear that ships with a bonding point gets bonded to the rack's bonding bar so the whole assembly sits at one potential. That gives fault current a low-impedance path back, holds the cabinet and its contents at the same reference, and gives the IT equipment the clean ground and ESD path it needs.

The bond has to bite bare metal. Paint and anodizing are insulators, so the connection uses a paint-piercing washer or a cleaned contact area at the stud. A cabinet that looks grounded through its painted frame is not grounded.

The cabinet bonding itself is largely a readiness item the facility side lands before load-in, governed by ANSI/TIA-607 for the telecom bonding and the NEC, NFPA 70, for the power side. The deployment crew confirms it is there and bonds the gear that calls for it. Follow the project's bonding detail and the equipment instructions rather than improvising a ground in the field.

Power-on, burn-in, and the soak

Bring the gear up in a sequence, not all at once. Power the cabinet PDUs and confirm both feeds before energizing equipment, then bring devices up in order so the inrush does not trip a breaker and so a dependency comes up before the thing that needs it. Watch each unit through POST, confirm it sees both power supplies, and update firmware and BIOS to the deployment baseline before the gear carries any workload.

Burn the gear in before you hand it over. A burn-in, or soak, runs the equipment under load for a set period to force the early failures out while a swap is still easy, because hardware that is going to fail tends to fail early. Storage gets its drives checked, memory gets exercised, and the unit runs hot long enough to surface a marginal supply or a bad DIMM.

A server that passes a real soak is one you can hand to operations with confidence. One that was racked, pinged once, and called done is a future outage waiting for its first hot afternoon. The soak length and the test suite follow the deployment standard and the equipment owner's policy, so run the soak the project calls for, not the shortest one that fits the schedule.

The handoff to operations

The handoff is the moment the deployment crew turns the live, burned-in equipment over to the team that runs it, and it lives or dies on the record. Operations inherits the as-built: the final rack elevation, the asset records, the power assignments with circuit and phase, the cabling and patch records, the labels, and the firmware baseline. If those match the steel, the room is supportable. If they do not, every future change starts with rediscovery.

Capture the as-built in the DCIM and a field tool like FieldOS at the point of install, not from memory at the end. The handoff package is the same record operations uses to run the room and the same one that proves the deployment was done to spec. Treat it like a commissioning hold point: an open punch item against a rack means the rack is not handed over. The as-built is the deliverable, not an afterthought once the gear is humming.

What is a migration: lift-and-shift vs phased?

A migration moves a workload from where it runs now to where it will run, and the two broad strategies are lift-and-shift and phased. Lift-and-shift, sometimes called a big-bang cutover, moves everything in one planned event: you take the downtime, move or replicate the workload, validate, and switch over. It is faster and simpler when the environment is contained and the business can take the window.

A phased migration moves the workload in waves, a group of systems or services at a time. It runs longer and costs more in coordination, but it shrinks the downtime per wave, lets you learn from each move before the next, and gives a faster path back if a wave goes wrong. Phased is the usual choice for business-critical production where a single big-bang window is too much risk.

The third case is a new-build cutover, where fresh gear is racked and stacked, validated, and the workload is migrated onto it from the old room. Which strategy fits depends on the workload, the tolerance for downtime, and the dependencies, so the decision belongs in the migration plan, not in the moment.

The migration runbook

The runbook is the step-by-step plan that runs the migration, and it is where migrations succeed or fail. It lists every task in order, who owns it, how long it should take, and what has to be true before the next step starts. It maps the dependencies so things come up in the right sequence, defines the downtime window, and names the validation that proves each step worked. A migration run off memory or a whiteboard is a migration that discovers its missing step at 2 a.m.

The part crews skip is the rollback. The runbook needs a back-out section with specific, measurable conditions that force a stop-and-revert, decided before the window opens, not argued over while the clock runs. Rehearse the runbook before the real cutover where you can, measure the actual downtime, confirm the rollback works, and fix the weak steps.

A method of procedure for the change controls the formal version of this, and the change process is where it gets reviewed and approved before anyone touches production. No approved runbook, no cutover.

Downtime, the cutover, and the back-out

The cutover is the moment of the actual switch, inside the maintenance window the change was approved for. Plan the window for the real worst case, not the optimistic path, and build in time to validate before you call it done and time to back out if you cannot. The window is a commitment to the business. Blowing through it with no back-out decision is how a planned change becomes an unplanned outage.

Validate against defined criteria, not a glance. The workload is up, the data is intact, the connections are live, the performance is in range. If the validation fails and you are past the point your rollback conditions named, you execute the back-out. You do not push on hoping it comes good.

Decide that line in advance. The hardest call in a migration is the one to stop and revert, and the runbook makes it for you so the room does not have to make it under pressure. Every change runs through the change process and its approved window, so confirm the window and the back-out plan are signed before the cutover.

Decommissioning the old gear

Decommissioning is the end of the equipment's life in the room, and it is a planned step with its own record, not a wire-cutting party after the migration. Confirm the workload is fully off the old gear and the new platform is stable before you touch the old equipment, then power it down in sequence, remove it, and retire the asset in the DCIM so the records match the room again. Cable pulled out comes out cleanly so it does not leave an unlabeled tangle for the next install.

The piece that cannot be skipped is the data. Every drive leaving the room carries data until it is sanitized, and the asset stays open in the records until it is accounted for. The decommissioning guide covers the full retirement workflow. The points that bite here are wiping the data, removing the gear without disturbing the live cabinet next to it, and closing the asset record. A decommission that leaves drives intact or assets open is a security and audit problem you handed to someone else.

Data wipe and sanitization (NIST 800-88)

Sanitize every drive before it leaves your custody. NIST 800-88, the media sanitization guideline, gives three outcomes: clear, which overwrites with standard commands; purge, which uses methods like cryptographic erase or block erase that resist a lab attack; and destroy, which physically ruins the media. Match the method to the data sensitivity and the project's policy, and verify the wipe rather than assuming the tool finished.

Keep a chain of custody from the moment a drive comes out until it is wiped or destroyed, with a record per serial of what was done and who did it. A drive that walks off the floor unaccounted for is a breach with your name on it. Where the data classification calls for destruction, the drive is shredded or degaussed and the destruction is documented, often with a certificate.

The exact method and the documentation are the security policy's and the data owner's call, so follow NIST 800-88 and the project's sanitization standard rather than picking a method in the field. The current revision adds a program-level framework, so confirm which revision and which method the policy names before you start.

What to document

The records are what let operations run the room and what prove the deployment was done right. Capture them per cabinet, keyed to the rack coordinate, as the work happens, because a record reconstructed after the cabinet is full and live is a record full of guesses. The asset, the elevation, the power, the cabling, the runbook, and the as-built all belong in the same coordinated set, in the DCIM and a field tool like FieldOS so they are logged at the point of install.

Common mistakes

• Loading a cabinet with no elevation or weight plan, so it ends up top-heavy and thermally uneven.
• Landing both A and B cords on the same PDU or the same upstream breaker, defeating the redundancy.
• Leaving cabling unlabeled, so the first fault under load turns into a hand-over-hand trace.
• Blocking front-to-back airflow and skipping blanking panels in the empty U.
• Racking gear with no asset record, so the cabinet cannot be audited or supported.
• Running a migration with no tested runbook and no defined rollback.
• Decommissioning gear without wiping the drives or closing the asset record.
• Cinching data cable with zip ties and dumping slack in the rear, choking the exhaust.
• Mounting heavy gear on its front ears alone, or muscling it up as a one-person lift.

Field checklist

Standards and references

TIA-606, the cabling administration and labeling standard, governs the identifier scheme for cables, panels, ports, and spaces, so both ends and the records agree. The rack, PDU, and server manufacturers set the mounting, the load ratings, the clearances, the PDU outlet and input ratings, and the firmware baselines, so build to the manufacturer's instructions for the specific model, not a remembered figure. NIST 800-88 is the media sanitization guideline behind the clear, purge, and destroy decision on a decommissioned drive.

A few more sit alongside. ANSI/TIA-607 and the NEC, NFPA 70, govern the bonding and the power grounding the cabinet ties into. TIA-942 frames the data center spaces and the cabling architecture the patch field inherits, and ASHRAE TC 9.9 gives the thermal envelope the airflow discipline is built to hold. The DCIM or CMDB carries the asset and configuration record, and the change process and its method of procedure control how a migration or cutover is reviewed and approved.

Across all of it, the elevation, the power, and the cabling follow the project design, the equipment manufacturer, and the adopted IT standards and code edition, so verify the numbers rather than carrying one in your head. Plan the elevation, the weight, and the dual A/B power; label and manage the cabling to standard; and migrate off a tested runbook and wipe every drive on decommission.

Units, terms, and conversions

Rack-and-stack mixes a few unit systems and a lot of shorthand on one drawing. Height inside the cabinet is counted in rack units, where 1U or 1RU is 1.75 in (44.45 mm). Power per rack is stated in kilowatts, weight in pounds or kilograms where 1 kg is about 2.2 lb, and copper runs are measured against the channel limits in meters or feet.

The terms below carry the subject across the deployment and the migration, from the elevation that fixes where the gear lands to the sanitization that closes out the gear coming off the floor.

Rack-and-stack

The physical install of servers, storage, and network gear into racks after the facility is ready, plus the migrations that load workloads in

U-space / elevation

The U-by-U map of what mounts where in the cabinet, 1U being 1.75 in (44.45 mm) of mounting height

Dual-cord A/B power

Two independent power feeds to one device, one cord each, from separate sources for redundancy

Rack PDU

The power distribution strip in the cabinet, in basic, metered, or switched grades, commonly 0U in the rear channel

Structured cabling / TIA-606

A fixed, tested, labeled patch field, and the administration standard that names every cable, port, and space

Lift-and-shift

A migration that moves the whole workload in one planned big-bang cutover window

Runbook

The step-by-step migration plan with owners, order, dependencies, downtime, and a defined rollback

Data sanitization

Removing data from a drive so it cannot be recovered, by clear, purge, or destroy under NIST 800-88

Related tools

Calculators and readiness checks for this work

Compare your options

FAQ

People also ask

• What is a rack unit (U)?
• What is rack readiness in a data center?
• What is TIA-606?
• Cast-in vs post-installed anchors: which should I use?
• What is a meet-me room?