What should be documented first?

Business flows that affect revenue, service, integrations and daily operations.

When is a rewrite justified?

Only after risk, dependencies, critical rules and the cost of keeping the system alive during transition are understood.

Legacy system without documentation: where to begin

Context

An old system still supports business operations, but few people understand its rules. Every change creates fear because flows, database rules, integrations, deployment and exceptions are not mapped.

Observed symptoms

Small fixes require long investigation.
Critical business rules live only in specific people memories.
There is no reliable list of integrations and scheduled jobs.
Deployment depends on poorly documented manual steps.
A full rewrite is discussed before risk and scope are measured.

Investigation path

Start with business flows

Document screens, routines and expected outcomes before explaining packages, classes and tables.

Map rules and exceptions

Legacy systems often contain old exceptions that look strange but keep operations running.

Create a minimum technical inventory

Database, jobs, integrations, files, variables, build and deploy go into the first map.

Prioritize incremental modernization

Separate critical parts, high-risk points and improvements that reduce the cost of future maintenance.

Technical decisions

Document flows that affect service or finance first.
Register technical decisions and business exceptions.
Create a stabilization route before large refactoring.
Use each maintenance task to improve the map.

Expected outcome

The legacy system still exists, but it is no longer a complete black box. The company gains clarity to fix, prioritize and modernize gradually.