The Pre-Opening Acceptance Test: What “Ready for Go-Live” Really Means

Every event has a moment that decides whether the network was built right: the first time the event opens and thousands of real transactions, badge scans, and production streams hit the system at once. By then it is far too late to discover that a payment VLAN can see the production network, or that a “redundant” circuit fails over in ninety seconds instead of the five you promised. The job of the pre-opening acceptance test is to move that moment of truth earlier — into a controlled window, before go-live, where a problem is a finding instead of an incident.

At LGL Networks this is not a vibe check or a quick “can you load a webpage” walk-around. It is a documented, repeatable procedure run against an explicit pass/fail standard, with the results captured for the post-event report and the accountability scope defined in writing in the statement of work. We run and stand behind your event’s mission-critical network — setup to teardown — so registration, payments, production and streaming stay connected. The acceptance test is where “stand behind” stops being a slogan and becomes evidence.

What the test actually verifies

A pre-opening acceptance test exists to confirm four things are true at the same time — not in theory, not on the design diagram, but on the live deployment in the building:

• Segmentation holds. The documented segmentation standard isolates payment, production, registration, attendee, contractor, and management traffic. The test proves those boundaries are enforced — that a device on the attendee or contractor zone cannot reach the payment or production zones, and that management interfaces are not exposed to anything that shouldn’t see them.
• Failover lands inside its window. Where the venue permits dual-WAN, we deliberately fail the primary path and confirm the secondary takes over within the target window defined in the scope. Mean-time-to-failover on critical paths is a number we measure, not a feature we assume.
• Critical-system redundancy is live. Wired-first drops for payments, registration, encoders, and show control are up, and their resilient paths are actually active — not cabled-but-cold.
• Monitoring is reporting. The NOC is seeing the deployment, alarms are wired, and the people who will respond at 7:58pm can already see what they’ll need to see.

Notice what the test is careful not to claim. LGL operates at the transport layer. The acceptance test verifies the network and connectivity we operate — availability, redundancy, segmentation, failover — not the uptime of the payment application, the payment processor, or the registration platform riding on top of it. Drawing that line precisely is part of being the accountable operator: one clear owner for the network, and an honest boundary around what the network can and cannot promise.

Why first-run pass rate matters

The metric we track is the pre-opening acceptance-test pass rate — the percentage of events that pass the documented test on first run. First run is the part that matters. Almost any deployment can be made to pass eventually if you keep poking at it. A high first-run pass rate is the signal that the deployment pods, runbooks, and standardized configs are genuinely repeatable — that we arrived at the venue and stood up a proven, segmented network, rather than improvising one and debugging it under time pressure.

A network that only passes on the third attempt didn’t pass — it was rescued. The goal is to be right the first time, with hours of margin, not minutes.

First-run pass rate is also an early-warning system. When it slips, it usually means a runbook drifted, a config wasn’t templated, or a venue surprise wasn’t caught during the risk assessment. Watching the number over a portfolio of events tells us where to harden the process before a weak spot becomes a failure on someone’s revenue night.

The goal: zero sev-1 incidents from untested failover

Redundancy that has never been exercised is a hope, not a safeguard. The most avoidable category of event-day failure is the “redundant” path that turns out not to work the one time it’s needed — because nobody pulled the primary and watched what happened. Our standard is blunt about it: we test failover before go-live so that no severity-one incident is ever caused by a failover path we never proved.

That means deliberately inducing the failure conditions we designed for, in the acceptance window, when there is time and no audience: pull the primary WAN and confirm the cutover; confirm critical wired paths survive a single-point failure; confirm the segmentation rules survive a device being plugged into the wrong port. Better to trip the alarm ourselves at 3pm than to discover the gap with a line of attendees holding payment cards.

What a passing test produces

A completed acceptance test is also a record. It feeds the post-event report, it underpins the accountability scope defined in the statement of work, and it gives the organizer or production partner something they rarely get from a connectivity vendor: written, dated proof of exactly what state the network was in when the event opened.

A practical pre-opening checklist

This is the shape of what gets verified and signed off before go-live. Specific thresholds and target windows are set per event in the scope.

None of this happens in a vacuum. The acceptance test is the last gate in a sequence that starts well before setup: the Event Network Risk Assessment surfaces the venue rights, critical applications, and pathway constraints; written venue authorization clears the deployment; the segmented overlay goes in behind the venue circuit; and only then does the test confirm it all holds. Skip the upstream steps and the test simply discovers the problems later — which is the entire failure mode it was built to prevent.

“Ready for go-live” should never be a feeling someone has about the network. It should be a test that passed, a record you can read, and an operator who put their name behind the result.