Go-Live Is a Claim Until Readiness Is Tested

The rack is populated. Both power-supply LEDs are green. The carrier has closed its delivery order, and the project plan shows installation complete. None of those facts tells the production owner whether the service can be monitored, supported, recovered, or safely accepted.

Go-live is the transfer of operational consequence from a project into production. That transfer should occur only when evidence crosses a defined threshold—not when the last installer leaves the room.

Installation asks whether specified components were placed, connected, and powered. Customer-side acceptance asks whether the deployed service can enter production under known operating conditions with a named owner.

The distinction is established well beyond colocation. In Google’s Production Readiness Review model, readiness is a prerequisite for an SRE team to assume production responsibility; the review covers dependencies, monitoring, emergency response, capacity, change management, and performance. The exact checklist cannot be copied into a physical deployment, but the governing idea transfers: responsibility should follow demonstrated readiness.

A useful acceptance review therefore starts with the service the rack is meant to support, then traces backward through connectivity, device identity, power, management, access, support, and recovery. A photograph of powered equipment is evidence for one part of one gate. It is not evidence for the outcome.

A readiness review can delay a straightforward deployment when low-risk issues become indiscriminate blockers. Defined hold and conditional go criteria keep the review proportional to consequence.

Use the Eight Readiness Gates at the customer acceptance meeting. Each gate needs four things: required evidence, an owner, a blocking condition, and a decision.

Gate states are pass, conditional pass, fail, or not applicable with rationale. A conditional pass requires an owner, due date, compensating control, and explicit acceptance authority. “We will fix it later” is not a state.

Scale the framework to service criticality. It does not replace facility commissioning, integrated systems testing, construction acceptance, or qualified engineering inspection.

Physical acceptance begins with identity. The reviewer should be able to connect the approved design to the installed rack, each relevant asset, both ends of important cables, the intended power feeds, and the handoff points used by production.

Plausible-looking installations can still be ambiguous. Two power supplies may be energized from the same intended failure path; a neat cable may reach the wrong interface. The lights prove local state, not architectural intent.

Published provider guidance reinforces the customer’s role. Equinix’s customer installation guidelines state that incorrect customer installation can affect equipment performance and SLA claims. The practical implication concerns the customer boundary: installation evidence must distinguish provider delivery from customer-side topology and configuration.

An effective evidence package records asset IDs, rack position, port and power-feed mapping, time-stamped photographs, deviations, and verifier. Store it where the incident team can retrieve it—not only in a project chat or installer’s phone.

A carrier delivery record may prove that a circuit exists at the demarcation. Production acceptance requires the customer’s intended path to work through the devices, routes, policies, name resolution, security controls, and remote endpoints the service will actually use.

The test should answer a defined question. “Ping succeeds” may verify a handoff but not routing convergence, MTU, authentication, or failover. Record the origin, destination, expected and observed results, time, configuration version, and owner.

A second operational example makes the distinction clear. Suppose a new router is reachable from an engineer’s temporary deployment laptop, but its management interface cannot be reached from the authorized operations jump path. The connectivity gate may pass for the production data plane while the management-and-monitoring gate fails. Combining those results into one green “network ready” status would erase the exact dependency the on-call team needs during an incident.

Before acceptance, the intended operating team—not only the project team—should demonstrate that it can:

• reach the approved console or management path;
• authenticate with production credentials and recover access under the approved process;
• observe service and device health through owned monitoring;
• receive and route a representative alert;
• identify the correct escalation contact and severity path;
• obtain facility access during the required support window;
• issue an executable on-site task with the required evidence return.

Google’s launch-checklist guidance stresses manageable, current questions tied to actions. “Monitoring configured?” invites a ceremonial yes; ask which signals, which owner, which failure, and which test evidence.

The same standard applies to access. A submitted name proves only submission; verify active approval, task authorization, and after-hours escalation within facility and customer security rules.

Worked hypothetical: installed, reachable, and still on hold

Hypothetical example. A CDN node deployment is scheduled to enter production on Friday. The project team initially considers it ready because the node is racked, both power supplies are on, the carrier handoff has been delivered, and a remote engineer can reach the host.

The acceptance evidence reveals three unresolved conditions. The serial number in the asset register differs from the installed chassis; the management controller is reachable only through a temporary deployment VLAN; and the overnight on-call engineer is not on the approved facility access list. A replacement component is present, but no readiness record or approved validation path exists.

The affected decision is not whether the hardware works now. It is whether the production owner should accept a service whose identity, incident-management path, and one defined recovery option cannot yet be demonstrated.

The gate results are: physical installation—fail, management and monitoring—fail, access and support—fail, and recovery—conditional. The recommendation is hold. Closure requires corrected asset identity, management access from the authorized path, confirmed incident-window access, and either validated spare readiness or explicit acceptance of that recovery limitation.

Each missing item changes who can act, on what equipment, through which path after handover.

Bound recovery planning to credible failures. Each needs an owned response, its prerequisites, a stop or rollback condition, and validation.

NIST’s contingency-planning guidance separates restoration activity from reconstitution and states that system owners declare a system operational after successful validation testing. The document is written for federal information systems, not colocation acceptance, but the decision principle is useful: return to operation should follow functional validation and recorded authority.

For a customer deployment, recovery evidence might include current configuration exports, tested console access, a prepared replacement component, a controlled procedure, escalation authority, and an acceptance test. A spare counts only when its identity, readiness, authorization, and validation path are recorded.

Mark each item pass, conditional, fail, or not applicable, then attach evidence and an owner.

1. Approved scope matches the installed deployment.
2. Rack, cabinet, and device positions are recorded.
3. Serial numbers and asset identities match the authoritative register.
4. Production cable endpoints and labels match the port plan.
5. Intended A/B power connections are verified where applicable.
6. Applicable environmental and power observations have an owner.
7. Carrier handoffs and cross-connects have acceptance records.
8. The production path has been tested from relevant endpoints.
9. Management interfaces are reachable through the authorized operations path.
10. Production credentials and access-recovery procedures are controlled.
11. Monitoring covers agreed service and device failure conditions.
12. Representative alerts reach the named on-call owner.
13. Facility access lists and requirements are confirmed for support windows.
14. Provider, carrier, vendor, and customer escalation contacts are current.
15. On-site tasks use approved procedures and evidence requirements.
16. Prepared spares cover the defined recovery scope.
17. Rollback or stabilization triggers and authority are documented.
18. Acceptance tests, expected results, and evidence location are defined.
19. Exceptions have owners, due dates, controls, and acceptance authority.
20. A named owner records the final go, conditional go, or hold decision.

Ownership consequence. A go-live decision transfers incident exposure and support cost to production; accepted exceptions therefore require named business authority.

The consulting output is a go-live readiness report listing passed and blocked gates, accepted exceptions, owners, next actions, and the final recommendation. Its value lies in controlling the transfer of operational consequence.

Acceptance is an ownership decision

Accept a colocation deployment when the service—not merely the installed equipment—has passed the evidence gates required for its risk level and a named owner has accepted the remaining conditions. The review cannot eliminate future failures, but it can prevent an unevidenced project status from becoming a production dependency.

Before production activation, I can conduct an independent customer-side readiness review and arrange controlled local verification where physical evidence is missing. You receive a gate-based go-live report that separates completed installation, accepted exceptions, and genuine production readiness.