UAT-to-Production
Governance: A Multi-Party Deployment Case Study
Category: Process Governance & Implementation
Management
When a production system change involves more than one organization,
the hardest part usually isn’t the technical work - it’s making sure
every party knows exactly what they own, in what order, and how a
handoff is confirmed rather than assumed. This case study walks through
a real production deployment that required coordinated action across
three parties: the client agency, a prime systems integrator, and the
platform vendor’s operations team.
The Setup
The system in question was a case-management platform running in
separate production and UAT (user acceptance testing) environments. A
release had been validated in UAT and was ready to move to production -
a process that, on paper, looks like a simple promotion. In practice, it
required five distinct categories of work, each owned by a different
party:
| Step | Activity | Owner |
|---|---|---|
| 1 | Client notification of planned outage window | Systems integrator |
| 2 | Full production database backup (rollback safety net) | Platform vendor’s DBA team |
| 3 | Export validated system configuration from UAT | Systems integrator |
| 4 | Export reference data changes from UAT | Systems integrator |
| 5 | Import system configuration into production | Systems integrator |
| 6 | Import reference data into production | Systems integrator |
| 7 | Migrate historical case data | Systems integrator |
| 8 | Update shared reference tables (owned jointly) | Systems integrator + client agency |
Why This Matters as
a Governance Case Study
Sequencing discipline. The backup step (owned by the
vendor’s DBA team) had to complete before any configuration
import began - not as a best practice, but as the only viable rollback
path if the deployment failed partway through. The documented procedure
made this dependency explicit rather than leaving it to the deploying
engineer’s judgment.
Accountability by activity, not by phase. Rather
than assigning “the deployment” to one party, each individual activity
had a named owner. This matters because a failure mode common to
multi-party deployments is the handoff gap - where each party assumes
the other completed a step. Explicit per-activity ownership
closes that gap.
Shared-ownership steps are called out explicitly.
One category of reference-data update required both the integrator and
the client agency to sign off jointly, since the values being changed
(routing/assignment rules) directly affected how the agency’s staff
would see their own casework the moment the deployment went live.
Treating this as a joint step - rather than folding it into the
integrator’s block of work - meant the client had a checkpoint to catch
a misconfiguration before it reached end users, not after.
A documented procedure is not the same as a controlled
one. The procedure existed as a narrative document, which is a
meaningful first step, but a narrative alone can’t enforce that
steps happened in order or that a step was verified before the next one
began. The most direct improvement path from this kind of artifact is
converting it from prose into an executable checklist or script with
built-in verification gates - the subject of a companion piece, The Deployment-Gate
Checklist.
Takeaway for Clients
If your organization runs any process - technical or not - where more
than one party touches production data or systems, the two questions
worth asking are: (1) is every activity assigned to exactly one owner,
with joint-ownership steps called out explicitly rather than implied,
and (2) is the sequencing dependency (what must finish before what can
start) written down, or does it live only in one person’s head?
Multi-party deployments are where undocumented tribal knowledge causes
the most expensive failures - and where a small amount of governance
discipline pays for itself the first time someone new has to run the
process.