Legacy infrastructure rarely explains itself in one place. The real system is spread across running services, configuration, application code, scheduled maintenance, data stores, and network devices. Changing any one of those pieces before understanding the whole flow can create more uncertainty than it removes.
Start with a read-only contract
Before inspection begins, define the boundary: no configuration edits, restarts, package changes, database writes, or test commands that alter sessions. The purpose of the first pass is to build an evidence-backed system map, not to prove that a proposed fix works.
This constraint improves the audit. It forces every conclusion to point back to observable evidence and makes uncertainty explicit.
Inspect the platform in layers
A useful sequence moves from the outside in:
- Host role — identify operating-system age, running services, resource pressure, and exposed service categories.
- Service topology — map the authentication service, policy store, management application, enforcement devices, and supporting jobs.
- Configuration dependencies — record which components read from which data sources and where trust boundaries appear broad or unclear.
- Application command inventory — list the operations the code can perform without assuming every defined function is active.
- Runtime evidence — compare code and configuration with observed processes, connections, schedules, and logs.
The important discipline is to separate three statements:
- Defined in code means a capability exists.
- Wired into the active flow means another component currently calls it.
- Observed at runtime means there is direct evidence it executed during the inspection window.
Treating those statements as interchangeable is one of the easiest ways to produce a misleading audit.
Trace complete operational flows
File inventories are useful, but operators need to understand what happens end to end. A network access platform can usually be described through four connected flows:
- Authentication: a network device sends a request, the policy service evaluates identity and attributes, and the device enforces the response.
- Accounting: session events are recorded so usage, duration, and state can be reviewed later.
- Management: an administrative application changes policy data that the authentication path consumes.
- Maintenance: scheduled cleanup, monitoring, and recovery jobs keep the service operating over time.
Mapping these flows reveals hidden coupling: a modern-looking web interface may still depend on an older policy engine, a direct device API may exist but not drive the primary path, and duplicated maintenance jobs may be more important than any single source file.
Turn findings into a modernization sequence
The first deliverable should not be a rewrite proposal. It should be a sanitized system map, an evidence matrix, a risk register, and a list of decisions that need owners.
A safe modernization sequence is usually:
- Confirm the current source of truth for identity, policy, and session data.
- Document interfaces and failure behaviour before replacing components.
- Narrow trust boundaries and remove duplicated operational responsibility.
- Add observable health checks and repeatable recovery procedures.
- Replace one dependency at a time while preserving a tested rollback path.
Public boundary
The public lesson is the method, not the infrastructure inventory. Hostnames, addresses, usernames, credentials, database names, internal paths, network ranges, organization identifiers, and exploitable configuration findings remain in private working material.
A trustworthy audit explains what is known, how it was verified, what remains uncertain, and which change would be safest to test next.