Agency-to-In-House Engineering Handover Checklist for Founders
Transfer code, cloud, releases, security, data and operating knowledge in an agency handover. KUMO provides full IP transfer from day one. Get 8 checks.
Aug 2, 2026
Agency-to-In-House Engineering Handover Checklist for Founders
A founder should sign off an agency handover only after the incoming owner passes 8 acceptance tests: build, release, observe, restore, access, data, documentation, and incident response. A folder of source code is not a handover. The business must be able to operate and change the product without a hidden dependency on the outgoing agency.
This checklist begins after agency offboarding has been agreed. It is for a founder, COO, product leader, or incoming engineering owner taking control of repositories, cloud, CI/CD, secrets, architecture records, runbooks, and production responsibility. It does not cover choosing an agency or onboarding one. Those decisions belong in the software product development agency checklist and the first-month agency guide.
If ownership is split across people and vendors, Map the first build milestone around the transfer risks that block a safe release.
Define handover acceptance before the agency exits
Set a written handover window, named outgoing owner, named incoming owner, and acceptance date. List every production system and the evidence required for sign-off. Payment or contract closure should follow the agreed acceptance process, not the delivery of a shared drive.
Use this operating definition: handover is accepted when the incoming owner can build, release, observe, restore, and change access using company-controlled accounts and current records. If the incoming team can only do those tasks while the outgoing agency is on a call, the transfer is still in progress.
KUMO provides full IP transfer from day one. The practical buyer test is broader than an IP clause. It asks whether the company controls the code, accounts, data, release path, records, and operating decisions needed after the agency leaves.
The 8 agency handover acceptance tests
Run these tests in a non-production environment first, then perform the agreed production-safe checks. Record the person who ran each test, the evidence produced, any exception, and the date it will be closed.
| Acceptance test | Incoming owner must demonstrate | Evidence to retain | Block sign-off when |
|---|---|---|---|
| 1. Build | Clone the repositories, install dependencies, configure a clean environment, and produce a valid build | Repository list, setup steps, dependency lockfiles, build log | The build needs an undocumented machine, personal account, or manual file |
| 2. Release | Deploy an approved change through the real CI/CD path with rollback available | Pipeline run, approval record, release notes, rollback result | Only the outgoing agency can release or approve production |
| 3. Observe | Find service health, logs, metrics, traces, alerts, and business-critical workflow status | Dashboard links, alert routes, sample diagnosis | Alerts reach a former contractor or no one can connect symptoms to systems |
| 4. Restore | Restore a defined backup or recover a service using the documented procedure | Backup inventory, restore log, recovery decision, validation result | Backups exist but have not been tested or credentials are missing |
| 5. Access | Add the incoming owner, verify role boundaries, remove test access, and identify privileged accounts | Access matrix, MFA status, owner list, revocation record | Shared credentials, personal email accounts, or unknown administrators remain |
| 6. Data | Identify systems of record, data flows, retention, exports, deletion paths, and recovery ownership | Data map, schema notes, retention policy, export test | The business cannot export or recover its data independently |
| 7. Documentation | Use current architecture records and runbooks to make a bounded change without oral guidance | Architecture map, decision records, runbook result, known limits | Documents describe an old system or omit critical operating steps |
| 8. Incident response | Triage a realistic failure, assign roles, communicate status, contain impact, and recover | Scenario, timeline, role record, recovery evidence, follow-up actions | No one owns command, communication, diagnosis, or recovery |
The GitHub repository transfer guide notes that a new repository owner can administer contents, issues, pull requests, releases, projects, and settings. Use that as a reminder to transfer the working history and administration boundary, not just a code archive.
Transfer company ownership of code and delivery systems
Create an inventory before changing access. Include application repositories, infrastructure code, automation scripts, package registries, container registries, CI/CD projects, deployment services, app-store accounts, domains, certificates, feature flags, monitoring, error tracking, support tools, analytics, and vendor consoles.
For each item, record the company account, current administrator, incoming owner, authentication method, billing owner, recovery method, and removal date for outgoing access. Transfer repositories into company-controlled organizations where the platform supports it. Preserve issues, pull requests, releases, branch rules, environments, webhooks, and deployment keys.
Do not rotate everything blindly at the start of the window. First map which secret serves which workload, how it is deployed, and what will fail when it changes. Then rotate or revoke in a sequenced plan with a test and rollback boundary. The OWASP Secrets Management guidance emphasizes centralized storage, provisioning, auditing, rotation, and management of secrets. It also notes that manual key rotation is difficult and can cause mistakes.
AWS recommends temporary credentials for human users and workloads, with roles used where possible. Review the AWS IAM security practices when the handover includes AWS accounts, CI/CD workloads, or long-lived access keys. The same ownership principle applies on other platforms: the company controls the account, named roles receive only necessary access, and former access can be revoked without breaking production.
Make architecture and data records usable
A useful architecture record explains how the product works today. It should show user entry points, services, databases, queues, storage, third-party integrations, environments, trust boundaries, scheduled jobs, deployment path, monitoring, and recovery dependencies. Add decision records for choices the incoming team is likely to question, including known constraints and work intentionally deferred.
The data handover should identify the source of truth for each important record, how identifiers match across systems, where personal or sensitive data moves, how long data is retained, and how exports, corrections, deletion, backup, and restore work. Include sample records with sensitive values removed when they help the incoming team understand edge cases.
Do not treat a diagram as proof. Ask the incoming owner to trace one customer or operational workflow from entry through processing, storage, integration, output, alerting, and recovery. Any unexplained step becomes a handover action.
Prove the release and rollback path
The incoming owner should release one bounded change through the same path used for normal production delivery. The exercise should cover code review, automated tests, artifact creation, environment configuration, approval, deployment, verification, monitoring, and rollback or forward repair.
NIST's Secure Software Development Framework provides practices intended to reduce vulnerabilities in released software, reduce the impact of vulnerabilities that remain, and address root causes. During handover, use that lifecycle view to check whether secure development and release responsibilities have a named owner after the agency leaves.
Record the release freeze, open defects, failed tests, dependency risks, security exceptions, migration status, and known manual steps. If the product is unstable or the agency relationship ended during a delivery failure, use the software project rescue plan before accepting a normal handover schedule.
Once the eight tests have owners and dates, Map the first build milestone around the gaps that must close before the next safe release.
Transfer incident and support ownership
List current support commitments, severity definitions, escalation channels, response responsibilities, and customer communication rules. Transfer open incidents, recurring alerts, workarounds, known failure patterns, and the people or vendors needed during recovery.
Google's Incident Response chapter separates resolving an incident from managing it. Resolution mitigates impact or restores service. Management coordinates responders and communication. Test both sides during handover: someone must diagnose and recover the system, while someone owns command, updates, and decisions.
Run one incident simulation based on a credible product failure. Examples include an expired credential, failed payment callback, unavailable dependency, delayed queue, database capacity issue, broken release, or corrupted import. The incoming team should identify the signal, assess impact, contain the issue, choose a recovery path, communicate status, and create follow-up actions.
Post-launch operating cost begins where the handover ends. Use the software maintenance cost after launch guide to assign budget for support, security, infrastructure, releases, observability, recovery, and ongoing ownership.
Use a copyable handover sign-off record
Create one row per system or acceptance test. Keep it in a company-controlled workspace and link the evidence rather than pasting credentials into the record.
| Field | What to record |
|---|---|
| Scope item | Repository, service, account, data store, pipeline, runbook, or acceptance test |
| Current owner | Named person and organization responsible before transfer |
| Incoming owner | Named person responsible after transfer |
| Company-controlled account | Organization, tenant, billing account, or admin boundary |
| Acceptance action | Build, release, observe, restore, revoke, export, diagnose, or change |
| Evidence | Link to log, runbook result, access record, release, restore, or decision |
| Exception | Missing item, risk, temporary dependency, and business impact |
| Due date | Date the exception must close |
| Sign-off | Incoming owner, founder or product owner, and date |
Keep an exception register beside the sign-off record. Every exception needs a risk statement, temporary control, owner, due date, and consequence if it remains open. Do not hide unresolved access, backup, security, or release risk inside a general note.
The in-house versus outsourced software development guide is the better page when the buyer is still deciding the future team model. This article owns the later transition decision, after offboarding begins and responsibility must move to a named internal owner.
The Volopay case study is the approved proof route for reviewing KUMO's founder partnership and product engineering involvement. It is implementation evidence, not proof that every agency handover has the same scope, duration, or outcome.
FAQ
What should an agency handover include?
It should include company control of repositories, cloud and vendor accounts, CI/CD, environments, secrets, data, architecture records, runbooks, monitoring, backups, incident responsibilities, open risks, and support commitments. Acceptance should require the incoming owner to perform the eight operating tests, not merely confirm that files were received.
Who should sign off the engineering handover?
Use at least three named roles: the outgoing technical owner confirms what was transferred, the incoming engineering owner demonstrates operating control, and the founder or product owner accepts business risk and open exceptions. Security, finance, legal, or data owners may also approve their specific boundaries.
When should agency access be removed?
Remove access according to a sequenced revocation plan after replacement access works and dependencies are understood. Privileged personal accounts, shared credentials, unknown administrators, and unused keys should not remain. Emergency or transition access needs a named owner, reason, expiry, and audit trail.
How long should a software handover take?
There is no defensible universal duration. The window depends on system count, documentation quality, release complexity, access ownership, open incidents, and the incoming team's readiness. Set the date from the acceptance inventory and tested dependencies, then track exceptions openly.
What if the incoming team cannot deploy or restore the product?
Do not sign off that acceptance test. Record the failure, business impact, missing dependency, temporary control, responsible owner, and retest date. If multiple tests fail because the system is unstable or undocumented, shift to a bounded rescue and stabilization scope before resuming the handover.
Leave with operating control, not a file transfer
A safe agency handover ends with demonstrated control. The incoming owner can build, release, observe, restore, manage access, explain the data, use current records, and respond to an incident. The founder can see every exception and the business no longer depends on hidden knowledge or personal accounts. Map the first build milestone around the transfer gaps that stand between the current system and accountable in-house ownership.
