AL+

Codebase takeover checklist: what to inspect before accepting a system

A reusable checklist for taking over software from another developer, agency, or team: access, production, data, change safety, dependencies, security, knowledge, and cost. Use it before you agree to own the system.

·

Before you accept responsibility for a system someone else built, inspect it. This is the checklist AL+ uses when taking over software. It is written so that a founder, a CTO, or an incoming team can use it without us. Work through it in order; the first sections protect you from the failures that cannot be undone.

The checklist has eight parts. Each item is a question with a yes-or-no answer. A "no" is not a reason to refuse the system. It is a line in the plan.

1. Access and ownership

The most common takeover failure is discovering, weeks in, that a critical account belongs to someone who has left.

  • Is the source code in a repository your company owns, with administrator rights held by your company?
  • Do you have owner-level access to hosting, DNS, the domain registrar, databases, object storage, and CDN?
  • Are email sending, payment providers, third-party APIs, app store accounts, and monitoring registered to company addresses, not personal ones?
  • Where do secrets live, and can you rotate every credential the previous developer had without an outage?
  • Which accounts are paid, on which card, and when does each renew or expire?
  • Are there licences (fonts, libraries, SaaS seats, map tiles) that will lapse when the previous team's accounts close?

If any answer is "we do not know", stop and find out before you change anything.

2. Production reality

The repository tells you what was intended. Production tells you what is true.

  • What is deployed right now, from which commit, and does it match the main branch?
  • How is it deployed? By hand, by a script, by a pipeline? Can you repeat it?
  • What runs on a schedule: cron jobs, queues, scheduled functions, webhooks? Where are they configured?
  • Which external services does the system call, and which call it?
  • What do the logs and error trackers say has been failing quietly?
  • What environments exist besides production? Is there a staging environment that resembles it?

3. Data

Data is the part of a system you cannot regenerate.

  • Where does data live: databases, files, third-party services, spreadsheets?
  • How large is it, and how fast is it growing?
  • When was the last backup, and has a backup ever been restored somewhere and checked?
  • What personal data is held, under which legal basis, and where is it documented?
  • Are there migrations pending, half-applied, or applied by hand?
  • Can you export the data in a form you could move to another system?

Restore a backup to a safe place during the review. A backup that has never been restored is a hope, not a backup.

4. Change safety

You will need to change the system. Find out how dangerous that is.

  • Can you run the system on a developer machine from the repository alone?
  • Are there tests? Do they pass? What do they cover?
  • Is there a review step before code reaches production?
  • Can a bad release be rolled back, and has that been done before?
  • Does a trivial change (a typo in a footer) travel through the full path in under a day?

If the answer to the last question is no, fixing that path is the first engineering task, before any feature.

5. Dependencies and platform

  • What are the runtime, framework, and database versions, and when does each reach end of life?
  • How many dependencies are there, how old are they, and which are unmaintained?
  • Do any carry known vulnerabilities?
  • When was the last upgrade, and what broke?
  • Is anything pinned to a version for a reason nobody remembers?

6. Security basics

This is not a penetration test. It is the minimum you must know before you own the system.

  • Is authorization enforced on the server, or only in the interface?
  • Are secrets in the code or in the repository history?
  • Is user input validated before it reaches the database or the shell?
  • Who has access to production, and is that access individual and revocable?
  • Are there administrative endpoints, debug modes, or default credentials still enabled?
  • Is transport encrypted everywhere, including between services?

7. Knowledge

  • Is the previous developer reachable, and willing to answer questions for a fee?
  • Is there any written description of the architecture, the deployment, or the reasons behind major decisions?
  • Which parts of the system does nobody currently understand?
  • Which parts does everybody avoid touching, and why?
  • What incidents happened in the last year, and how were they resolved?

Ask about decisions, not code: why this database, why this hosting, what they would change, what they were afraid of. Record the answers.

8. Cost and fit

  • What does the system cost per month in hosting, licences, and third-party services?
  • What does it cost in engineering time to keep running today?
  • What does the business need from it in the next twelve months?
  • Is any large part of it serving a use case that no longer exists?
  • Is this a system to own, to modernize in place, or to replace? The answer comes from the previous seven sections, not from the first meeting.

How to use the result

Write the answers down as a single document, with a "no" list ranked by risk. The ranking becomes the first weeks of work: access and billing first, then backups and deployments, then the fragile parts, then the wanted ones. A takeover done in this order shows the business a new feature later than it hoped and an outage never.

If you would rather have us run this review and take the system over afterwards, that is what our software takeover service is. If you want to run it yourself, the checklist is yours.