A signed order starts a data center deployment; it does not establish that every dependency is ready. A first rack or cage brings together facility work, carrier delivery, hardware, configuration, and application decisions. For a migration, the existing environment must remain recoverable while those pieces come together.
Use this checklist to define what each phase must produce and who can accept it. Keep the working documents together so the installation team and the people taking over operations use the same approved information.
Assign owners and confirm dependencies
Name a deployment lead and individual owners for facility coordination, network delivery, hardware, systems, application acceptance, and change approval. Give each task a prerequisite, completion evidence, and an escalation contact. A shared department name is insufficient when someone must resolve a blocked delivery.
Confirm facility readiness, power installation, cross-connects, carrier service activation, hardware availability, and access approvals with the responsible parties. Record confirmed dates separately from requested dates. Use supplier commitments and delivery evidence to build the schedule; avoid assuming a standard lead time applies to every site.
Agree on the scope of deployment services, including who racks equipment, loads configurations, tests applications, and approves production use.
Approve the physical, power, and network plans
Create an inventory with model, serial number when available, rack units, configured weight, depth, rail kit, power supplies, and network interfaces. Produce a rack elevation showing equipment positions, reserved space, and cable management. Check rack loading, rail compatibility, service clearance, and airflow direction against the actual equipment documentation and facility rules.
Cable planning must account for maintenance access. Dell's PowerEdge T630 cabling guide illustrates how rail compatibility, cable management arms, strain relief, and service movement affect installation. Use the guide for your specific model before settling cable routes.
Approve two accompanying documents:
- A power schedule covering approved capacity, connectors, power distribution units, outlet assignments, and A/B supply mapping where provisioned. Confirm that the design supports the intended failure condition.
- A network plan covering circuit and cross-connect identifiers, demarcation points, optics, port assignments, addressing, VLANs, routing, firewall rules, DNS, and management access.
Resolve connectivity requirements before patching begins. Labels at both cable ends should match the port map.
Prepare receiving, access, and initial configuration
Confirm shipping labels, delivery appointments, loading restrictions, receiving contacts, storage arrangements, and the procedure for damaged or missing equipment. Reconcile deliveries against the inventory before the installation window. Arrange visitor authorization, escorts where required, tools, and a remote-hands work order with explicit tasks and escalation limits.
Establish and test out-of-band access through an approved management path. Record how an authorized operator reaches consoles when the production network is unavailable, and protect those credentials in the agreed credential store.
Before application data arrives, apply an approved baseline: compatible firmware and drivers, operating-system patches, storage configuration, time synchronization, logging, monitoring agents, and security settings. Replace default credentials, restrict management interfaces, and disable unnecessary services. Record versions and retain configuration backups so later troubleshooting starts from a known state.
Rehearse the migration and define rollback
Write the cutover sequence around application dependencies, including databases, authentication, scheduled jobs, and external integrations. Assign an operator and a verifier to consequential steps. Specify when writes stop, how final synchronization is checked, and when traffic changes.
Take application-consistent backups and complete a representative restore test before approving the move. Record the recovered data, elapsed recovery time, and application validation result. Microsoft's disaster recovery guidance recommends testing restores and validating recovery procedures in nonproduction before production drills.
Set a decision cutoff that leaves time to execute rollback within the approved window. Define measurable stop conditions, such as failed transactions, unacceptable error rates, incomplete synchronization, or lost management access. Document who can call rollback, the reversal steps, and how to handle writes accepted after cutover. Microsoft's migration planning guidance supports workload-specific rollback instructions, tested recovery steps, and explicit decision authority.
Test against agreed acceptance criteria
Acceptance should demonstrate the intended service under agreed conditions. Capture baseline application response times, throughput, storage latency, hardware health, and network behavior, then compare results with the approved requirements.
Test customer-controlled failover paths only within a documented scope and authorized window. Agree on the equipment, traffic, expected interruption, abort criteria, and observers. Coordinate any power-path exercise with the facility; never operate shared facility infrastructure as an informal acceptance test. Confirm alert delivery and recovery behavior as well as the failover itself.
Have the application owner sign off representative business transactions. Record exceptions with owners and deadlines before declaring acceptance.
Hand over an environment someone can operate
Deliver as-built rack elevations, power and port maps, inventory, configuration versions, test results, and recovery procedures. Record outstanding work and where credentials are securely held.
Assign responsibility for monitoring, incident response, backups, restore testing, patching, hardware replacement, and carrier escalation. Confirm contact routes and coverage expectations with whoever provides system administration. Close the deployment when operational ownership is accepted and the agreed stabilization checks are complete.