What Should a Custom Software Handover Package Contain?

A custom software handover package should contain the source code, build and deployment instructions, environment and access credentials, a data dictionary, test evidence, an architecture overview, a known-issues log and a named support route. Ask for three things before signing: a requirements document you approved, a runbook your own staff can follow, and a repository you control. If any of those three is missing at final payment, the project is not finished.

The rest of this article walks through the stages of a custom software development engagement and names the artefact each stage must produce. The point is to give you a checklist you can apply to any vendor, including us.

What should the requirements stage produce before code starts?

The requirements stage should produce a signed software requirements document that lists every screen, report, integration and permission rule the system must support. Without that document, scope is whatever the developer remembers, and every later disagreement becomes a change request.

A usable requirements document has four parts: a process map of who does what, a data dictionary naming each field and its source, a list of integrations with the external system and frequency, and acceptance criteria written as testable statements. If an acceptance criterion cannot be tested by someone who did not write it, rewrite it before development begins.

This is also the stage where you decide whether to replace a legacy system or wrap it. Wrapping keeps the old database and adds a new interface; replacing retires it. Choose replacement only when the old system's data can be exported in a form the new one can validate; otherwise the migration becomes an open-ended project.

The client controls this stage more than the delivery team does. Your operations manager knows which exceptions happen weekly; the developer does not. Budget time for two review rounds, because requirements written in one sitting usually miss the month-end process.

What artefacts should design and build produce?

Design and build should produce a versioned code repository, an architecture diagram, a data model and a test log that maps each acceptance criterion to a passing test. These are the artefacts that let a second developer understand the system without calling the first.

The architecture diagram does not need to be elaborate. It needs to show which services run where, which database holds which data, and which third-party APIs the system calls. If the diagram cannot be drawn on one page, the system probably has a boundary problem worth fixing before launch.

Test evidence matters because it separates a demo from a delivery. Ask for the test log by name, and check that it covers failed payments, duplicate submissions and permission denials, not only the happy path. A vendor that cannot produce this log is asking you to trust a verbal assurance.

For teams building bespoke business software across several locations, the build stage should also produce a deployment script. A deployment that requires the original developer to run it by hand is a dependency, not an artefact. The script should work on a clean machine with only the documented credentials.

What must be in the handover checklist at go-live?

A software handover checklist at go-live must include source code access, environment credentials, a runbook, a data dictionary, a backup and restore procedure, and a named contact for support. Each item should be demonstrated, not just listed.

Use this ordered list as a starting point. Adapt the names to your business, but keep the sequence, because each item depends on the one before it.

1. Repository access transferred to an account your company owns, with the commit history intact.
2. Production, staging and test environments documented with who holds each credential.
3. A runbook covering start, stop, backup, restore and the five most likely failures.
4. A data dictionary listing every table, field, source and retention rule.
5. A known-issues log with severity, workaround and owner for each open item.
6. A support route with names, hours and escalation path for the first ninety days.

The comparison below shows what each delivery stage should produce and what happens when the artefact is missing. Treat a missing artefact as an open item on the final invoice, not as a promise for later.

Our own practice is to hand over the repository and runbook at go-live, not at the end of the warranty period. We deliver custom software, business systems, mobile apps, websites, IoT systems and AI applications from Chengdu, and the handover pack is the same shape for each. You can see the service groupings on the service overview page.

How do you verify the handover without the original developer?

You verify a handover by having someone outside the delivery team restore a backup, deploy the system to a clean environment and fix one small bug using only the documentation. If they cannot, the package is incomplete regardless of how many files it contains.

Run this test before the final payment, and give the tester a fixed time budget. If a developer who has never seen the system cannot deploy it from the runbook in one working day, the runbook is not finished. The test also tells you whether the documentation matches the code.

For a Chinese-owned business operating in Europe or North America, the tester should also check language and currency settings, tax rules and data residency notes. These are easy to omit because they sit outside the code. Our Chinese business software page describes how we scope those settings, and the Chinese-speaking developers page explains how we staff bilingual reviews.

What does the handover package cost, and how long does it take?

The handover package itself should not be a separate line item; it is part of the custom software cost and typically accounts for a small share of the total, depending on how many integrations and user roles the system has. A package priced as an extra is a warning sign.

Total cost depends on the number of integrations, the number of user roles and whether legacy data must be migrated. If a quote gives a single figure without naming those three factors, ask for the breakdown before comparing vendors. The same factors drive the timeline.

Duration depends on how quickly your team can review requirements and test releases, because those reviews sit on your side of the schedule. The development team controls build and test time; you control approval time. A project that stalls usually stalls at a review, not at a keyboard.

If you are still running the business on spreadsheets, the trigger to move is usually a process where two people edit the same file and one overwrites the other. When a spreadsheet error has already cost you money once, the next month is the right time to scope a replacement.

Frequently asked questions

What should be included in a software handover?

A software handover should include source code in a repository your company owns, build and deployment instructions, environment credentials, a data dictionary, test evidence, an architecture overview, a known-issues log and a named support route. Each item should be demonstrated to your team, not only listed in a document. If your staff cannot deploy and restore the system without the original developer, the handover is incomplete.

How much does custom software development cost?

Custom software development cost depends mainly on the number of integrations, the number of user roles and whether legacy data must be migrated. A system with one integration and two roles costs far less than one with five integrations and eight roles. Ask each vendor to break the quote down by those factors so you can compare like with like.

How long does it take to build a custom business system?

The timeline depends on how quickly your team reviews requirements and tests releases, because approval time sits on your side of the schedule. The delivery team controls build and test time; you control how fast decisions are made. Projects that run late usually wait at a review, not at development.

When should a business stop using spreadsheets?

A business should stop using spreadsheets when two people routinely edit the same file and one overwrites the other, or when a spreadsheet error has already cost money. At that point the file is acting as a database without permissions, audit history or backups. The next step is to scope a replacement, not to add another tab.

What is the difference between a software requirements document and a handover checklist?

A software requirements document defines what the system must do and is signed before development starts. A handover checklist defines what the delivery team must transfer at go-live so your staff can run the system. Both are needed; one without the other leaves either the scope or the operation undefined.

Does Your Business Website Development Produce Citable Pages?

Mobile App Development: How to Judge Accessibility Requirements

IoT System Development: How to Secure Device Credentials at Scale