How to document a system you inherited
When you document a system you inherited, the temptation is to start with the screens. Start with the data model instead. In Jestor, tables and their relations describe what the system is actually about, and the apps built on them are presentation.
Why inherited systems are intimidating
Nobody explains why decisions were made, only what exists. Faced with dozens of apps and automations, the instinct is to document everything, which takes months and produces a manual nobody reads.
Most of it is also irrelevant, because much of what exists is no longer used.
What a structured approach gives:
- Understanding of what the system is really about
- Knowledge of which parts are still in use
- Confidence to change something without breaking another
- Documentation focused on what matters
- A handover that does not depend on the previous owner
Order of investigation
| Step | What it reveals | Why first |
|---|---|---|
| Tables and relations | What the system models | Everything else sits on it |
| Record volumes | What is actually used | Separates live from abandoned |
| Automations | What happens without a person | The hidden behaviour |
| Integrations | External dependencies | Where breakage propagates |
| Permissions | Who does what | Reveals the real process |
| Apps and views | How people interact | Presentation, understood last |
Step by step to do it
- Map the tables and their relations before opening a single app.
- Check record counts and recent activity, to find what is live.
- List the automations, reading their triggers and actions.
- Identify external connections and what depends on them.
- Review permissions, which describe the real process better than any diagram.
- Talk to the people using it, whose workarounds reveal the gaps.
- Document only the live parts, and archive the rest.
Why the workarounds are the most valuable thing you will find
Every workaround marks a place where the system does not fit the process. Collected during your investigation, they become the improvement backlog, and they are far more useful than a complete description of a system nobody is satisfied with.
Why choose Jestor
In Jestor, tables and relations are inspectable directly, record history shows recent activity per table, automations are listed with their triggers and an execution log, permissions are visible per role and field, and documents can be attached to the processes they describe so the documentation stays where the work is.
Frequently Asked Questions
Where should I start with an inherited system?
With the tables and their relations, since everything else is built on them. See jestor.com.
How do I know which parts are still used?
Record volumes and recent activity per table.
What is the most useful output?
The list of workarounds people have invented, which becomes your improvement backlog.
Video Tutorial: Step by Step
With Jestor, you can automate workflows, connect teams, and build internal systems your way, all without code and powered by AI. Discover Jestor at jestor.com and see how to take your company's operations to a new level of efficiency and control.