Goal
Go to production safely with a rollback path, then hand over everything the client needs to own the product.
Inputs → outputs
Inputs
- Approved release and runbook
- Rehearsed cutover plan
- User & admin documentation
Deliverables
- Release running in production
- User guide, admin guide, runbook
- Source repo + access, account & secret inventory (securely handed over)
- Handover record
Teams & roles
- DevOps / SREleads go-live and hypercare
- Data & AIdata cutover and reconciliation
- Support & Customer Successtraining, user docs, support intake
- Project Management / Scrum Mastercoordinates handover and records
- Application Security (AppSec)secure secret handover
- Client (Product Owner / sponsor)picks the window, receives handover, rotates credentials
RACI matrix
R — does the work · A — accountable, final sign-off (exactly one A per activity) · C — consulted before · I — informed after.
| Activity | BA | PM | Dev | QA | Sec | Ops | Data | CS | Client |
|---|---|---|---|---|---|---|---|---|---|
| Go-live (backup, migrations, monitoring, roll-back) | · | · | R | · | · | A | R | · | I |
| Data cutover & post-go-live reconciliation | · | · | · | R | · | · | A | · | C |
| User & admin training | R | · | · | · | · | · | · | A | C |
| Hand over code, accounts, secrets | · | A | · | · | C | R | · | · | R |
| 72-hour hypercare | · | · | R | · | · | A | · | R | · |
| Sign the handover record | · | R | · | · | · | · | · | · | A |
BA = Business Analysis (BA); PM = Project Management / Scrum Master; Dev = Engineering (FE · BE · Mobile); QA = Quality Assurance (QA/QC); Sec = Application Security (AppSec); Ops = DevOps / SRE; Data = Data & AI; CS = Support & Customer Success; Client = Client (Product Owner / sponsor)
Quality gate
Production stable after hypercare; handover record signed.
Entry criteria
- Release approval signed
- Go-live window approved by the client
- Latest production backup verified
Exit criteria
- Production runs the right version; smoke tests green
- Post-cutover data reconciliation matches
- Users and admins trained
- All accounts and keys handed over; client rotated credentials
- Hypercare ends with no open P1/P2 incidents; handover record signed
Activities
- 1.Go-live checklist: backup first, migrations, monitoring on, rollback plan
- 2.Run the rehearsed data cutover and reconcile afterwards
- 3.Train users & admins, record how-to videos
- 4.Hand over source code, accounts, keys, domains — transfer ownership
- 5.Close watch for the first 72 hours (hypercare)
Checklist
Tick to self-review — 0/5. Ticks stay in this browser only and are not sent anywhere.
Document templates
Markdown (.md) files: open in any editor, or paste into Word / Google Docs. Each states its purpose, who fills it in and when.
Client involvement
- Pick a low-impact go-live window
- Receive and rotate every handed-over credential
Tools
- Docker · CI/CD
- pg_dump / pg_restore
- Loom / OBS
- Bitwarden (chia sẻ bí mật)
Reference standards
- ITIL® 4 — Release & Deployment management
- Controlled release and deployment practices
- ISO/IEC/IEEE 12207:2017
- Transition process: moving the system into its operational environment
- Semantic Versioning 2.0.0
- Release numbering
Common pitfalls
- Going live on a Friday afternoon
- Handing over passwords in chat
- Forgetting to transfer domain / cloud account ownership
- Nobody on call after go-live
Real example
cuongthai.com, 18 Aug 2026: an image swap used the wrong Dockerfile (a musl base carrying a glibc Prisma engine) — green build, green push, green swap, then the API returned 502 for seven minutes. A libc ↔ engine check now runs before every push, and the runbook documents a fast roll-back: re-tag the previous image still on the host (about 40 seconds instead of a 15-minute rebuild). A green build does not mean a working image.
Where to learn
Subjects and courses on cuongthai.com that teach this stage’s work.