Data Center Commissioning Software: Why Integrated Systems Testing Always Slips the Handover Date

Why commissioning is where a data center build actually finishes or does not

Construction on a data hall ends long before the building is worth anything. The concrete, the steel, the switchgear and the pipework are all in place, and none of it produces revenue until somebody has proved, with evidence, that the design does what the owner asked for under failure conditions. That proof is commissioning, and it runs through staged levels: factory witness testing on major equipment, site acceptance and pre functional checks, functional performance testing on each component, integrated systems testing where systems are exercised together, and finally full load testing with deliberate failures.

The scale of that is not intuitive from outside. A single hall can involve thousands of individual test scripts across hundreds of tagged pieces of equipment, executed by multiple contractors, witnessed by a commissioning authority, an owner representative and sometimes a tenant. Each script produces a result, and each failure produces an issue that has to be assigned, fixed, retested and closed. Then all of it has to be assembled into a turnover package that the owner accepts before the building can be handed to operations.

The economics are brutal in a way that makes this worth solving properly. A hall that is physically complete but not commissioned is a fully funded asset producing nothing, often against a lease or a customer contract with a committed service start date. Every week of commissioning delay is a week of that. And the delay is almost never caused by the physical work. It is caused by evidence: a witness who was not there when the test ran, a script executed against a superseded revision, an issue that was fixed on site and never closed in the log, or a turnover package that takes two months to assemble because it was never assembled as the work happened.

The week integrated systems testing goes wrong

Level 4 integrated systems testing is when the building is exercised as a system. Utility is dropped, generators start and take load, transfer switches operate, the uninterruptible power supplies carry the gap, the mechanical plant rides through and recovers, and the whole sequence is measured against the design intent. It is scheduled weeks in advance because it requires load banks, vendor engineers, the commissioning authority and the owner all present at the same time.

What goes wrong is rarely the test. What goes wrong is that on the morning of the test three pre functional checks on chilled water pumps are still open, because a contractor completed them on paper and the paper is in a site office folder. Nobody can confirm readiness, so the scenario runs anyway with a caveat, or it does not run and a very expensive day of load bank rental and vendor time is lost. Then during the run an anomaly is observed on a transfer sequence, and three different people log it in three different formats: the mechanical contractor in their own spreadsheet, the electrical contractor in an email, and the commissioning agent in the master log. Two weeks later, nobody can say whether that anomaly was resolved or whether the three entries are the same event.

That is the whole problem. Not the engineering. The state of readiness at any given moment is unknowable, and the issue record is fragmented across the organisations that created it.

What CxAlloy, Facility Grid and Procore actually fail at

All three are real, all three are used on data center projects, and none is a bad choice for what it does. CxAlloy is purpose built for commissioning and handles issue logs and checklists competently across building types. Facility Grid is aimed directly at this space and is a credible product. Procore is construction management at the project level and holds documents, submittals and field records well.

Where owners with continuous build programmes run into limits is consistent. The first is script libraries as a versioned asset across projects. Data center owners standardise: the same switchgear model, the same uninterruptible power supply, the same air handler across five sites. The script that tests it should be a library object with a version, and when the standard changes the library changes and every future project inherits it. Products generally treat scripts as project scoped content, so each project rebuilds or copies them and they drift. Two years later, two sites in the same portfolio are commissioned to subtly different standards and nobody intended that.

The second is the integrated systems test as a modelled object. Level 4 and 5 scenarios are not checklists on equipment, they are timed sequences with expected behaviour at each stage, multiple simultaneous observers, and instrumentation data captured during the run. Generic commissioning tools model a test as a form. They do not model a scenario with a timeline, observers stationed at different points in the building, and measured values that need to be compared against design intent.

The third is contractor participation. If subcontractors will not enter results into the system, the system holds a partial picture and the commissioning agent maintains a shadow spreadsheet, which is exactly the state you were paying to escape. Getting a mechanical subcontractor's field engineer to complete pre functional checks on a phone requires an interface designed for them, not a licence seat in a platform designed for the owner.

The fourth is the turnover package. Owners want a specific structure with their equipment identifiers, their document taxonomy and their acceptance criteria, delivered into their own systems and often into the operations platform the facility will run on. Standard exports get you to a folder of files and then a person spends six weeks restructuring it.

What a custom commissioning build has to include

Start with the equipment register at tag level, imported from the design and reconciled against what was actually installed including serial numbers and submittal data. Every test result, issue and document in the system attaches to a tag. Systems and subsystems group tags, and a system carries a readiness state derived from the tags inside it rather than declared by a person.

The script library is the second foundation. Scripts are versioned templates attached to equipment types, with the steps, the acceptance criteria, the required witnesses and the level they belong to. A project instantiates from the library. When your standard changes, the library version changes, and you can see which sites were commissioned under which version, which matters more than people expect when a fleet wide equipment issue emerges later.

Execution has to work on a phone or tablet, offline, in a building with no signal and no finished ceilings. Steps are ticked with values entered where values matter, photos attach, and witnesses sign in the app at the time of the test rather than on a printout collected afterwards. A witness signature captured three days later is not evidence, it is a formality, and everyone in the room knows the difference.

One issue log, and only one. Every contractor writes into it through their own view. An issue has a tag, a discipline, a severity, an owner, a required retest, and a closure that requires the retest to have passed. Duplicate detection matters because the same anomaly gets logged by three observers during an integrated test, and merging them later is a manual chore nobody enjoys.

Integrated systems test scenarios get their own model: a named scenario with a timeline of events, expected behaviour at each step, observers assigned to positions, and a place to attach instrumentation output and power monitoring data captured during the run. Readiness for a scenario is computed from prerequisite completion, so on the morning of the test the answer to whether we can run is a screen rather than a debate.

Turnover assembly should be continuous. Every accepted script, closed issue, operations manual, warranty and training record accumulates into the package as the project runs, structured to the owner's taxonomy from day one. Handover then becomes a review and an acceptance rather than a two month assembly project, which is where a large part of the schedule saving actually comes from.

What it costs and how long it takes

In Digital Heroes delivery experience, a first release runs $80,000 to $160,000 and ships in 12 to 18 weeks. That covers the tag register, the versioned script library, offline mobile execution with witness sign off, and the single issue log with contractor views. It is used on a live hall, not piloted on a completed one.

A full platform at $200,000 to $450,000 phased over 6 to 12 months adds integrated systems test scenario management with observer assignment and instrumentation capture, load bank and vendor scheduling, automated turnover package assembly to the owner's structure, owner acceptance workflow, and export into the operations and maintenance platform the facility will run on.

What raises the cost in this category: the number of distinct owner standards you must satisfy, if you are a commissioning authority working for several owners rather than an owner yourself. Instrumentation and power monitoring data capture during integrated testing, which is genuinely valuable and genuinely fiddly. Export into an operations platform, since attribute mapping into a maintenance system requires that system's cooperation. And the number of contractor organisations that need their own view, each with an onboarding cost.

What holds it down: one project, electrical scope first, mechanical second, and a script library seeded from your three most common equipment types rather than all of them.

When buying is the right answer

If this is a single build and you will not do another for years, buy. CxAlloy or Facility Grid on a project licence is proportionate, and the money is better spent on a stronger commissioning agent and more load bank days. A one off project does not amortise a platform.

Build when you commission continuously, when you standardise equipment across sites and want a script library that is genuinely one asset, when tenants or customers impose acceptance criteria you must evidence, or when turnover package assembly has become a repeatable multi week tax on every handover. The economic case is almost always the revenue start date, so work out what a week of delay costs on one hall and compare it to the build. Most owners find that comparison decides the question quickly.

How to choose a developer for commissioning software

Ask them to model an integrated systems test scenario on a whiteboard. What you want to see is a timeline with expected behaviour, observers at positions, and measured values compared against design intent. What you do not want is a checklist with a pass or fail toggle, which is what a developer who has only built inspection apps will produce.

Ask how a subcontractor's field engineer completes a pre functional check. If the answer involves a licence, a login and training, contractor adoption will fail and the commissioning agent will go back to a spreadsheet. The right answer is a narrow, fast interface that works offline and asks for exactly what is needed.

Ask how script library versioning works when the owner standard changes mid project. This is the question that separates people who have thought about a portfolio from people who have thought about a project, and the answer tells you whether the system will still be useful on your fourth site.

Ask who owns the code and settle it before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else to continue. At Digital Heroes the client owns the code from the first commit. The commissioning record is the evidence that your building performs as designed, and it will be referenced during warranty claims and incident investigations for years, so access to it should never depend on a commercial relationship.