Test the handoff before the original developer leaves
The repository arrives. The application still works. Then the receiving developer tries to deploy a fix and discovers that the build needs a private package, the hosting account belongs to someone else, and nobody knows whether the backups can be restored.
A useful custom software handoff proves that another authorized team can run the system. A folder of code is one part of that transfer.
This is a delivery checklist for buyers and receiving developers. For contract and selection questions earlier in the project, see how to avoid vendor lock-in.
Name the receiving owner
Assign a business owner and a technical owner before the final delivery meeting. The business owner accepts service responsibilities and recurring costs. The technical owner tests access, deployment, and recovery. If you do not have an internal developer, appoint the incoming provider or an independent technical reviewer.
Arrange a staged handoff while the outgoing team is still available. Agree on the verification work and any transition fees in advance. A handoff test is not a request for unlimited free training or future development.
This is a buyer’s checklist, not a list of included Somnio deliverables. Confirm the rehearsals, account arrangements, responsibilities, and fees with your provider in the delivery plan. Agree which missing items block acceptance and record any limitation the buyer accepts.
Work through the delivery inventory
| Item | What to receive | What to demonstrate |
|---|---|---|
| Source repository | History, release reference, access roles | Receiving owner can access the release |
| Build process | Runtime versions, dependency files, build instructions | Clean environment can build it |
| Automated checks | Test suite, test data guidance, automated build/check configuration, known gaps | Receiving developer can run the documented checks |
| Hosting and domain | Account owners, billing contacts, DNS details | Authorized owner can manage access |
| Configuration | Required settings and secret locations | Staging starts without copied personal credentials |
| Data | Schema, migrations, retention and backup procedures | A backup restores in an isolated environment |
| Integrations | Provider accounts, permissions, limits, failure procedures | A test transaction reaches its destination |
| Operations | Monitoring, alerts, scheduled tasks, background workers | Test alert reaches the responsible person |
| Rights and costs | License inventory, ownership terms, recurring fees | Buyer knows what transfers and what does not |
Mark missing items as open findings with an owner and due date. “Documentation sent” is not the same as “receiving team tested it.”
Run a deployment rehearsal
Ask the receiving developer to create a clean staging environment from the instructions. Use appropriately protected test data. They should install dependencies, supply configuration, apply database changes, build the frontend, start background workers, and verify the core user task.
Record any undocumented intervention by the outgoing team. If a developer has to remember a server setting or manually copy a file, add that step to the instructions or automate it. Repeat the failed part until the receiving team can perform it.
Also rehearse rollback. Application rollback and database rollback are not always the same operation. A database change can remove information that an older release needs. The handoff should explain which changes can be reversed and which need a forward repair or data restoration plan.
The goal is not a large new infrastructure project. It is evidence that the delivered release can be installed and operated using what the buyer received.
Prove recovery, not just backup creation
A successful backup job only shows that a job finished. Restore a recent backup into an isolated environment and check the important records and file attachments. Restrict access to restored customer data and delete temporary copies according to the agreed retention procedure.
Have the business owner decide how much data loss and downtime are acceptable. Then compare the tested recovery process with those requirements. Do not describe an untested restore time as a recovery guarantee.
For an order system, a useful check is whether customer records, order status, and attachments agree after restoration. Any transactions that occurred after the backup need a reconciliation procedure. Payment providers and email systems may have already acted; restoring the database must not blindly repeat those actions.
Transfer access without leaving personal dependencies
List every service the application depends on: hosting, domain registration, email, payments, object storage, monitoring, and AI providers where used. Record the account owner, billing owner, recovery method, and who can grant access.
Use role-based access where a provider supports it. Transfer secrets through an agreed secure channel rather than source control or a public ticket. Plan rotation carefully: changing a key before the application is updated can stop a live integration.
Remove outgoing access at the agreed point after the receiving team verifies control. Do not remove access needed for contracted transition work without coordinating it. The checklist should end with a known access state, not a collection of shared personal passwords.
Separate ownership from licensing and support
Ask which code is project-specific, which components existed before the project, and which services need continuing subscriptions. A license inventory should explain restrictions and renewal responsibilities. A provider account may require its own transfer process even when the buyer owns the custom code.
Somnio’s published AI consulting terms state that, upon full payment, clients own project-specific custom code. Third-party licenses and pre-existing tools retain their terms. A retainer is optional and is not required to continue with another developer. The signed agreement controls final ownership and warranty terms.
The published 30-day defect correction commitment concerns verified defects against agreed requirements. It does not promise free new features, changed requirements, or fixes for third-party service changes. Put the support contact, response arrangement, and next maintenance decision in the handoff record.
Close with an evidence-based acceptance record
Keep the release reference, rehearsal results, restore result, account inventory, open findings, and named owners together. The buyer should be able to answer: “Who can deploy a fix tomorrow, and what evidence shows they can do it?”
If the answer is uncertain, use the checklist to define the missing work before accepting the transition. For help reviewing those boundaries, explore Somnio’s architecture consulting.
