Server Room Migration Preliminary Plan

Server room migration preliminary plan: inventory, move waves, rollback thinking and power/network dependencies before racks are bought.

Project context

• Setting: Mainland / GBA office server room move
• Scale: Single server room / IDF-dense room migration to new floor or building

Challenge

Facilities planned a move of the office server room. Stakeholders needed a preliminary migration plan: inventory, wave design, rollback thinking, power/network dependencies—before purchasing racks or booking elevators. Risk of treating migration as “unplug Friday night” without dependencies.

Environment

• Source room with mixed servers, NAS, network stack, CCTV NVR possible
• Target room with power/cooling assumptions to validate
• Business apps with undocumented owners
• Limited maintenance windows

Solution architecture

Text view of the architecture (each line: component → what it connects to):

Inventory & dependencies → Migration waves
Migration waves → Wave1 - low risk services, Wave2 - line-of-business, Wave3 - edge / hard cut, Acceptance per wave
Wave1 - low risk services → Rollback points
Wave2 - line-of-business → Rollback points
Wave3 - edge / hard cut → Rollback points

Technical highlights

Inventory dimensions

• Device role · dependencies · power plug type · rack U · network ports · backup state · owner
• Hosts documented with role labels such as Server-A or NAS-01.

Wave design

• Prefer migrating stateless or easily rebuilt services first.
• Domain controllers / firewalls planned with explicit auth impact notes.
• Physical rack-and-roll vs rebuild-in-target decision tree.

Network & cabling

• Target IDF patch plan ready before move day.
• Temporary parallel uplinks if overlap window exists.

Power / cooling

• Preliminary plan lists questions to validate (circuit capacity, UPS runtime); capacity figures come from facilities, not assumptions.

Rollback

• Each wave defines abort criteria (e.g. auth broken, backup unreachable).
• No “zero downtime” promise unless the architecture genuinely runs in parallel and this is contracted.

Implementation steps

1. Discovery inventory.
2. Dependency map workshop.
3. Target room readiness checklist.
4. Preliminary wave plan + RACI.
5. Risk/rollback review with app owners.
6. Decide go / revise / hire specialized movers.
7. Detailed runbook (follow-on SOW) → execute.

Acceptance (preliminary plan stage)

• Inventory signed as “best known”
• Waves reviewed by app owners
• Target readiness gaps listed
• Rollback principles agreed
• Preliminary plan accepted as planning baseline

Deliverables

• Inventory workbook
• Dependency notes
• Preliminary wave plan
• Target readiness checklist
• Risk/rollback section
• RACI

Outcome

Stakeholders received a preliminary server-room migration plan suitable for budgeting and scheduling.

Related

• Project support services
• More Easyton case studies

Easyton has delivered IT infrastructure and support projects since 2009. Planning something similar? Contact Easyton to discuss your requirements.