Originally published at https://axentis.tech/software-project-handover-checklist/.
Most companies discover whether they really own their software at the worst possible moment: a vendor relationship ends, a key engineer leaves, or an investor's technical due diligence asks who can deploy to production tonight. If the honest answer involves "we would need to ask the agency", you have a handover problem, and it is far cheaper to solve at the start of an engagement than at the end.
This software project handover checklist is written for CTOs and founders in the US, UK, Canada and Australia who work with an outsourced team, including an India-based partner like us. It covers ownership of accounts and credentials, reproducible environments, the documentation worth insisting on, the contract basics, and how to run a handover session that proves your team can operate the system without the vendor in the room.
Why handover gets planned too late, and what that costs you
Handover is usually treated as the last line of the project plan. By then, the decisions that make it easy or painful have already been made: whose account the cloud resources sit in, whether environments were built by hand, and whether anything was written down. Typical consequences of a late handover include:
- Nobody on your side can deploy, roll back or rotate a credential.
- Production runs in an account billed to the vendor, so moving it becomes a migration project.
- Key knowledge lives in two engineers' heads, and the next team spends its first weeks reverse-engineering decisions.
- Domains, app store listings or payment accounts are registered to the wrong legal entity.
None of these are dramatic on day one. All of them become expensive the day you need to move quickly.
Ownership from day one: repositories, cloud accounts, domains and credentials
The simplest rule: anything your product depends on should be created in your company's name, with the delivery team added as collaborators whose access you can remove.
| Asset | Who should own it | What to check |
|---|---|---|
| Source code repositories | Your organisation | Vendor engineers are members you can remove; no "real" copy lives elsewhere. |
| Cloud and hosting accounts | Your company, on your billing | At least two people on your side have administrator access. |
| Domains and DNS | Your company's registrar account | Renewal contact and payment are yours. |
| App store developer accounts | Your legal entity | A mobile MVP release slice is distributed through your own TestFlight or Google Play Console account. |
| Third-party services (email, payments, analytics, error tracking, AI model providers) | Your company | API keys are issued from your accounts, not shared from the vendor's. |
| Secrets and credentials | Your secrets manager or vault | Nothing sensitive in code, chat history or CI logs. |
| CI/CD pipelines | Your organisation | Pipeline definitions live in the repository, not only in a vendor-run tool. |
If you inherit a project where this was not done, the first handover task is moving each asset into your ownership, one at a time, with a rollback plan for each move.
Infrastructure as code and reproducible environments
An environment that was built by clicking through a cloud console can only be rebuilt by the person who clicked. Ask for infrastructure defined as code (Terraform, OpenTofu, Pulumi or the cloud provider's own templates), committed to your repository and applied through a pipeline.
Alongside that, expect:
- Environment configuration kept in code, with secrets referenced from your vault rather than pasted in.
- A README that gets a new engineer from a fresh laptop to a running local copy, including seed or sample data.
- Automated tests and build steps that run in CI on every change.
- Separate staging and production environments, created from the same definitions.
The real test is simple: can an engineer who has never seen the project stand up a working staging environment using only the repository and the docs? If you want help reaching that standard, it is core work for our DevOps and SRE services.
Documentation that matters: architecture notes, runbooks, decision logs
Long documents nobody reads are not the goal. Short, current documents that a new engineer actually uses are.
Architecture overview
One or two pages: the main components, how data flows between them, external dependencies and where each piece is hosted. A simple diagram is enough.
Runbooks
Step-by-step instructions for routine and stressful tasks: deploying, rolling back, rotating a secret, restoring a backup, scaling a service and responding to the most likely alerts.
Decision log
Brief records of significant technical decisions and why they were made. These save the next team from undoing choices that had good reasons.
Known issues and technical debt
An honest list of open bugs, shortcuts and areas that need attention. A partner who hands this over freely is a partner you can trust.
For AI features, add the prompts and configuration, model versions, the evaluation set, the design of the human review and approval step, and the usage limits in place. That mirrors what we recommend in how to scope an AI pilot.
Code ownership in outsourced development: the contract basics
Technical ownership needs a legal match. Before work starts, confirm with your own counsel that the contract covers:
- IP assignment of work product to your company on payment, or on terms agreed in writing.
- Pre-existing vendor components, such as internal libraries, and the licence you receive to keep using them.
- Open-source dependencies, with an inventory of licences so there are no surprises in later due diligence.
- Exit terms: what the vendor delivers at the end, how access is revoked and what happens to any copies of your data.
This is a checklist, not legal advice. The point is to raise these terms before kickoff, not after a disagreement.
The handover session: walkthroughs, a supervised first deploy, open issues
Documents are necessary but not sufficient. Knowledge transfer from an outsourcing vendor should include hands-on proof that your team can operate the system:
- Recorded codebase walkthrough. The vendor's tech lead walks your engineers through structure, key flows and tricky areas, and the recording is stored with the docs.
- Supervised first deploy. An engineer from your side runs a production deploy while the vendor watches and only advises.
- Rollback and restore rehearsal. Roll back a release and restore a backup to a non-production environment, following the runbooks.
- Credential rotation. Rotate shared secrets and remove access that is no longer needed.
- Open issues review. Walk through the known-issues list and agree who handles what.
- Support window. Agree a short, defined period in which the vendor answers questions after handover.
Software project handover checklist
| Area | Done when |
|---|---|
| Repositories | Owned by your organisation; vendor access removable. |
| Cloud, domains, app stores, third-party services | All in your company's name and billing. |
| Secrets | In your vault; rotated at handover. |
| Infrastructure | Defined as code; staging rebuilt from the repository. |
| Documentation | Architecture overview, runbooks, decision log and known-issues list are current. |
| Contract | IP assignment, vendor components, open-source licences and exit terms confirmed. |
| Operation | Your engineer has deployed, rolled back and restored a backup. |
| Support | Post-handover support window and contact agreed in writing. |
If any row is incomplete, you have not finished handover yet.
Scaling after handover: in-house, extended engagement or hybrid
A clean handover gives you real choices. You can take the product in-house, extend the engagement with another scoped piece of work, or run a hybrid where your engineers own the core and a partner delivers defined workstreams. Our comparison of staff augmentation vs project outsourcing can help you pick the model for the next phase.
How Axentis builds handover into a Launch Pilot
We design every Launch Pilot to end with the checklist above already satisfied: client-owned repositories and accounts from day one, infrastructure as code where the scope includes environments, short practical documentation and a handover session in which your team runs the deploy. That is why a pilot is a useful test of any partner; our guide to paid pilot projects explains what else to watch. The same standard applies to our custom software development engagements.
FAQ
When should handover planning start?
At kickoff. Account ownership, infrastructure as code and documentation habits are set in the first week. Leaving them to the end turns a routine handover into a migration project.
What should knowledge transfer from an outsourcing vendor include?
An architecture overview, runbooks, a decision log, a known-issues list, a recorded codebase walkthrough and a supervised deploy by your own engineer, followed by a short, defined support window.
How do I avoid vendor lock-in with an outsourced team?
Own every account and credential from day one, require infrastructure as code, put IP assignment and exit terms in the contract, and rehearse a deploy and rollback by your own team before the engagement ends.
Who should own the app store accounts for a mobile MVP?
Your company. Create the Apple Developer and Google Play Console accounts under your legal entity and add the vendor as users, so tester builds and any later public release stay under your control.
Ready to start with handover built in?
If you want an outsourced build that ends with your team holding the keys, discuss a Launch Pilot with Axentis. We will scope one bounded outcome with you privately and agree the handover standard before any code is written. If you are taking over an existing codebase and want a second opinion first, talk to an expert.
If you are planning a first engagement, see how a scoped Launch Pilot from Axentis works, or read more product and engineering notes on the Axentis blog.
Top comments (0)