Taking Over a Software Project: What the Business Must Own

A software project changes hands more often than most roadmaps allow for. An agency relationship ends, a contractor takes a permanent job, a team is restructured, and somebody inherits an application they did not build.

The code is the part everyone asks about first. It is also the part least at risk, because either it is in a repository or its absence is obvious within an hour. What goes missing is everything arranged around the code: the account that owns the repository, the key that signs the mobile build, the reason the payment integration works the way it does.

So the useful way to order a takeover is not by what matters most. It is by what you cannot reconstruct once the outgoing team stops answering.

#Rank the assets by how hard they are to recover

Three tiers, and the order you work in should follow them.

Effectively unrecoverable without the outgoing party. Code signing keys and publishing accounts, the domain registrar login, the merchant account at a payment provider, and historical data that exists in one place. These are assets where a lost credential is not an inconvenience. Losing the key an app was signed with can mean existing installations cannot be updated at all, only replaced by a new listing that every user has to install again.

Recoverable, at a cost you would rather not pay. The deployment path, environment configuration, scheduled jobs, and the decisions behind the architecture. All of it can be reverse engineered from a running system by somebody competent, and doing so consumes weeks that were meant for delivery.

Cheap to recover. The source itself, the dependency list, and anything generated from them. Worth having, never the constraint.

Most takeover checklists are ordered by the third tier because it is the easiest to write down. Work the first tier in the week you still have somebody to ask.

#Repositories, and the account that actually owns them

Access to a repository is not ownership of it. Repositories live inside an account or an organisation, and in an agency arrangement that container often belongs to the agency rather than to the business paying for the work.

Establish three things in this order. Who owns the organisation the repositories sit in. Whether the business has an owner-level seat in it, not a collaborator seat. And whether the contract assigned the intellectual property to the business in the first place, because a transfer of files does not settle a question the agreement left open.

Then take the repository, not a copy of it. A zip of the source is a snapshot with the reasoning stripped out. What you want transferred is the full commit history, the branches and tags that correspond to what is running, the pull request discussions, the issue threads, any published packages, and the continuous integration configuration. Half the answers to "why is this like this" are in those threads, written at the time by people who knew.

Two things sit beside the repository and are missed for the same reason. Repository secrets used by the build are stored separately from the code and do not travel with a clone. Anything installed as a bot or an app against the repository, including deployment integrations, is authorised by an account that may be leaving with the outgoing team.

#The credentials that never appear on a credentials list

A credentials export covers the systems somebody is thinking about. The ones that matter are usually the ones nobody thinks about until they break.

Work through this list explicitly:

• The domain registrar and the DNS provider, which are often different companies and frequently sit in a personal account
• Code signing certificates and keystores, along with the app store and play console accounts that publish with them
• Push notification credentials, which expire on their own schedule
• The payment provider and the merchant account behind it
• The domain used to send transactional email, and the records that authorise it to send
• Error tracking, analytics, and any service holding historical data that restarts at zero if the account is recreated
• Every third-party API key in use, and which account issued it

For each one there is a question sharper than "do we have the password": whose mailbox receives the password reset. An account the business cannot recover on its own is an account the business does not hold, whatever the credentials document says.

The billing owner deserves the same treatment. A service paid for on a card belonging to somebody at the outgoing supplier will keep working until it does not, and the notice will go to them.

#The deployment path, from a commit to production

Ask for the path to be written down end to end, and be specific about what end to end means: what triggers a build, where builds run, what the deployable artefact is, where configuration and secrets come from at runtime, how database migrations are applied, what the rollback procedure is, and who is permitted to approve a release.

The gaps in that document are the useful part. Most projects have one step that only one person performs, and it tends to be the step that is not written down anywhere. It might be a manual cache clear, a flag toggled in a dashboard after every release, or a job somebody runs by hand at month end. Those steps are invisible in the code and obvious in the answer to "what do you actually do when you ship".

Infrastructure itself, the servers and hosting underneath this, is a separate exercise with its own checklist. We wrote that one up separately as what to verify at an infrastructure handover.

#Documentation worth having, and the kind that is not

Most handover documentation is a description of the code written by somebody reading the code. It is the least valuable artefact in the transfer, because you can also read the code.

Four documents earn their place:

1. How to run the project locally, verified on a machine that has never run it, by somebody who is not the author
2. The deployment path described above
3. A map of every environment and third-party service, with the account that owns each and what it costs the business to lose it
4. The decisions and their reasons: why this database, why this integration works this way, what was tried before and abandoned

The fourth is the one that cannot be regenerated. Everything else in this list can be rebuilt from a running system with enough patience. The reasoning behind a decision exists only in somebody's memory and in the threads attached to the work, and it decays quickly once they move on.

#Who the licences are registered to

Commercial libraries, themes, fonts, SDKs, and seat-based services all carry licences, and a licence registered to a person is a licence the business does not hold.

Ask for a list of everything paid for, what it is used for, when it renews, and the name and account it sits under. Where something is registered to an individual at the outgoing supplier, transferring it is a task with a vendor in the loop and its own lead time, not a checkbox on the last day.

The other licence question runs the opposite way: the terms of the code you are receiving. If the product is distributed rather than run as a hosted service, open source components carry obligations that travel with it. That is worth knowing at the point of takeover rather than at the point somebody asks for the source.

#The known issues list nobody volunteers

No outgoing team opens with the things that are fragile. It reads as an admission, it arrives at the moment they are least inclined to make one, and nothing in a standard handover template asks for it.

Ask directly, and make it safe to answer:

• What would you not deploy on a Friday
• Which test fails occasionally and gets rerun
• What breaks if this integration is slow rather than down
• Which part has a workaround in place instead of a fix
• What do you do by hand that should be automated
• What has been on the list to fix for a year

A project with no known issues does not exist. A handover that reports none is an incomplete handover, and the items will arrive anyway, in the order the system chooses rather than the order you would have chosen.

#Ship something small while the outgoing team is still there

Documentation can look complete and still be unusable. The only way to know is to use it.

Before the relationship ends, have somebody from the incoming team take a trivial change all the way through: a commit, a review, a build, a deployment to production, a verification that it is live, and a rollback. The outgoing team watches and answers questions without touching anything.

Every question asked during that hour is a gap in the handover, found while there is still somebody to answer it. It is the cheapest audit available and the only one that produces a fact rather than a document.

If a supplier transition is coming and you are not certain what the business actually holds, that is worth establishing while it is still a paperwork exercise. Discuss a project takeover with us before the outgoing team's last week, not during it.