Software Handover Checklist: Own What You Paid For

A software handover is complete only when you hold the source code, the accounts, the credentials, the documentation, and the legal rights to all of it — and your team has proven it can deploy the system without the vendor on the call. If any one of those is missing, you have paid for software you do not actually own. This checklist walks you through exactly what to collect, verify, and sign off before you release the final payment.

Most Indian SMBs discover the gap two years later: the agency has shut down or gone silent, the domain renewal fails, and nobody knows the AWS password. At NexaEx we run every project through a formal handover protocol, and we built this checklist from the wreckage we have been called in to rescue — projects in Erode, Chennai, Bengaluru and abroad where the previous vendor left with the keys.

Why does software handover go wrong so often?

Because nobody budgets time for it. The last 5% of a project — transferring accounts, writing runbooks, walking the client's team through deployment — earns the vendor nothing extra, so it gets skipped unless the contract forces it. The client, meanwhile, is focused on launch, not on what happens when the relationship ends.

The second reason is structural: many agencies deliberately keep hosting, domains, and repositories in their own accounts. Sometimes it is laziness; sometimes it is a retention strategy. Either way, the effect is the same — you cannot leave, and every future change order is priced accordingly.

A proper handover reverses that power balance. Everything below should be in your accounts, under your email addresses, before the final invoice is settled. If you are still negotiating the engagement, read our companion piece on software development contracts in India — the handover clause belongs in the contract, not in a post-launch argument.

The master handover checklist

Use this as a literal sign-off sheet. Every row should be verified by someone on your side, not just claimed by the vendor.

Source code: the repository is not enough

Getting a ZIP file of code is not a handover. You need the live repository with its history, transferred to a GitHub or GitLab organisation registered to your company email. History matters: it is the record of what changed and why, and any future developer will rely on it.

Verify three things:

• It builds. A developer who has never seen the project should be able to clone it and run it using only the README. If that fails, documentation is incomplete — see below.
• It is current. Diff the repository against what is running in production. We have seen vendors hand over code three releases behind the live system.
• Nothing is hard-coded. API keys and passwords inside the code are both a security failure and a sign the .env handover will be messy.

Intellectual property: paper beats assumption

Under the Indian Copyright Act, 1957, code written by an independent contractor belongs to the contractor unless a written agreement assigns it to you. Paying for the work is not enough on its own. Your contract or handover letter must contain an explicit assignment of copyright in the deliverables to your company, and it should distinguish bespoke code (assigned to you) from the vendor's pre-existing libraries (licensed to you, perpetually and irrevocably). If your current contract is silent on this, fix it before final payment — you have maximum leverage exactly once.

Accounts and credentials: the part everyone fumbles

The rule is simple: anything that bills money or holds data lives in an account you control. In practice that means:

• Cloud hosting — the AWS/GCP/Azure/Vercel account root email is yours (use a role address like infra@yourcompany.in, not a founder's personal Gmail). The vendor keeps a scoped IAM user you can revoke.
• Domain registrar — your name, your card. Expired domains are the single most common way Indian SMBs lose their web presence; recovery through auction can cost ₹50,000+ for a contested .in or .com.
• Payment gateways (Razorpay, Cashfree, PayU) — these are KYC-bound to your company anyway; make sure the dashboard owner login is yours, not a vendor email added as owner.
• Communications — SMS DLT registration, WhatsApp Business API (via your Meta Business Manager), transactional email (SES/SendGrid) domains verified under your DNS.

After transfer, rotate every secret. The vendor had these credentials; post-handover, they should not work for anyone but you. Budget an hour of engineering time for rotation — it is the cheapest security control you will ever buy. Our security checklist for business software covers the rotation procedure and the DPDP Act obligations that make it non-optional.

Documentation: the three documents that matter

You do not need a 200-page manual. You need three short, current documents:

1. Architecture overview (2–4 pages). What the components are, how they talk to each other, and which third-party services are involved. A diagram plus a paragraph per component.
2. Deployment runbook. Step-by-step: how to deploy a change, how to roll back, how to restore the database from backup. Written so a competent developer who has never seen the system can follow it.
3. Admin manual. For your operations staff: user management, common tasks, what the error states mean, who to call.

The test of documentation is not reading it — it is using it. Which brings us to the step almost everyone skips.

What is a supervised deployment, and why should you insist on one?

A supervised deployment is a live exercise where your team (or an independent developer you hire for a day, ₹5,000–₹15,000 well spent) deploys the application from the repository to a fresh environment, using only the documentation, while the vendor watches but does not touch the keyboard. Every gap it exposes — a missing environment variable, an undocumented build step, a manual database tweak — gets fixed and documented on the spot.

This one exercise converts the handover from a pile of files into a proven capability. It typically takes half a day. No serious vendor refuses it; at NexaEx it is a standard line item in our delivery process, because it protects us as much as the client — nobody calls us at midnight a year later asking how the build works.

Structure the final payment around the checklist

Money is the only enforcement mechanism you have after the code is written. Structure the tail of the payment schedule accordingly:

• Hold back 10–15% of the project value against handover completion, released only when the checklist is signed off.
• On a ₹8,00,000 project, that is ₹80,000–₹1,20,000 — enough that finishing the handover is worth the vendor's time.
• Separate the warranty period (30–90 days of bug fixes, included) from AMC (ongoing support and updates, typically 15–20% of project value per year, ₹1,20,000–₹1,60,000 on that same project). Confusing the two causes most post-launch disputes.

If you are still scoping the build, our project cost calculator includes handover and warranty in its estimates — because a quote that omits them is not comparable to one that includes them.

Red flags that predict a bad handover

Watch for these during the engagement, not after:

• The staging site runs on the vendor's subdomain and the vendor's cloud account "for convenience".
• You ask for repository access mid-project and get excuses.
• The proposal has no line item for documentation or knowledge transfer.
• Licences for themes, plugins, or libraries are "included" but never itemised — meaning they are on the vendor's licence and will break when the relationship ends.
• The vendor resists a supervised deployment "because it will delay launch".

Any one of these is fixable with a conversation. Three or more, and you should be planning your exit while you still have payment leverage. Our case studies include two projects that came to us precisely because a previous vendor failed this list.

Talk to us

If you are approaching a handover — or inheriting a system from a vendor who has gone quiet — we can audit the handover, rescue the accounts, and get your team to a proven deployment. Contact us or message us on WhatsApp at +91 97912 97741; we reply within 24 hours.