Cable documentation for a move is the record of where every cable starts, where it ends, and how it is labeled, captured before anything is disconnected. A usable package has rack photos, a port-level map, consistent labels on both ends, and an exception list, so a technician who has never seen either room can re-cable correctly.
Every data center has two cable plants: the one in the documentation and the one behind the racks. During a move the gap between them becomes the critical path, because re-cabling depends entirely on knowing where each cable came from and where it belongs. The work is not creating documentation from nothing. It is closing the gap between record and reality before anything gets disconnected.
Why document first and disconnect second?
Because once a cable is unplugged, the information it carried (which port, which panel, which direction through the pathway) exists only in whatever was recorded beforehand. Recovering it later means tracing, which is slow and error-prone. This ordering is the discipline most often reversed under schedule pressure.
Capture before touching anything
- Rear elevation photographs of each rack, taken straight on, with enough resolution to read labels
- Close-up photographs of each patch panel and switch face
- A port-level map, using switch exports your network team provides and patch schedules where they exist
- Physical trace verification for anything the record does not explain
- Notes on anything that contradicts the documentation
That last category is the valuable one. Every environment has cables that should not exist: a temporary run from an old incident, a cross-connect to a decommissioned system, a patch that bypasses the structured cabling. Find them before the move so someone decides whether they move. The National Electrical Code (NFPA 70) treats abandoned communications cable as something to remove, not carry forward.
What makes a cable label hold up?
ANSI/TIA-606-C provides the framework most enterprise environments use: consistent identifiers for spaces, racks, pathways, cables and ports, applied to a documented scheme rather than invented per rack. The standard matters less than the consistency, but the physical practice matters a great deal:
- Label both ends of every cable, without exception
- Machine-printed labels only; handwriting fades, smudges, and is misread under a rack at 3 a.m.
- Self-laminating vinyl wraps for cable bodies; flag labels where wrap diameter will not work
- Labels readable in place, without pulling the cable forward
- Identifiers that match the documentation exactly, including case and separators
A label that is present but inconsistent with the port map is worse than no label, because it will be trusted. For the asset side of the same discipline, see asset tagging and labeling standards.
What extra documentation does fiber need?
Copper is forgiving. Fiber is not, and fiber problems in a new installation tend to appear as intermittent performance issues rather than clean failures.
- Record polarity method (Type A, B or C) and connector type for every trunk and patch
- Track MPO breakout configuration and cassette types where present
- Clean and inspect every connector at re-termination; contamination is the leading cause of post-move link problems
- Keep insertion loss budgets and test results with the port map, not in a separate folder
- Re-certify links after the move and compare against the origin baseline
Fiber cleaning gets skipped because the link comes up anyway. It comes up, runs at a degraded margin, and fails months later under load. Inspect and clean as a required step, not a conditional one. The fiber optic relocation guide covers handling trunks and cassettes in transit.
How do carrier and cross-connect circuits fit in?
Anything crossing the demarcation point runs on someone else's schedule. The demarc is where the carrier's responsibility ends, as defined for U.S. premises in 47 CFR 68.105.
- Inventory circuits with carrier IDs and current demarc locations early
- Order new cross-connects and circuit moves as soon as the destination is confirmed; multi-week lead times are normal
- Confirm Letters of Authorization are in place for the colocation provider to work on your behalf
- Verify the destination demarc location and available capacity before the move, not on move day
- Test each circuit end to end before it is needed
Carrier lead times cause more schedule slippage in migrations than any physical work does. They are also the easiest thing to start early. The MDF and IDF planning guide covers carrier sequencing in more depth.
What should the re-cabling package contain?
Photographs and a spreadsheet are not documentation until they are structured well enough for someone else to work from.
| Component | What it holds |
|---|---|
| Port map | Source rack, device, port; destination rack, device, port; cable type, length, label ID |
| Rack elevations | Origin and destination, with planned positions |
| Photo library | Organized by rack and indexed to the port map |
| Patch schedules | One per panel |
| Exception list | Anything undocumented, unresolved, or deliberately not moving |
The test is simple. A technician who has never seen either room should be able to re-cable a rack correctly from this package. If it requires a phone call to interpret, it is not finished. Build it during the pre-move survey, then review it with the crew lead who will use it before the first rack comes down.
Why does the destination need its own port map?
Re-cabling is rarely a one-to-one reproduction. Rack layouts differ, cable lengths change, pathway routing changes, and consolidation moves devices into different positions. Annotating the origin map to describe the new room produces a document nobody can read at 2 a.m.
Build the destination port map as a distinct document, keyed to the same label IDs so every cable can be traced from its origin row to its destination row. Then verify lengths against actual measured runs in the new room, not against the drawings, and allow for the slack and routing your cable managers need. The single most common re-cabling delay is discovering that a batch of patch cords is six inches too short after they have all been ordered.
Close the loop the same week
Documentation created during a move decays fastest in the days right after it, when small fixes happen quickly and nobody records them.
- Hand your IT team the as-built package so it can update the DCIM and CMDB from the as-built state, not the plan
- Re-verify labels physically against the final port map
- File certification and test results with the project record
- Log every deviation from the plan, including the ones that were obviously correct at the time
Closing the loop is cheap in the first week and expensive later, when someone has to re-trace a rack to settle a disagreement between two records. The move is the one moment when the documentation and the physical plant are guaranteed to match. That alignment is worth capturing properly, because it starts drifting again the following week.