A database handover is not complete when a document is delivered. It is complete when the receiving team can operate the environment, respond to an incident, explain the important dependencies, and make a controlled change without depending on the person who left.
This checklist is designed for CTOs, technical managers, IT service firms, and incoming database teams taking responsibility for a production estate. It works for a planned transition, but it is especially useful when a key developer or database owner leaves with incomplete documentation or limited knowledge transfer.
Start by defining the transfer of responsibility
Name the outgoing owner, receiving owner, business sponsor, technical escalation contact, and decision maker for production changes. Record the effective date of the transfer and separate three states: information received, information verified, and responsibility accepted. A credential list or architecture diagram may be received without proving that it is current or usable.
Agree what the receiving team owns. Database administration can include availability, performance, backups, security, patching, scheduled jobs, data integrations, reporting refreshes, vendor coordination, and migration support. If any responsibility remains elsewhere, name that owner and the handoff between teams.
Database handover checklist
| Area | What to collect and verify | Acceptance evidence |
|---|---|---|
| Ownership | Business owner, technical owner, support coverage, escalation contacts, vendors, and responsibility boundaries. | Every production system and critical process has a named accountable owner. |
| Inventory | Database engines, versions, hosts, clusters, cloud accounts, regions, environments, and lifecycle status. | The inventory matches discovered infrastructure and connection endpoints. |
| Architecture | Primary and replica topology, network paths, storage, failover, integrations, data flows, and dependent applications. | The receiving team can trace a critical transaction or data flow end to end. |
| Access | Administrative access, service accounts, break-glass procedure, secrets storage, VPN, bastions, MFA, and approval process. | Approved team members can access each environment without using personal or shared credentials improperly. |
| Workloads | Critical queries, scheduled jobs, ETL processes, maintenance tasks, peak windows, batch deadlines, and resource limits. | A complete operating cycle is observed and its failures are understood. |
| Monitoring | Dashboards, alerts, thresholds, on-call routing, noisy signals, log locations, and normal performance baselines. | A test or recent alert can be traced from detection through response and closure. |
| Backups | Backup types, schedules, retention, encryption, storage, replication, recovery objectives, and restore procedure. | Recent backup status is checked and restore evidence exists for a representative system. |
| Incidents | Recent outages, recurring failures, unresolved actions, emergency changes, post-incident reviews, and stakeholder communications. | Known failure patterns and first-response actions are documented. |
| Changes | Release process, migration scripts, approvals, maintenance windows, deployment tools, validation, and rollback. | The team can explain and rehearse the next planned production change. |
| Security | Data classification, encryption, audit logs, privileged roles, access reviews, vulnerabilities, and compliance obligations. | High-risk access and unresolved security exceptions have owners and deadlines. |
| Reporting | Dashboards, semantic models, refresh jobs, KPI definitions, reconciliation controls, deadlines, and report owners. | Critical reports can be traced to source data and their refresh failures can be diagnosed. |
| Risks | Capacity limits, end-of-life components, manual workarounds, single points of failure, technical debt, and undocumented dependencies. | Each material risk has impact, likelihood, owner, and an agreed next action. |
1. Build an inventory that matches reality
Collect existing inventories, diagrams, cloud exports, configuration repositories, monitoring targets, and connection records. Then reconcile them. Look for databases that appear in application configurations but not in the official inventory, jobs running under personal accounts, abandoned replicas, old environments that still receive traffic, and systems with unclear business ownership.
For each database, record its purpose, engine and version, environment, hosting location, criticality, data sensitivity, recovery expectations, upstream sources, downstream consumers, and current support owner. Mark facts that were discovered technically versus statements that still require confirmation.
2. Transfer access without creating new risk
Do not exchange passwords in a handover spreadsheet. Use the approved secrets manager and access process. Confirm how administrators reach private networks, where privileged credentials are stored, how emergency access is approved, and which accounts are tied to the departing person.
Rotate credentials when ownership changes, but sequence the work carefully. A service account can be embedded in jobs, applications, monitoring, backup agents, or vendor integrations. Inventory its use, create a rollback plan, make the change during an appropriate window, and verify every dependency afterward.
3. Observe the operating cycle
A static document rarely captures what actually happens during daily, weekly, and month-end operations. Observe at least one meaningful cycle. Review scheduled jobs, backups, maintenance, reporting refreshes, file arrivals, data quality checks, capacity patterns, and manual interventions.
Ask which tasks fail frequently, which alerts are ignored, which jobs must finish before a business deadline, and which procedures exist only in one person's memory. Record the expected start time, completion signal, normal duration, dependencies, failure behavior, retry rule, and escalation owner for every critical process.
4. Verify monitoring and incident response
List the tools used for infrastructure, database, application, job, and data-pipeline monitoring. Establish a normal baseline for availability, latency, connections, CPU, memory, storage, replication lag, lock waits, deadlocks, job duration, and backup status where relevant. Thresholds without context are not enough; the receiving team must know what action each important alert requires.
Review recent incidents and unresolved follow-up actions. Capture how severity is assigned, who communicates with stakeholders, who can authorize an emergency change, and how evidence is preserved for a post-incident review. A useful runbook begins with diagnostic checks and decision points, not a long list of commands with no explanation.
5. Prove backup and recovery readiness
A successful backup job is not proof that the database can be recovered. Confirm backup scope, frequency, retention, encryption, storage location, cross-region or off-site protection, and the recovery point and recovery time expected by the business. Identify who can initiate a restore and where it can be performed safely.
Review recent restore evidence or perform a controlled restore test when risk and access permit. Validate that the restored data is usable, required encryption keys and credentials are available, dependent applications can reconnect, and the team knows how to communicate recovery status. Record gaps as operational risks rather than treating them as documentation issues.
6. Map reporting and integration dependencies
Database responsibility often extends beyond the application itself. A schema change, delayed ETL job, or overloaded replica can affect dashboards, KPI packs, customer reports, finance processes, and data exports. Record critical consumers, refresh windows, service expectations, and the person who decides whether late or incomplete data is acceptable.
Trace critical reports from their visible metric back through semantic models, transformations, jobs, and source tables. Capture reconciliation checks and known differences between operational and reporting definitions. This prevents the incoming team from fixing a technical symptom while breaking a business reporting commitment.
7. Record known risks and planned changes
Separate current operating risks from future improvement ideas. Current risks include unsupported versions, storage pressure, missing restore evidence, unmonitored jobs, weak privileged-access controls, single points of failure, and undocumented manual procedures. Give each risk an impact, likelihood, evidence, owner, and next review date.
List upcoming releases, migrations, certificate renewals, contract dates, maintenance windows, capacity events, and audit deadlines. Include the change owner, validation plan, rollback trigger, and required approvals. An incoming team should not discover a major production change from a calendar invitation after responsibility has transferred.
When the previous owner is unavailable
When there is no cooperative handover, switch from transfer mode to controlled recovery. The immediate objective is continuity, not optimization. Secure access, preserve logs and configuration, inventory the estate, verify backup and monitoring status, identify critical business deadlines, and freeze avoidable changes until the environment is understood.
- Stabilize ownership: establish technical and business decision makers, communication channels, and emergency authority.
- Protect access: recover approved administrative paths, disable inappropriate personal access, and preserve break-glass capability.
- Discover dependencies: inspect application configurations, job schedulers, monitoring, infrastructure, repositories, and reporting tools.
- Verify protection: check active alerts, backup completion, replication, storage headroom, and near-term operational deadlines.
- Observe before changing: watch routine workloads and document behavior before tuning, upgrading, or restructuring.
- Maintain an unknowns register: make uncertainty visible, prioritize it by business risk, and close it with evidence.
Acceptance criteria for the receiving team
Use a formal acceptance review instead of assuming that elapsed time means the handover is finished. The receiving team should be able to demonstrate the following:
- Access to every in-scope environment through approved, auditable paths.
- A reconciled inventory and architecture view with named system owners.
- Understanding of critical workloads, integrations, reporting deadlines, and normal operating patterns.
- Ability to interpret priority alerts and follow incident and escalation procedures.
- Verified backup status and credible restore evidence.
- A controlled process for releases, schema changes, maintenance, validation, and rollback.
- A risk register covering unresolved gaps, owners, priorities, and next actions.
- Completion of a real operating cycle without depending on the outgoing owner.
Frequently asked questions
What should be included in a database handover?
A database handover should include system ownership, environments, architecture, access procedures, privileged accounts, integrations, scheduled jobs, monitoring, backups, restore evidence, incident history, change procedures, reporting dependencies, vendor contacts, known risks, and an agreed acceptance process.
How long should a database operations handover take?
A focused handover for a well-documented environment may take several days. A business-critical estate with multiple databases, undocumented jobs, weak access control, or missing restore evidence can require several weeks of discovery, observation, remediation, and validation.
What if the previous database owner is unavailable?
Treat the transition as a controlled recovery. Secure administrative access, inventory systems and dependencies, preserve current operations, verify backups and monitoring, observe scheduled workloads, interview adjacent teams, document unknowns, and avoid nonessential changes until the environment is understood.
How do you know a database handover is complete?
The handover is complete when the receiving team can access each environment, explain ownership and dependencies, operate routine jobs, respond to alerts, restore from backup, follow change and escalation procedures, identify known risks, and support a real operating cycle without relying on the departing owner.
Recover ownership before the gap becomes an outage. Datrick can inventory the estate, restore operational access, map dependencies, verify monitoring and backups, build runbooks, and establish a support model when a key database owner leaves.
Request a database handover assessment