A failing system rarely fails in only one place. The visible complaint may be a broken button, a slow page or an incorrect balance, while the real problem sits in permissions, duplicated data, conflicting plugins, undocumented manual work or a damaged deployment process.
Before approving repairs or a rebuild, map the operating reality. The goal is not to produce a long technical report. The goal is to establish what the organization depends on, what can be trusted and what change can be made safely.
Start with the workflow, not the technology
Interview the people who perform the work and follow one real transaction from beginning to end. Record who creates it, who approves it, where money or responsibility changes hands, what evidence is retained and what happens when something goes wrong.
A workflow map reveals hidden systems: spreadsheets, WhatsApp approvals, shared passwords, handwritten registers and private knowledge held by one employee. These dependencies belong in the audit because they determine operational risk.
- Identify the critical daily and monthly workflows.
- Name every role that creates, changes, approves or views records.
- Mark external integrations, manual handoffs and offline steps.
- Record the business consequence if each workflow stops.
Establish a protected technical baseline
Before changing production, preserve a dated copy of the application, database, uploaded files, configuration and dependency versions. Confirm that the backup can actually be opened or restored in a protected environment.
Then inventory the active modules, scheduled tasks, integrations, database tables, permissions, APIs and custom code. A clean baseline makes regression testing possible and prevents a repair from silently deleting valuable behavior.
- Create and verify a recoverable backup.
- Record software, plugin, theme and runtime versions.
- Inventory data stores, scheduled jobs and external services.
- Separate secrets and credentials from working copies.
Test data integrity, access and recovery
Check whether totals reconcile, records are duplicated, required fields are missing and status transitions make sense. Review permissions from the viewpoint of each real role, not only the administrator.
Backups are not enough. A responsible audit includes a restore test, a review of audit trails and a clear answer to how the organization would continue if the primary system became unavailable.
- Reconcile a sample of financial or operational totals.
- Test least-privilege access for every staff role.
- Confirm logs show important changes and approvals.
- Perform a controlled restore or recovery rehearsal.
Decide: stabilize, repair, modernize or replace
A rebuild is not automatically the professional answer. If the data model and core workflow are sound, targeted stabilization may produce value faster and with less risk. Replacement is justified when the architecture cannot meet required security, scale, integration or operational needs.
The decision should compare risk, time, cost, migration difficulty and business interruption. A phased roadmap normally provides more control than a single all-or-nothing launch.
- Immediate containment for critical risk.
- Targeted repair for valuable working logic.
- Modernization where the platform can still support the future.
- Planned replacement only when evidence supports it.
What the audit should deliver
The final output should be usable by management and technical teams. It should state what was inspected, what was verified, what remains unknown, which risks are urgent and what each recommended phase will achieve.
- System and workflow inventory.
- Risk register with evidence and business impact.
- Data, security, performance and recovery findings.
- Prioritized roadmap with dependencies and acceptance tests.
- Explicit limitations, assumptions and unresolved questions.