How do I transfer a codebase to a new development team?

#The repository

The easiest part, and the one most often done in a way that quietly loses something.

1. Transfer the organisation, not the repository

   A repository moved out of a supplier organisation into yours keeps its history. A repository copied into a fresh one usually does not keep issues, pull requests, review comments or releases.

   Those artefacts are where a new team finds out why a decision was taken. They are worth more than most of the documentation that gets written instead.

2. Insist on full history

   Not a zip, not a squashed initial commit. If the first commit in the history you receive is “initial import”, ask what happened to the years before it.

3. Check for other repositories

   A mobile app, an internal library, infrastructure-as-code, a separate admin tool, a data pipeline. Ask directly rather than assuming the one you were shown is all of it.

4. Give two of your own people owner rights

   Not one. An organisation with a single owner is the same single point of failure you are trying to remove, wearing different clothes.

5. Look at the history for secrets

   Credentials committed and later removed are still in the history. Before you widen access, check — and rotate anything you find, since it has been readable to everybody with a clone since the day it landed.

#Environments and secrets

Two separate lists, and the second one is the reason the first one matters.

Environments. Build the list from the cloud console rather than from a conversation. The forgotten ones are the entire point of the exercise, and an old staging environment holding a copy of production data is both a security problem and a surprising cost line.

Secrets. Document them by name and purpose, not by value: what each variable is for, what breaks without it, and where the real value lives. Values move separately, through a channel neither team keeps, and every one of them is rotated afterwards.

PAYMENT_PROVIDER_KEY
  What      Authenticates us to the payment provider
  Owner     Company payment provider account (finance@)
  Rotate    Provider dashboard → API keys → roll
  Breaks    All card payments, immediately
  Value     Not in this document. See the company vault.

#The demonstration week

The single highest-value part of any codebase transfer, and the part most often replaced by a presentation.

Book a week in which the incoming team does four things themselves, with the outgoing team available but not driving:

1. Get it running locally, from the written instructions alone. Every step they have to ask about is a correction to the instructions.
2. Deploy a trivial real change to production, through the real process.
3. Roll it back, through the real rollback procedure.
4. Restore a backup into a scratch environment and confirm the data is usable.

Each of these converts a belief into a fact, and each one reliably finds something. The most common findings: an undocumented setup step, a deployment step that only works from one person's machine, a rollback procedure that does not cover database changes, and a backup that restores but is missing something.

#What is not in the repository

Ask this explicitly. It is the category that produces the month-three surprises.

• Scheduled tasks on a server. A crontab that nobody has looked at since it was written.
• Cloud resources created by hand. A function, a bucket rule, a queue, a scheduled trigger created in a console and referenced by nothing in the code.
• Scripts on somebody's machine. A monthly report, a data fix, a deployment helper.
• Configuration held in a provider dashboard. Webhook endpoints, email templates, payment rules, feature flags.
• Manual processes. Somebody who exports something every Monday and emails it to a partner.

None of these will appear in an analysis of the code, which is why an analysis reports them as open questions rather than pretending they do not exist. Asking the outgoing team directly, in those words, is faster than any other method.

#Rotation, in the right order

Do it in this sequence, and not in any other:

1. Establish ownership of every account — whose identity is it in?
2. Transfer anything in a personal or supplier name. Several of these take days.
3. Create and verify your own admin routes, with recovery going to company mailboxes.
4. Then rotate every credential the outgoing team could have seen, and remove their personal access.

#What goes wrong

#What this does not cover