A database handover is easy to declare and hard to finish. Handing over a database works when the receiving team can operate, restore, and change it without a private call to the previous owner.
Define What Handing Over a Database Transfers
List the database, instance, environments, applications, owners, scheduled jobs, integration points, backup destinations, and security dependencies. Include the database’s business purpose and peak usage windows. A handover note that contains only server name and connection string leaves the hard questions unanswered.
I begin with a boundary check. Does the team receive responsibility for the SQL instance, one database, or the full application data path? Which alerts and approvals move with that responsibility? State the effective date and the person who accepts it. Without that line, incidents can bounce between teams while the database waits.
Capture Current State
Save the database options, compatibility level, collation, file layout, recovery model, high availability configuration, and known capacity limits. Record the source and time of each snapshot. A diagram should match current reality, not the server layout from the last migration. List recent changes that can explain near-term behavior.
This query gives a first database inventory. It does not include jobs or external dependencies, so pair it with the operational map. I use it to catch a database left out of the handover list.
SELECT name, state_desc, recovery_model_desc,
compatibility_level, collation_name
FROM sys.databases
WHERE database_id > 4
ORDER BY name;Transfer Recovery Knowledge When Handing Over a Database
Provide backup schedules, retention rules, storage locations, encryption key custody, and recent restore-test results. Demonstrate a restore to an isolated environment with the receiving team. The exercise should include an integrity check and application validation. A backup job success report is not enough evidence for taking responsibility.
I ask the receiving DBA to choose the files for one recovery point without help. That reveals missing log chain information quickly. Which person can authorize a restore that overwrites data? Put that approval path in the runbook. Recovery is the part of handing over a database that deserves a rehearsal, not just a document attachment.
Move Access and Alerts
Grant named access to the receiving team through the standard process. Test read-only diagnostic rights and change rights separately. Transfer monitoring ownership, paging rules, and incident channels. Remove old access only after the new path has been tested and the support period is agreed. Avoid leaving a shared administrator account as a shortcut.
I check who receives a backup failure alert before and after transfer. An alert that still pages the previous team can create a quiet gap if nobody responds. Also verify that the new team can reach file shares, backup keys, and support contacts. SQL permission alone is not operational access.
Review Jobs and Dependencies
Inventory SQL Server Agent jobs, external schedulers, ETL processes, linked servers, reports, and applications that read or write the database. Include run times and owners. A job can be disabled intentionally, so note that rather than re-enabling it during cleanup. Check whether service accounts and credentials are controlled by the receiving team.
The query below lists Agent jobs for a first review on editions with SQL Server Agent. It does not show Windows Task Scheduler or external services. I compare it with the runbook and ask about every unexplained job.
SELECT name, enabled, date_created, date_modified
FROM msdb.dbo.sysjobs
ORDER BY name;List Open Risks and Changes
Give the receiving team current incidents, technical debt, pending deployments, certificate expirations, capacity concerns, and accepted exceptions. For each item, name the owner and next action. Do not hide an unresolved issue to make the transfer appear clean. The point is to move knowledge with responsibility.
I keep the risk list short and evidence based. A vague warning that performance is bad helps nobody. Name the query, time window, symptom, and current evidence. Which item needs action during the overlap period? Address it together so the new team sees the decision process.
Keep a Support Overlap After Handing Over a Database
Agree on a support period when the previous team can answer questions and join a real incident. Define response expectations and an end date. During the overlap, the receiving team leads routine checks and changes while the previous team observes. That is the quickest way to find gaps in runbooks and access.
I close the handover with an acceptance review. Can the new team restore a backup, explain the application path, respond to an alert, and deploy a safe change? If not, list the missing pieces and keep ownership explicit until resolved. A signed checklist should describe readiness, not conceal unfinished work.
Handing over a database should include a recovery walkthrough, not only an architecture diagram. Ask the receiving team to restore a backup in a safe location and explain where log backups, keys, credentials and application connection details are managed. I prefer a live exercise with notes over a long document that nobody has used. The receiving team should know the last known good restore point and the process for declaring an incident.
Record open changes and known exceptions separately from stable design. A performance issue under investigation, a scheduled migration and a temporary configuration value each need an owner and date. Otherwise the new team can inherit an ambiguous state and call it normal. Include contact paths for the application, infrastructure and data owners.
During the overlap period, let the receiving team drive routine tasks while the outgoing team observes. Confirm that alerts route to the correct people and that a failed job produces an actionable response. Handover is complete when the new team can operate the database, not when the last attachment is uploaded.
The final handover meeting should include a small incident drill. Give the receiving team a failed backup alert or a blocked deployment scenario and let them locate the runbook, owner and next action. I watch where they pause. Those pauses reveal missing links in the handover package. Fix them before the overlap ends. A signed document cannot replace the confidence that comes from using the process once.
Related reading on this blog: Get Last Restore Date and Full, Differential and Log Backups: A Practical Guide.
A database handover is not a change of names on a chart, it is a transfer of tested operating knowledge.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
