How to take over software another vendor built: the first two weeks
Inventory before audit, audit before changes, and a written scope before a contract. A two-week sequence for inheriting a live system, from our own handover of a marketplace.
- Inventory first. Most surprises are outside the code: deploy path, backups, accounts.
- Rank findings by severity and fix in waves, most urgent first.
- Write the maintenance scope after the audit, not before.
- Capture a baseline before the first change, so you can show improvement later.
Quick answer
Spend week one on an inventory: repositories, environments, accounts, secrets, how production deploys, whether backups run and can be restored. Spend week two on a ranked audit, a scored baseline and a written scope. Change nothing in production until both exist, except in an emergency.
The short answer
When you inherit a live system, the urge is to start fixing. Resist it for two weeks. The first week is an inventory. The second is a ranked audit, a baseline and a written scope. Only then do you change anything.
This is opinionated on purpose. Most handovers go wrong in the first month, and almost always for the same reason: someone started “improving” a system before they knew what it did, what it depended on or what would hurt most if it broke.
Why buyers ask this
You may have a vendor who left, a developer who moved on, or a system you bought as part of a business. Nobody holds the whole picture, and the system is earning money, so every change feels risky. You also don’t yet know whether you are inheriting a tidy codebase or a liability. The two weeks below are how you find out cheaply.
Before day one: three rules
- Get access in writing, early. Repository access, hosting, the domain registrar, app-store accounts, payment and messaging dashboards, monitoring and the database. If the previous vendor is still around, ask for the list of what they hold. If they aren’t, list what you can see and assume the rest is missing.
- Freeze non-urgent changes. Emergencies only. Fixing as you go means you never see the whole picture, and you can’t rank the work.
- Rotate before you trust. Anyone who left still knows the passwords and keys. Once you have the inventory, change credentials that a former team could still use, starting with anything that touches money or personal data.
Week one: inventory
Write it all down in one document. You are not judging yet.
| Area | What to record | Who to ask |
|---|---|---|
| Code | Every repository, which one deploys what, which branch is production | Previous developer, the hosting account |
| Environments | What runs in production, whether a staging copy exists, what each is for | Previous developer, the server itself |
| Accounts | Who owns the domain, hosting, app-store listings, payment and messaging accounts | The business owner, registrar and billing records |
| Secrets | Where credentials live, who can read them, whether any are in the code | Previous developer, a scan of the repository |
| Release path | How a change reaches production, step by step, and who does it | Previous developer, deploy logs |
| Data | Where the database runs, who can reach it, what personal data it holds | Database host, schema |
| Backups | Whether they run, where they go, and whether anyone has tested a restore | Hosting dashboard, then a real restore test |
| Third parties | Every external service the system calls, and the account behind each | The code’s configuration, billing records |
| Documentation | What exists, and whether it is true | Read it against the system |
Two points make this table work. Record “unknown” as an answer. An unknown is a finding. And separate what the code can tell you from what only people can. On a marketplace we took over, the system arrived as five code repositories on one server. Several answers, such as how production is deployed and how recovery works, aren’t in the code at all. An audit that only reads repositories can’t settle them, so the inventory lists them separately and someone has to be asked.
Week two: a ranked audit
Now judge. Review the system area by area, so nothing gets skipped because it’s boring. We use 17 parts, from system discovery, architecture, user flows, data and APIs through security, authorisation, payments and concurrency, scale, reliability, web and mobile, testing, infrastructure and release, privacy and compliance, design and SEO, and dependencies and documentation, ending with a synthesis. Your list can be shorter. Its job is the same: stop you auditing only the parts you find interesting.
Rank every finding by severity, most serious first. A workable scale:
| Severity | Meaning | Example (generic) |
|---|---|---|
| Critical | Someone could take money, data or control today | An endpoint that anyone can call, or a secret in a public place |
| High | Likely to cause an outage or data loss | A change process that can’t be undone, or backups nobody has restored |
| Medium | Will hurt as you grow | Missing indexes, no monitoring |
| Low | Quality and tidiness | Dead code, inconsistent naming |
Ranking is what makes the audit usable. A flat list of two hundred issues is paralysing. A ranked list lets you say: these are fixed first, these wait, and these we will accept.
Keep evidence next to every finding, such as the file, the log or the screenshot. A finding nobody can reproduce doesn’t survive review, and a vendor who disputes it will win the argument.
Score a baseline
Before you change anything, score the system against a fixed list of categories and write the date on it. Ours has 21, on a 0 to 10 scale, from architecture and security to backup, accessibility, SEO and dependencies. The scores reflect only what you can verify. Where a control may exist outside the repositories, the row says so, because an unverifiable control is an unreliable control.
Re-score every quarter. The baseline is what lets you answer “did it get better?” with a dated number. Also record one or two operational measures that the business cares about, such as error rate, page speed or completed bookings per week. The scorecard tells you how the system is built. It doesn’t tell the owner how many bookings completed last week.
Write the scope after the audit
Only now write the maintenance agreement. Three rules:
- Remediation is a phase, not routine upkeep. If the audit found serious problems, say so in the scope, and put the repair first.
- Limits in writing. What is covered, what is capped, what is excluded.
- Risk decides process. A copy change doesn’t need an architecture review. A payment change needs everything. See what a maintenance retainer should and should not cover.
Fix in waves
Order the fixes by severity and by dependency, not by what is quick. Each wave should be small enough to verify and undo. Do not ship a code change and an incompatible database change together, because that makes a rollback impossible without losing data. Add the new thing, switch over, then remove the old thing, in three separate releases.
The mistakes we see most
- Fixing while auditing. You lose the picture, and you can’t rank.
- Trusting the documentation. It describes the system someone intended. Read it against the real one.
- Skipping the restore test. A backup nobody has restored is a hope.
- Leaving old credentials alive. The vendor who left can still log in.
- Calling repair “maintenance”. It hides the cost, and it hides the risk.
- Starting the redesign now. Fix the foundations first, or you can’t tell which change caused which result.
Our fixes on that marketplace are planned, not shipped, so this is a method, not a result. And if your system is small, with one repository, one environment and one person who knows it end to end, a full audit is more than you need. A handover checklist and a half-day review will do.
Two weeks, at a glance
| Day | Do |
|---|---|
| 1 to 2 | Access list, freeze non-urgent changes, rotate exposed credentials |
| 3 to 5 | Inventory: code, environments, accounts, secrets, release path, backups |
| 6 to 8 | Audit in parts, evidence beside every finding |
| 9 | Rank by severity, score the baseline |
| 10 | Write the scope, put remediation first, agree the waves |
Next: what a maintenance retainer should and should not cover and the full handover checklist. Case study: inheriting a live marketplace.
Facts about the marketplace come from our own audit tracker, handover documents and scorecard and are tracked in our claim ledger. The client is under an NDA, so no client detail, score or finding appears. The two-week sequence, severity scale and day plan are our own method and proof grade 4, not an industry standard.
More by GarunaCDX
Let's talk about your build.
Tell us what you are building. A founding engineer replies within one working day with how we would approach it.
