Can our technical team maintain the system after source-code handover?
The clearest acceptance test is whether the client's technical team can use a clean environment to build, deploy, restore data, release a small change, and roll back without the original supplier performing the critical steps. Receiving a source-code archive is not a completed handover.
Maintainability also depends on repository history, build tooling, configuration and secret inventories, schema and migration scripts, cloud permissions, third-party services, open-source licenses, release procedures, monitoring, incident records, and unresolved technical debt. If any essential element exists only on a supplier's laptop or personal account, the client can possess code that it cannot run.
When agreeing deliverables, handover, and ownership boundaries, also compare Can our system still be maintained if the supplier closes or its core team disbands?; the linked guidance adds context that should be considered in the same decision.
| Handover depth | What the client receives | Remaining gap | Final acceptance? |
|---|---|---|---|
| Source archive | Files at one point in time | No history, environment, accounts, artifacts, or operational proof | No |
| Repository and documents | History, architecture, interfaces, and deployment guide | Documents may be stale and untested | Input to handover only |
| Assets plus takeover exercise | Repository, data, accounts, artifacts, documents, training, and independent results | Residual issues and support window still need agreement | Recommended |
The asset register should cover seven areas: source and CI/CD; runtime accounts and permissions; data dictionaries, migration, backups, redaction, export, and restore evidence; architecture, interfaces, versions, capacity assumptions, and limitations; release, scaling, alerting, incident, and disaster-recovery runbooks; ownership and licenses for custom, client, open-source, and commercial components; and a frank backlog of defects, temporary workarounds, security risks, upgrades, and future cost.
Production secrets should not be copied into documents or source. Rotate them and grant access through a client-controlled secret system. Commercial components and non-transferable services must be distinguished from source owned by the client.
Wavesteam should prepare an isolated or pre-production environment, redacted data, permissions, and an exercise script. An engineer nominated by the client and not involved in development then checks out a tagged version, installs locked dependencies, initializes data, injects test configuration, builds, and deploys it. That engineer makes one low-risk change, runs tests, publishes it, rolls back, restores a backup, and reconciles key records. We observe and answer questions but do not take over the steps being tested; any blockage becomes an asset or documentation defect to fix and retest.
Record time to first successful build, documentation blockers, test results, restore point and time against the agreed RPO/RTO, rollback duration, and questions that still require oral knowledge. There is no universal RPO or RTO; Wavesteam derives appropriate targets from business impact and proposes them for client approval. A process that still needs a personal supplier account or cannot be rebuilt on another machine has not passed.
Our transparent delivery standard treats repositories, documents, accounts, and process history as continuing deliverables rather than a final-payment package. The contract schedule should identify each asset and right explicitly. A client without its own engineers may continue managed operations, while retaining domain, owner cloud account, and core business data so a future move remains practical.