Skip to content

Customer delivery & systems integration

Moving an Eight-Bay Venue to Production

An operating venue needs more than a deployed page. The rollout had to preserve booking state, local rules, device identity, and a writable recovery path.

4 min read

The engineering decisions

  • A stable venue identity connects configuration, devices, and acceptance.
  • Technical checks and physical device observations prove different things.
  • After new production writes begin, recovery must respect the new data boundary.
  1. 01

    Local requirements

    Operator rules, timezone, currency, rooms, and enabled capabilities.

  2. 02

    Acceptance

    Configuration, device mappings, and isolated booking checks.

  3. 03

    Controlled cutover

    Freeze writes, reconcile records, and activate a writable candidate.

  4. 04

    Recover and observe

    Keep the current database authoritative and track field checks.

A simplified view of the implementation flow. The checks and recovery boundaries are explained below.

Turn local requirements into an explicit configuration

The New Zealand GolfJoy venue had eight simulator bays and was already operating when I prepared its move to the production platform. The deployment had to bring booking rules, membership behavior, devices, and regional settings into agreement. A page responding with HTTP 200 was only a small part of that task.

I used the venue's stable identity to organize requirements and acceptance. The legal operator, physical venue, customer contact, test store, and production store were related records, not interchangeable identifiers. Names could change without changing which venue a configuration or device belonged to.

Local settings were explicit. New Zealand timezone and currency could not inherit a California template. This venue used payment at the venue and did not enable door access. Treating those choices as capabilities prevented an unrelated venue's payment or door workflow from appearing simply because the same application code was deployed.

Separate technical ownership from field communication

I owned the implementation decisions, configuration, integration checks, and release. The venue operator supplied local requirements and field support coordinated with the device vendor. In particular, field support handled the vendor communication needed to resolve the device-registration gap.

That distinction mattered in the troubleshooting loop. The field team could observe a physical screen and confirm a device. I could compare that observation with the mapping, selected device service, booking state, and command result. The next action depended on which layer had failed, rather than treating every symptom as a frontend bug.

I kept device identity, command acceptance, and physical behavior separate. A successful vendor API response did not prove that the intended bay had changed state. A device heartbeat did not prove the complete booking lifecycle. The acceptance record therefore tracked those observations individually instead of turning one successful response into an all-bays claim.

Prepare a recovery path before moving customer traffic

Before cutover, I checked the source, test, and production resource boundaries, rehearsed backup restoration, and validated candidate deployments. Isolated acceptance exercised real login and booking creation/cancellation with test records, followed by cleanup. Those checks could not substitute for reconciling the operating venue's current data.

The cutover plan had a writable fallback and a writable primary tied to the intended production database. Before either received customer writes, a failure could restore the source application. After the target started accepting writes or background work, the recovery boundary changed. Returning to the old database could discard new state, even if the old page still looked healthy.

I treated the start of production traffic as a state transition that had to be recorded before later health checks. Recovery could then distinguish preparation from a live production system. It could continue on the current database without repeating the final migration or copying newer production state backwards.

Brief write freezes were part of the actual migration

The production record contains two controlled write-freeze windows. During the first attempt, an active checked-in booking caused the migration to stop. Because target writes had not begun, the original writable source was restored. The booking then completed through the source system's normal business logic before the second attempt.

The second freeze allowed a consistent backup and final copy. I reconciled booking relationships and the relevant future-booking snapshot before the writable fallback took customer traffic. Read pages remained available, while new booking and administrative writes were explicitly blocked during the freezes. This was not an uninterrupted-write migration.

A later completion check encountered an alias-audit issue after production traffic had started. The venue stayed on the verified writable fallback while I corrected the project-scoped alias check. The failure did not send it back to the old database or leave it on a read-only destination. Recovery behavior was part of the delivery result, rather than an afterthought.

A completed cutover is one outcome, not every possible acceptance

The production cutover completed on August 26, 2026, with reconciled booking records and a verified primary/fallback path. Later venue records confirm the eight-bay venue running on the production platform. The public customer entry point is GolfJoy Play.

Physical acceptance remained a separate track. The record included field lock/unlock observations for specific bays and later successful vendor command results, but those did not justify claiming that every device and every real member journey had been physically verified. I preserved the remaining checks instead of hiding them behind the completed deployment status.

The reusable lesson is to define what each piece of evidence proves. A deployed revision, valid configuration, accepted device command, physical screen observation, and complete customer workflow are different facts. Customer delivery becomes more reliable when the release decision uses those facts together without allowing one to stand in for the rest.

Project context and evidence

Written from my August 2026 rollout, with later venue-state checks. Public links below support the product and attribution context. Internal project records are summarized, with customer records, credentials, and employer source code omitted.

Related engineering articles

All articles ↗