Software maintenance and support
Keeping delivered systems working — fixes, upgrades, performance and a support contract with numbers in it.
- Technical support
- Performance optimisation
- Monitoring
- Backup and recovery
- Dependency scanning
- Application upgrades
- Code
- MNT
- Class
- A · 12 months and over
- Engagement
- ROLLING 12 MONTHS · MONTHLY CONTRACT
- Stages
- 04
- Deliverables
- 06
- Sections
- 06
Overview
Software does not stay working on its own. Dependencies reach end of life, certificates expire, data volumes grow past what the original design assumed, and the platform underneath ships a breaking change. Maintenance is the least glamorous line in this register and the one that most often determines whether a good system is still a good system in three years. We take on systems we built and systems we did not, with a written response time and a monthly report that says what we actually did.
Benefits
05 pointsA response commitment with numbers: severity levels, response times and a named escalation route, agreed before anything breaks.
Preventive work, not only reactive. Dependency updates, certificate renewals and capacity checks are scheduled, because every one of those is an outage waiting for a date.
A monthly report a non-technical sponsor can read: what broke, what was fixed, what was updated, and what is coming that needs a decision.
Systems we did not build are taken on properly — a two-week familiarisation and risk assessment first, so we are not learning the system during your first incident.
Contracts are month to month after the first term. A maintenance supplier that has to be tied in is telling you something.
Workflow
04 stagesFamiliarisation
Two weeks for a system we did not build: architecture, deployment, dependencies, monitoring and the known-fragile areas. It ends in a risk assessment naming what should be fixed before it fails.
Stabilise
The backlog of known defects and overdue updates is cleared in priority order, with monitoring added where incidents were being discovered by users rather than by alerts.
Run
Support against the agreed response times, scheduled preventive maintenance, and a monthly review with the numbers behind it.
Plan ahead
A rolling twelve-month view of what is coming out of support, what is approaching a capacity limit and what needs budget, so upgrades are planned rather than triggered.
Deliverables
06 items- Support agreement with severity definitions, response times and escalation contacts.
- Risk assessment and remediation plan for any inherited system.
- Monthly report: incidents, fixes, updates applied, and decisions required.
- Maintained dependency and runtime inventory with end-of-support dates.
- Updated runbooks and monitoring, corrected as the system changes.
- Rolling twelve-month upgrade and capacity plan.
Questions
03 entriesYes, and it is a large part of this practice. We ask for two weeks of familiarisation and access to the repository and environments first, and we will tell you honestly if the system is in a state where a support contract would be a fiction. Occasionally the right advice is a short remediation project before any support agreement makes sense.
Maintenance is keeping the agreed behaviour working: defects, updates, performance, capacity, and the environment around it. New behaviour is a change request, estimated separately. The boundary is written into the agreement with examples, because it is the thing these arrangements argue about.
The standard contract is one hour for a system-down severity one during business hours with a four-hour target restoration, next business day for severity three, and out-of-hours cover as a priced option. Those are commitments in the agreement, not aspirations, and the monthly report shows whether we met them.
Book a consultation
01 locationsComplete IT, software and AI solutions
- Indore, India