Is handing over a ZIP of the source code enough?
Usually not. Verify version history, locked dependencies, database scripts, configuration, builds and deployment, account access, and a reproducible working result.
How to Agree on Software Project Changes and Source-Code Handover
Summary: Software projects can lose scope between “already approved” and “just one more adjustment.” Source-code delivery can also be mistaken for sending a ZIP file at the end. A more reliable approach is to establish a requirements baseline, change log, and version mapping, then verify source code, data, configuration, accounts, documents, and deployability at each milestone.
Establish a traceable requirements baseline first
At a minimum, the baseline covers business goals, user roles, key workflows, pages and features, data APIs, permissions, deployment environment, deliverables, and acceptance conditions. Record a version number, approval date, and approvers. Later discussions should identify the exact item and baseline version being changed instead of referring vaguely to “what we discussed before.”
A change request should answer five questions
- Why change: business, data, compliance, technical constraints, or user feedback?
- What changes: pages, workflows, fields, APIs, permissions, deployment, or acceptance criteria?
- What is affected: cost, schedule, test scope, historical data, compatibility, or maintenance?
- Who approves: requestor, business owner, technical lead, and project manager?
- Which release: the current phase, next phase, pilot, or deferred?
Define defect fixes, implementation adjustments within agreed scope, and new requirements in the project agreement. Do not classify them solely by how one party describes the request.
What should source-code handover cover?
| Category | What to verify | Acceptance method |
|---|---|---|
| Code repository | Frontend and backend, scripts, branches, tags, commit history, and access rights | The designated account can clone the full history |
| Dependencies and builds | Dependency list, lockfiles, runtime versions, and build commands | Build succeeds in a clean environment |
| Database and files | Schema, migrations, initialization, backups, and uploaded-file instructions | Restore a test environment and verify versions |
| Configuration and secrets | Environment-variable documentation, configuration templates, certificates, and a secure key-transfer method | Sensitive values are transferred through a controlled channel |
| Third-party components | Open-source and commercial components, cloud services, maps, messaging, and licensing boundaries | Check accounts, costs, licenses, and renewal responsibility |
| Documentation | Requirements, prototypes, APIs, deployment, operations, tests, and known issues | Open and verify each item against the inventory |
Reproduce the system once after source delivery
The recipient, or both parties together, should use the delivered materials to clone, install dependencies, configure, initialize the database, build, deploy, and test core workflows in the agreed environment. Opening a ZIP file does not prove that the system can be maintained. Git's documentation notes that git bundle can transfer Git objects and refs offline, but environment settings, secrets, files, and third-party accounts outside the repository still need separate handover.
List dependency and third-party boundaries separately
Record each component's name, version, purpose, source, license or commercial entitlement, modifications, known alternatives, and upgrade owner. If a machine-readable software bill of materials is needed, see the SPDX open standard. Decide whether and how extensively to use it according to the organization's security and compliance process.
Sequence for a mid-project handover
Freeze and tag a working version first. Back up databases and files, then export the task backlog, defects, risks, and change log. Transfer repositories, servers, domains, certificates, cloud services, third-party accounts, and contacts. Finally, have the recipient reproduce the system in a new environment and rerun core workflows. Production secrets should not go into source code or ordinary documents.
Put ownership and evidence on the same handover line
Download the software project source, deployment, and account handover checklist (Chinese) and record repository versions, build dependencies, database, secrets and configuration, deployment rollback, third-party services, account permissions, verification methods, and handover evidence. Do not write passwords, tokens, or private keys directly into the sheet.
Frequently asked questions
When should a request go through project change control?
When an approved scope, workflow, API, deployment method, or acceptance condition changes and affects effort, schedule, or risk, create a traceable record.
If a provider changes mid-project, what should be transferred first?
Freeze a working version, then receive repository access, an environment inventory, database and file backups, known issues, third-party accounts, and the remaining task scope.
Can the checklist be copied directly into a contract?
It can guide business and technical verification. The organization's legal team or qualified advisers should review intellectual property, confidentiality, data, and liability clauses.
Related materials
How to Choose a Custom Software Development Company in Beijing, How to Develop an Enterprise Management System, Software Provider Delivery Capability Checklist (Chinese).