System Maintenance and Support
Custom software does not stop needing attention at go live. Dependencies age, security advisories appear, the business changes what it needs, and the person who understood the system takes another job. Support arrangements exist so none of that becomes an emergency, and so the knowledge does not leave with an individual.
1
Onboard
Learn the system properly
2
Monitor
Catch it before users do
3
Respond
Against agreed times
4
Maintain
Patch and upgrade
5
Improve
Enhancements under control
How Support Works
01
Onboarding and Knowledge Transfer
Taking over a system we did not build starts with understanding it. We review the code, the architecture and the deployment path, and document what we find, which is frequently more than the original team left behind.
- Code, architecture and dependency review
- Deployment and environment documentation
- Known issues and technical debt register
- Handover from the incumbent team or developer
02
Monitoring and Alerting
The objective is knowing before your users do. We monitor availability, error rates and the background jobs that fail quietly, because a scheduled task that stopped three weeks ago is usually discovered at month end.
- Availability and response time monitoring
- Application error tracking and alerting
- Scheduled and background job monitoring
- Capacity and storage trend alerting
03
Support and Response
Response times are written into the agreement and measured, with severity defined so both sides know what a priority one actually means. Every request is logged and visible to you rather than handled informally.
- Severity definitions agreed in writing
- Response and resolution targets per severity
- Logged, trackable requests
- Monthly reporting on volume and performance
04
Security Patching and Upgrades
Dependencies accumulate vulnerabilities whether or not anyone is looking. We track advisories against your actual dependency list and apply updates on a schedule, testing before release rather than after.
- Dependency vulnerability monitoring
- Scheduled patching with tested releases
- Framework and runtime version upgrades
- End of life planning before support lapses
05
Enhancements and Change Control
Business needs change and the system has to follow. Enhancements are estimated, approved and released through the same tested path as any other change, so improvement does not become the thing that breaks production.
- Enhancement requests estimated before approval
- Prioritisation with the business owner
- Release through the tested deployment pipeline
- Documentation updated as part of every change
What You Receive
- Support agreement with severity definitions and response targets
- System documentation, refreshed at onboarding
- Monitoring and alerting configuration
- Monthly reporting on volume, response and availability
- Scheduled patching and upgrade record
- Change controlled enhancement releases
Indicative Timeline
Support is an ongoing arrangement rather than a project, normally contracted annually with monthly reporting. Onboarding a system we did not build takes two to four weeks before full response targets apply.
- Onboarding and code review: two to four weeks
- Monitoring configuration: one week
- Full response targets: from the end of onboarding
- Reporting: monthly, with an annual review
What Support Covers
A support arrangement is defined by what it includes and, just as importantly, what it does not.
Incident Response
Fixing what is broken, against agreed response and resolution targets by severity.
Security Patching
Tracking advisories against your dependencies and applying tested updates on a schedule.
Platform Upgrades
Framework, runtime and library versions kept current so upgrades never become a rewrite.
Monitoring
Availability, errors and background jobs watched continuously with alerting to a person.
Enhancements
Small changes delivered under change control, quoted and approved before they are built.
Documentation
Kept current with every change, so the system never depends on one person remembering.
Frequently Asked Questions
Can you support software somebody else built?
Yes, and it is common. Onboarding takes longer because we document what we inherit, and we are direct about anything we find that concerns us before agreeing response targets we could not meet.
What response times do you offer?
They are set in the agreement against severity levels defined with you, because a realistic target for a critical outage differs from a cosmetic defect. We would rather agree targets we will meet than quote a number that looks good in a proposal.
What if we want to bring support back in house?
The documentation, the code and the deployment pipeline are yours throughout. We hand over rather than hold anything, and we would rather leave a system a client can run than create a dependency.
Is patching included or extra?
Security patching and dependency upgrades are part of the arrangement. Major version upgrades that amount to a re platforming exercise are scoped and quoted separately, and flagged well before support lapses.
How do enhancements work?
Requested, estimated, approved, then built and released through the same tested path as any other change. Small items are usually absorbed within an agreed monthly allowance; larger ones are quoted individually.
What happens if the system goes down at night?
That depends on the cover you buy. Extended hours and after hours cover are available and priced accordingly. We would rather you chose it deliberately than assume it and discover otherwise during an outage.
Related Services
This sits inside our Systems Development practice. Related work: Custom Software and App Development where the system is built in the first place, and Managed ICT Services if the whole environment needs running rather than one application.
