Runbook 02 · Service adoption

Hand off the service, not the mystery

A practical acceptance checklist for inherited applications, vendor-run systems, and services that have outlived their original maintainer.

RB–02 / v1.0Output: Signed handoff packetPrint-friendly

Done means: a new operator can deploy, restore, observe, escalate, and pay for the service without depending on the departing maintainer's memory.

1. Ownership and access

  • Name the business owner, technical owner, incident contact, and budget owner.
  • List every production account, organization, tenant, repository, domain registrar, cloud, CI, monitoring, and vendor portal.
  • Move shared access into an approved password manager; remove personal accounts and unknown recovery emails.
  • Confirm multi-factor authentication, break-glass access, and the process for offboarding.

2. System map

  • Draw the primary request path from user to response, including DNS, edge, app, data store, queues, and critical vendors.
  • Mark trust boundaries, public endpoints, scheduled jobs, and places data is copied.
  • Record environments, regions, runtime versions, and end-of-life dependencies.
  • Identify the smallest user journey that proves the service is alive.

3. Deploy and rollback

  • Run the documented build from a clean checkout.
  • Deploy a harmless, visible change through the real production path.
  • Prove rollback or roll-forward with explicit stop conditions.
  • Record migrations, feature flags, secrets, approvals, and who can bypass them.

4. Data, backups, and recovery

  • Inventory data stores, retention, encryption, residency, and deletion obligations.
  • Record backup schedule, retention, location, ownership, and alerting.
  • Restore into an isolated environment and verify usable records—not merely a successful backup job.
  • Write the recovery point and recovery time the business actually accepts.

5. Monitoring and incident readiness

  • Test the primary journey from outside the service.
  • Route every urgent alert to a named rotation or owner.
  • Remove alerts with no action and document silence/escalation rules.
  • Run a tabletop failure and confirm the incident log, status channel, and vendor escalation path.

6. Vendor and security due diligence

  • List contracts, renewal dates, payment methods, usage limits, data-processing terms, and exit/export paths.
  • Rotate inherited credentials and review active users, API keys, webhooks, OAuth apps, and certificates.
  • Record known vulnerabilities, audit findings, unsupported software, and accepted risks with an owner and review date.
  • Verify domain, TLS, email, and code-signing renewals cannot fail silently.

Acceptance record

Service:
Business owner:
Technical owner:
Handoff date:

[ ] Access transferred and personal accounts removed
[ ] Clean build completed
[ ] Production deployment completed
[ ] Rollback or roll-forward proven
[ ] Backup restored and checked
[ ] Primary user journey monitored
[ ] Vendor/security risks recorded

Open risks | Owner | Due date | Evidence of closure
-----------|-------|----------|--------------------
           |       |          |

Accepted by:
Accepted with exceptions:

Adopting an orphan application?
Hoyack can scope the stabilization and ownership transfer.

Request a review