---
id: KB-CF-010
url: https://app.codecontract.io/help/use-cases-by-capability/inheriting-a-system-somebody-else-built
idioma: en
categoria: casos-por-funcionalidad
audiencia: usuario
nivel: avanzado
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-CF-002, KB-TL-013]
citadoPor: [KB-CF-020]
---

# Inheriting what somebody else built

_You take over a role and inherit processes, cases and criteria you never wrote._

**Responde a:** i inherited document management from someone else · taking over a colleague's processes · understanding a system i did not build · reviewing configuration someone else left

Someone left and this is yours now. One temptation is to rebuild it your way; the other is to touch nothing out of fear. Both are expensive. What works is a short, ordered walkthrough before deciding what to change.

## The walkthrough, in one afternoon

1. **See what is alive** — How many cases moved last month. What has not moved in six months is probably unused.
2. **See who signs in** — The log shows who actually uses this. Sometimes it is two people, and not the ones you were told.
3. **Open the most-used processes** — Read them as the supplier who receives them. That is where you see why people deliver or not.
4. **Look for what expires** — It is what can blow up unannounced if nobody was watching.

## What to touch, in what order

| Finding | Urgency | What to do |
| --- | --- | --- |
| Expired documents and nobody warned | High | Fix it this week |
| Accounts and accesses of people who left | High | Close them |
| Processes with titles nobody understands | Medium | Rewrite them; it lifts delivery and breaks nothing |
| A folder structure you dislike | Low | Leave it. Changing it disorients people who had found their way |

> [!IMPORTANT]
> Do not close or delete cases you do not yet understand. One may be open for a reason you cannot see — a claim, a stalled site — and closing it with the wrong reason leaves a record you will have to explain later.

> [!WARNING]
> If whoever built it is still reachable, half an hour with them saves two weeks. What is written nowhere is why each thing was decided, and only they have it.

> [!NOTE]
> Change one thing at a time and let two weeks pass. If you change five and something worsens, you will not know which.

**Can I see who configured each thing?**

The log shows who made each change and when.

**What if a process is clearly wrong?**

Change it, but for future cases: running ones are corrected individually.

**Is it worth rebuilding entirely?**

Almost never. What works, however ugly, is worth more than something elegant and untested.

## Ejemplos

**Someone inherits a company's document management when the manager leaves.**

- Spends an afternoon on the walkthrough
- Closes four accesses and fixes nine unwarned expiries
- Leaves the folder structure alone

→ Within a week they have the urgent things under control without breaking anything people already knew how to use.

**You inherit a process built by somebody who has left and nobody knows why it asks for what it asks.**

- Goes through the list with whoever uses it today
- Removes what nobody looks at and notes why the rest stays

→ The process is understood and can be improved rather than touched fearfully.

**The inherited process has ten phases and nobody remembers the reason.**

- Checks which phases genuinely add something

→ The process shortens without losing anything.

**Something is changed and it breaks a case nobody knew about.**

- Tests the change on a real case before applying it

→ The improvement does not break what worked.

**There are four similar inherited templates.**

- Unifies and archives the ones not being launched

→ The list becomes readable again.

**Nobody knows which files use each template.**

- Checks which ones are still active

→ You touch what is in use rather than what is dormant.