How to Evaluate a Data Center in Azerbaijan Before Signing a Contract

A data center proposal can be accurate and still be insufficient for a contract decision. Assume the quoted power is available, the certifications are current, and the tour is professional.

The buyer may still not know who can enter the facility at 2:00 a.m., what happens during concurrent maintenance, how a carrier path reaches the building, or which recovery steps have ever been exercised. Those are not secondary details. They determine whether the proposed service can support the customer's operating model after the sales process ends.

The purpose of pre-contract evaluation is therefore not to decide whether a provider appears credible. It is to determine which claims are decision-ready, which remain assumptions, and what the unresolved uncertainty means for the deployment.

Most comparisons begin with visible, easily tabulated attributes: price, available rack space, contracted power, cooling approach, certifications, connectivity options, and headline service levels. These matter, but they describe only part of the service.

The missing layer is behavior. A facility is experienced through access procedures, change windows, maintenance coordination, escalation paths, spare-part handling, cross-connect delivery, and recovery actions. Two proposals with similar technical features can behave very differently when a customer needs an urgent intervention or a carefully controlled change.

The distinction between a reported representation and the underlying operating state also runs through my infrastructure resilience notes. During procurement, it matters before any equipment is installed: a green comparison cell can hide a condition that has never been examined in the customer's context.

Recognized standards reinforce the need to connect facility characteristics with business requirements. ISO/IEC 22237-1 covers availability, security, energy efficiency, business risk, operating cost, and references to data center management. Its operational companion, ISO/IEC TS 22237-7, focuses on the processes required to deliver the intended resilience and availability. A certificate or standards-based design can be valuable evidence, but the buyer still has to map its scope to the proposed service and deployment.

Consider a simple example. A provider confirms that Remote Hands is available around the clock. That statement does not yet establish who may authorize a hardware replacement, whether the technician may select a spare, which actions require a method of procedure, or what evidence will close the task. The feature exists; the recovery path remains undefined.

A useful assessment starts with the customer's operating model, not the provider's brochure. Before requesting evidence, define the decision the facility must support.

At minimum, translate the deployment into six groups of criteria:

• Workload consequence: What is the business effect of losing a rack, a power path, a carrier circuit, or physical access?
• Capacity and growth: What power density, floor loading, space, cooling envelope, and expansion path are required, and over what period?
• Connectivity: Which carriers, cloud connections, latency constraints, route dependencies, and cross-connect lead times affect the design?
• Operating cadence: How often will the customer perform changes, receive equipment, replace components, or require vendor access?
• Recovery model: Which actions must be possible outside normal hours, who has authority, and what recovery time is the architecture designed to support?
• Governance and assurance: Which security, reporting, audit, contractual, and evidence requirements apply to this specific deployment?

The criteria should distinguish requirements from preferences. If independent A and B power delivery to dual-corded equipment is a design condition, it is not a bonus feature to be traded against a lower monthly price. If occasional escorted access is acceptable, unrestricted access should not receive a large score simply because it sounds better.

This translation also prevents a common procurement error: evaluating every available provider feature instead of evaluating the few conditions that materially change the customer's outcome.

A credible statement is not automatically decision-ready evidence. Its evidentiary status must remain visible.

I use four evidence states during a provider evaluation:

1. Documented. The claim is supported by a current document with identifiable scope: a service schedule, certificate, single-line diagram, access procedure, maintenance policy, test report, or other controlled record.
2. Reported. A provider representative has answered the question verbally or in correspondence, but the claim is not yet tied to adequate supporting material or contractual language.
3. Observed. The condition has been seen during an approved visit or demonstration. Observation confirms what was visible at that time; it does not prove hidden dependencies or behavior under failure.
4. Tested. The relevant behavior has been exercised through an approved test, drill, sample workflow, or witnessed procedure, with results and scope recorded.

This is an evidence ladder, not a rule that every claim must reach the fourth level. Testing a commercial term makes no sense; the executed contract is the relevant evidence. Observing two entrance rooms does not prove end-to-end carrier separation. A failover test from last year may not describe the current configuration. Evidence is useful only when its scope, date, ownership, and relation to the claim are clear.

The ladder exposes gaps without turning them into accusations. A reported answer may be entirely correct. The assessment simply records that the buyer is relying on a statement that has not yet been validated to the level required by the decision.

For example, a provider may document two power paths to the customer area. The buyer might observe the distribution equipment and review a maintenance explanation. If the customer's recovery case depends on transfer behavior, however, the remaining question is whether suitable commissioning or test evidence addresses the relevant configuration. Each step adds confidence, but none should be silently substituted for another.

The strongest questions follow the service through normal work and abnormal conditions. They ask what happens, who acts, what dependency is involved, and how the answer can be verified.

Pre-contract assessment checklist

1. Which exact space, rack, power, cooling, and growth requirements are included in the proposal, and which are conditional?
2. What customer load and rack-density assumptions were used to confirm capacity?
3. Which certificates or assessment reports apply to the proposed facility, service, and current configuration?
4. What planned-maintenance activities can affect the customer's power, cooling, access, or connectivity?
5. How are maintenance notices, method statements, conflicts, and customer objections handled?
6. Who may request, approve, and revoke physical access during and outside normal hours?
7. What escort, identity, security, or advance-notice conditions can extend the access timeline?
8. What Remote Hands actions are available, prohibited, or subject to separate authorization?
9. How are the correct device, component, port, and spare identified before physical work begins?
10. What evidence is provided after an on-site task, failed attempt, or observed anomaly?
11. Which carriers and cross-connect options are commercially available for the proposed space?
12. What can the provider substantiate about facility entrances, meet-me-room dependencies, and internal cross-connect paths?
13. Who coordinates carrier incidents and planned work when responsibility crosses organizational boundaries?
14. Which recovery procedures relevant to the proposed service have been exercised, and what is the scope and date of the evidence?
15. Which open assumptions must be resolved before signing, converted into contract conditions, or explicitly accepted by the buyer?

These questions are intentionally selective. A good assessment is not the longest checklist. It is the shortest set of questions capable of changing the decision.

Unanswered questions should not disappear into meeting notes. Convert them into an assumption and risk register tied to the proposed operating model.

Each entry should state the assumption or condition, current evidence level, possible operational consequence, affected business requirement, owner, required follow-up, and decision treatment. The treatment may be to close the gap before signature, add a contractual condition, change the technical design, accept the exposure, or remove the provider from consideration.

Suppose two carrier services are quoted, but end-to-end physical separation cannot be confirmed. The finding is not “connectivity is not redundant.” That would overclaim. A defensible entry is: “The proposed services are commercially distinct; shared external-route dependencies remain unverified.” The consequence and treatment then depend on the customer's tolerance. A deployment with independent out-of-band recovery may accept the uncertainty. Another may require a different design or further evidence.

This phrasing matters. It separates an identified defect from an evidence gap and prevents uncertainty from being presented as fact.

The same discipline applies to access. If the documented process requires advance authorization but the emergency workflow is only reported, the register should identify the missing approval path and its possible effect on recovery. It should not invent a response-time estimate.

The final output should be more useful than a scored spreadsheet. A provider-comparison brief should explain:

• the decision and operating assumptions;
• mandatory requirements and deal breakers;
• the evidence supporting each material conclusion;
• differences between documented, reported, observed, and tested claims;
• unresolved dependencies and their consequences;
• contractual, technical, or procedural conditions required before commitment;
• the recommended option, credible alternatives, and the reason for the recommendation;
• the next actions, owners, and decision deadlines.

The recommendation may still contain uncertainty. The objective is not to manufacture certainty before a contract. It is to show leadership exactly where confidence is strong, where it is conditional, and what would have to change the recommendation.

That is the difference between a facility tour and due diligence. One creates familiarity. The other produces a traceable basis for a capital and operating decision.

Planning a data center or colocation decision in Azerbaijan? I provide independent provider evaluation and operational due diligence, including provider-comparison briefs, evidence-gap analysis, and assumption and risk registers for international infrastructure teams.