Recovery starts by identifying what was lost: availability, files, database records or trust in the environment. A configuration failure and confirmed compromise need different responses. Deploying an archive may restore pages while retaining the cause. We assess the situation, preserve necessary information and choose recovery sources, then verify data and operations. PHP migration is considered separately as an operational improvement.
Record the initial state
Establish discovery time, symptoms and recent actions. Check infrastructure, application and available logs. Suspected attack requires containment and evidence preservation before destructive changes. After a failed release, compare code, configuration and data changes. Explain confirmed facts and unknowns so recovery follows reasoning rather than repeated, uncoordinated file replacements.
Verify backups
An archive’s existence does not establish usability. Check date, contents and readability, including databases, uploads and configuration. For stores, database and file state must correspond. Suspected compromise raises the possibility that the backup already contains unauthorised changes. Without a trusted archive, consider separate sources and state limits honestly rather than promising unavailable data.
| Source | What it may restore | What to verify |
|---|---|---|
| Full backup | Environment and data at a point in time | Date, integrity and trust |
| Database export | Stored records | Relationships and currency |
| Repository | Application version | Configuration compatibility |
| External systems | Individual operations | Reconciliation and import feasibility |
Restore separately from production
A separate environment permits verification before visitors return. Install supported components and applicable fixes with limited permissions. Review credentials rather than copying them automatically. Revoke and replace potentially exposed secrets in a trusted environment. A reproducible configuration is more valuable than files that happened to work after undocumented edits, especially for an old installation whose composition is unclear.
Reconcile data and operations
Check content, documents and forms. Applications also need roles, relationships, amounts and states. Agree representative operations with the customer and record outcomes. Investigate orders newer than the backup using available sources. Provider records may help but lack fields, so disclose gaps for staff handling rather than presenting an incomplete business state as complete.
Prevent accidental side effects during testing: repeated email, duplicate orders or resubmission to integrations can worsen damage. Restrict outbound actions and use test configuration where possible. Confirm necessary connections separately before production. This verifies logic without affecting customers and prevents an old schedule unexpectedly triggering live work.
Remove the cause
Correct configuration or replace and fix dependencies as appropriate, then confirm operation. For compromise, investigate access and scope; deleting a visible malicious file is not a completed investigation. Personal data consequences need separate review. Where GDPR authority notification is required, assessment relates to awareness and risk, not the completion of recovery or migration.
- Failure or compromise indicators → Record and contain
- Record and contain → Choose trusted source
- Choose trusted source → Restore separately
- Restore separately → Data and functions verified?
- Data and functions verified? → Choose trusted source (No)
- Data and functions verified? → Return service and plan changes (Yes)
When a backup is insufficient
Define the achievable recovery point. Code may come from a repository and some operations from external systems, while missing enquiries remain unknown. Document limits so staff distinguish an available website from a complete business history. Do not invent missing records or mark incomplete operations successful without evidence. Reconcile against sources appropriate to each action.
Review future backups after restoration: what is saved together, who sees errors and how often recovery is tested. Files without the orders database are inadequate; database copies without required documents may be too. The outcome is a verified operational recovery scenario rather than dated folders.
Assign backup ownership, alert recipients and test responsibility where gaps were found. This avoids discovering archive usability only during the next emergency.
The recovery plan should distinguish what is technically available from what can be trusted. A recent archive may contain the same unauthorised changes as production, while an older one may omit important new orders. Selecting a source therefore includes both integrity and business reconciliation, with any remaining uncertainty visible to the customer.
Outbound activity deserves its own launch check. A restored environment can contain schedules or queued operations that would send messages again. Restrict those actions during verification, then confirm which connections are enabled for production. This avoids turning recovery into an accidental second disruption for customers.
After restoration, the handover should include what was done, what was checked and what remains unresolved. If migration is proposed, define it separately so the owner can compare immediate recovery with longer-term architectural change. A new language is not a substitute for missing data or for understanding the original incident.
When to move away from PHP
Recovery restores agreed operations or a limited replacement when the old environment is unusable. Migration then evaluates Go or Node.js when existing architecture prevents updates and makes releases risky. It cannot recover data absent from all sources or cancel the investigation. Explain these boundaries before quoting short timelines.
Send address, symptoms, discovery time and backup details without passwords. We define the first stage, expected result and unknowns. After recovery, provide actions taken and recommendations; migration receives its own scope and acceptance. The aim is dependable service, understandable data and tested recovery, rather than a homepage that merely opens again.
Sources
PHP: official 2026 advisories. EDPB: personal data breaches. Checked on 26 October 2026. Migration procedures, examples, prices and delivery conditions describe the project’s proposed service.
