PHP maintenance based on risk and continuity
Maintenance is not waiting for failure. It preserves support, knowledge and change capacity while the product continues serving users.
- Separate incidents, prevention and evolution.
- Prioritize by impact and exposure.
- Measure technical and operational health.
- Practice recovery and transfer.
Use the guide to prepare a real decision
The goal is not to complete a reading, but to improve the quality of a technical and business conversation.
Begin by defining which situation needs to change, who depends on the outcome and which constraints cannot be ignored. Gather enough examples, metrics, incidents, architecture and previous decisions to separate facts from perceptions. The guide helps organise that evidence; it does not replace system-specific knowledge.
Then compare options by impact, risk, reversibility and team capability. A useful conclusion identifies the next proportionate step, the evidence it should produce and the conditions that would require the plan to be reviewed. This prevents a general recommendation from becoming an investment that is hard to correct.
- PrepareContext, evidence, constraints and owners.
- ChallengeOptions, assumptions, risks and change costs.
- DecideNext step, boundary and success criterion.
- ReviewOutcomes and conditions changing the decision.
1. Define the service
Agreeing systems, hours, severity, channels and responsibilities prevents everything becoming urgent. Separate user support, technical incident, recurring problem and planned evolution.
- Inventory and owners.
- Severity and impact.
- Hours and escalation.
- Work entry and acceptance.
2. Build a preventive cycle
Reserve capacity for versions, dependencies, backups, certificates, capacity and documentation. Prevention competes with features and needs visible policy.
- Support calendar.
- Dependencies and vulnerabilities.
- Backup restoration.
- Capacity and cost review.
3. Learn from incidents
Restore service first; understand and reduce recurrence afterwards. Record timeline, evidence, decision and follow-up without blame.
- Detection and declaration.
- Containment and recovery.
- Proportionate causal analysis.
- Actions with owner and date.
4. Measure for action
Combine experience, errors, latency, saturation and business signals. Every alert needs a recipient and action; every dashboard should answer a question.
- Service objectives.
- Errors by flow.
- Queue and database capacity.
- Incident and debt trends.
5. Deliver safe change
Reduce batch size, automate checks and know rollback. Maintenance and development share definition of done and release discipline.
- Risk-based review and tests.
- Small changes.
- Window and communication.
- Post-release observation.
6. Preserve knowledge
Document architecture, operations and decisions where the team works. Test onboarding and runbooks with another person to expose hidden dependency.
- System map.
- Executable runbooks.
- Relevant decisions.
- Rotation and transfer.
Content connected to this decision
Continue with diagnosis, execution or related experience.
Apply the guide to your application
We review the situation, evidence and options without tying the assessment to implementation.