Source code handover: why to insist, and what "complete" means

We are regularly called in to take over a system left by another team. In most cases the business believes it "has the source code" — until the moment it needs rebuilding on a new server and far too much turns out to be missing.

Why this matters more than people think

Not because you intend to modify the software yourself. Most businesses have no technical team and do not need one. The real reason is negotiating position:

• If only one firm can change the system, they set the maintenance price and you have no alternative.
• If that firm closes or changes direction, nobody is looking after your system.
• If the relationship deteriorates, you cannot leave without losing everything.

Having the source does not mean you will use it. It means you could — and that alone changes the balance in every negotiation that follows.

Handover checklist

The code

• All source in a repository with change history, not a one-off zip file.
• Administrative ownership of that repository in the company’s name, not a developer’s personal account.
• A list of third-party libraries with their licences.

How to actually run it

• Environment documentation: what software, which versions, what configuration.
• The list of environment variables and configuration keys, with an explanation of what each does.
• The deployment procedure for shipping a new build, written as executable steps.
• The database schema and the migrations that shaped it over time.

Infrastructure and accounts

• Administrative access to servers, domains and certificates.
• Accounts for the third-party services in use — and these should have been registered under company email from the start, not the supplier’s.
• Backup configuration: where backups live, how often, how long they are kept, and the restore procedure.

Documentation for users and administrators

• User guides by job role.
• A description of the main processes and any special rules built into the system.
• A list of scheduled automated jobs, when they run and what they do.

The one test that proves the handover is complete

Every item above can be ticked off and still be incomplete. There is only one real verification: rebuild the whole system on a blank server using only what was handed over, without phoning anyone.

If you are already in a bad position

If the source is already out of reach, there are still moves, in order of priority:

1. 1Secure the data first. Data matters more than code. Ask for a regular full export onto your own machines, and do this even while the relationship is good.
2. 2Move the domain and service accounts to the company. Usually straightforward and rarely contentious.
3. 3Negotiate to buy the right to use the source. It costs, but far less than rewriting.
4. 4If no agreement is possible, plan a piecewise replacement. Rewrite module by module while the old system keeps running — slow, but without interrupting trade.

SealCore takes on work of the fourth kind: reading through a system another team left behind, judging whether it is salvageable, then repairing or rewriting it in stages. Details in the legacy maintenance and upgrade solution area.