Legacy Support
We examine an existing application before deciding whether to protect, modernise, upgrade or replace a selected module.
An audit is not a quick code review or a list of style comments. It replaces assumptions with verified information: what the system does, which business processes depend on it, where risk lies and what should happen first. An older application can contain valuable knowledge about exceptions, pricing, documents, customers and integrations even where its documentation is incomplete.
The audit starts with consequences, not framework versions. Are orders, payments, invoices and customer access predictable? What blocks development? Which data must remain consistent? Who handles a failure and how does the business learn about it?
Business processes
orders • payments • documents • access
│
▼
Audit areas
code and dependencies • data • integrations • security
testing • deployment • workers • monitoringThe work may cover PHP and framework versions, libraries, architecture, database queries and migrations, API integrations, authentication, authorisation, organisation boundaries, secrets and deployment. It is not automatically a complete security assessment or evidence that no vulnerabilities exist; conclusions depend on the agreed scope and available material.
The report separates fact from interpretation. A log showing an invoice worker stopped is evidence. The risk that paid orders will wait for documents follows from that evidence and the process description. Priority also depends on business impact, frequency and recovery options.
| Element | Example | |---|---| | Observation | Invoice worker does not restart after some releases. | | Evidence | Logs, configuration and release history. | | Risk | Paid orders may wait for documentation. | | Recommendation | Check workers, expose status and define a restart procedure. | | Priority | Agreed with the business by impact and urgency. |
Consider a hypothetical Symfony application handling checkout, payments, invoices, email and an operations panel. It is not a GiSoft client case. An audit may find stable checkout but poorly verified payment callbacks, invoice jobs without a visible state, and manual retries that could duplicate work.
That does not automatically call for replacement. First we check the authoritative order state, the boundary between application logic and payment provider, timeout behaviour, durable attempt records and tests for the critical workflow. A stable identifier helps recognise the same case, but idempotency also needs durable state, concurrency control, uniqueness constraints and compatible provider behaviour.
An audit reviews data ownership and whether synchronisation creates two systems of record. It assesses performance from actual queries and load rather than assuming every SQL query or monolith should be replaced. It also covers retries, timeouts, webhooks, integration credentials, workers, backups, monitoring and recovery documentation.
Access control is checked on the server: identity, roles, permissions, organisation isolation and disabled accounts. A hidden button is not a security measure. When client information is confidential, we agree access boundaries, minimise data exposure and identify areas that could not be verified.
Findings + business context
│
├── retain a stable module
├── apply immediate protection
├── stabilise operations
├── modernise a selected area
└── plan replacement or a broader rewriteAn audit report is not a finished technical design or a guarantee of outcome. It records scope, verified findings, assumptions and limitations, risks and business effects, recommendations and a justified order of work. It also identifies decisions needing more evidence or a separate investigation.
GiSoft combines discussion with people using the system, technical analysis and production behaviour. The business receives a basis for choosing protection, stabilisation, phased modernisation, module replacement or a broader rebuild rather than deciding from technology age alone.