Agree what is being handed over
Define the product, release, environments and responsibilities included. State whether the receiving team will operate, maintain, extend or only own the commercial relationship.
Separate launch acceptance from handover acceptance. A feature can be live while operational ownership is still incomplete.
Repository and build process
Transfer the source repositories with appropriate access and ownership. Identify the default branch, release tags, dependency or package registries and the supported build process.
The receiving team should be able to make a small change, run checks and produce a deployable build without relying on one departing developer's machine.
Hosting, cloud and environments
List development, staging and production services, including regions, plans, quotas and billing ownership. Record how environments are created, configured and accessed.
Include deployment pipelines, release approvals, scheduled jobs, storage and CDN configuration. Link to the advanced go-live readiness checklist if the handover follows a complex production release.
Domains, certificates and credentials
Transfer registrar, DNS, certificate and email-service ownership. Confirm renewal dates, billing contacts and recovery methods.
Move credentials through a secure password or secret-management process. Do not place passwords or production keys in the handover document. Remove access that is no longer required after the receiving team verifies its own.
Documentation and architecture
Provide a concise system overview: major components, data flows, integrations and the decisions that are difficult to infer from code. Include setup, deployment, rollback, backup and recovery instructions.
Prioritise documentation that supports real actions. An outdated architecture diagram is less useful than a tested restoration procedure.
Integrations, analytics and third-party accounts
List vendors, APIs, webhooks, analytics, consent tools, email, payments and support platforms. Record account owner, purpose, plan, renewal, limits and support contact.
Verify that notifications and reports reach current addresses. Remove personal accounts or explain the approved transition plan.
Known issues and technical debt
Share open defects, workarounds, monitoring gaps and deliberate trade-offs. For each item, record impact, priority, owner and any deadline or trigger.
Hiding technical debt does not make the handover cleaner. It makes the receiving team's first incident harder.
Backups, recovery and monitoring
Confirm what is backed up, how often, where it is retained and who can restore it. Test access to the backup and, for critical systems, evidence that restoration works.
Transfer dashboards, alerts, logs, incident contacts and escalation paths. Define when the previous team stops monitoring and the new team starts.
Maintenance and support responsibilities
Agree who handles incidents, security updates, dependency maintenance, content changes, small improvements and vendor renewals. Define response expectations and any warranty or support period.
Close the handover with a live walkthrough and an owned action list. Use the go-live checklist guide to confirm production readiness and the project readiness checklist when the receiving team plans the next delivery phase.