Service · Legacy Modernisation
Application maintenance and support, with an audit trail.
Senior engineers keeping production systems healthy: SLAs by severity, change control that produces evidence, security patching against a clock, and a monthly report your board can read. Built for regulated software, where "we fixed it" has to come with proof of how.
What do application maintenance and support services include?
Application maintenance and support keeps a production system healthy after the build team has moved on: fixing incidents, applying security patches, keeping the application working as its platforms and dependencies move, and shipping the small improvements that stop a working system from rotting. The software-maintenance literature splits it into four categories, and a real service covers all four.
We run this for systems that carry compliance weight: the platforms behind regulated businesses and the portfolio-company systems that have to look tidy in the next diligence pass. Often for systems we did not build, and sometimes for systems nobody still at the company built.
The scope
What are the four types of software maintenance?
Corrective, adaptive, perfective, and preventive: the ISO software-maintenance categories, and a useful audit of any support quote. A contract that only covers the first is an incident-response service wearing a maintenance label.
Corrective
Fixing what breaks: incidents, defects, and the failures users report. The visible tip of the work; Lientz and Swanson's classic maintenance studies put it near a fifth of the total.
Adaptive
Keeping the application working as its environment moves: OS and runtime upgrades, dependency EOLs, API changes in the systems it talks to, certificate and credential rotation.
Perfective
The small improvements that keep a system worth using: performance fixes, usability snags, minor features. Batched into a backlog and shipped on a cadence, never as drive-by changes.
Preventive
Work that stops future incidents: monitoring and alerting, security patching against a CVE clock, test coverage on the paths that matter, documentation of the things only one person knows.
The regulated version
What changes when the application is regulated?
In a regulated business the support function is part of the compliance surface. The work is the same four categories; what changes is that every one of them has to leave evidence.
Change control that produces evidence
Every change reviewed, ticketed, versioned, and reversible, with a record an auditor can walk without an engineer interpreting. The audit trail is an output of the process, never a reconstruction after the request.
Patching against a clock
Security updates applied inside defined SLAs by severity, with proof of when each landed. An unpatched critical CVE in a regulated system is a finding; a patch log is the answer.
Compliance windows and freezes
Releases planned around reporting deadlines, audit periods, and regulator-imposed freezes. The support calendar has to know your compliance calendar.
Access on the record
Named engineers, least-privilege access, logged sessions. Who touched production, when, and why is a logged query away; no archaeology required.
How the engagement runs
Read first, then the retainer
We do not accept a pager for a system we have not read. The onboarding read is the same discipline as our modernization method: understand the system, write down the risks, and price the work before committing to it.
Phase 1 · 2-3 weeks · fixed price
Onboarding read
We read the system before we accept the pager: architecture, deploy path, incident history, dependency risks. Output: a runbook, a risk register, and a stabilization list of anything too fragile to support as-is.
Phase 2 · Monthly retainer
Steady state
Defined SLAs by severity (typical starting grid below), monitoring we operate, a monthly report in plain language: incidents, changes, patch status, and the risks we are watching. Senior engineers, not a ticket queue in another timezone.
Phase 3 · Priced per milestone
Improvement backlog
The perfective and preventive work, scoped and priced as discrete milestones outside the retainer. You decide what gets built and when; the retainer never quietly absorbs project work.
The typical starting grid
| Severity | Looks like | Response |
|---|---|---|
| P1 | Production down, or data integrity at risk | Inside 1 hour |
| P2 | Degraded service with no workaround | Inside 4 hours |
| P3 | Impaired, workaround in place | Next business day |
| P4 | Cosmetic issues and minor change requests | Scheduled monthly |
The honest section
When support is the wrong buy
A support retainer is the right answer for a viable system and an expensive way to avoid a decision about a dying one. Three situations where we will point you elsewhere.
The system needs modernizing, and support would just be life support.
If the platform is on our own value-vs-health matrix heading for refactor or replace, a support contract postpones the decision at the price of paying twice. Start with the assessment behind the modernization roadmap instead; support can hold the fort during the work, and that is a different, honest scope.
You need a team, not a service.
If the backlog is mostly new features, you are buying development with a support label on it. Better shapes exist for that, and we will say so on the first call.
The application is being retired inside a year.
Minimal-touch stabilization and a decommissioning plan cost less than a support contract. The cheapest incident is the one in a system you switched off.
Receipts
Systems we keep healthy in exacting environments
Live across 20+ financial institutions
A sanctions-compliance platform operating under financial-crime scrutiny: the change-control, evidence, and release discipline on this page is the discipline that system runs on.
Read the case study NASA / JPL · PIXLISERun cost held at $900/mo
The Mars-rover science platform we built and keep running: preventive engineering took the cloud bill from $3,500 to $900 a month, and operational discipline keeps it there.
Read the case studyFrequently asked
Questions we get
What is included in a typical application support contract?
Four categories of work, in the ISO software-maintenance framing: corrective (fixing failures), adaptive (keeping the application working as platforms and dependencies move), perfective (small improvements), and preventive (patching, monitoring, and documentation that stop future incidents). A real service also includes incident response with defined SLAs, a monthly plain-language report, and runbooks so knowledge does not live in one head.
How much does application maintenance cost?
The industry rule of thumb is 15-20% of the original build cost per year, but treat that as a sanity check, not a quote. What actually drives our pricing: the system's fragility (found in the onboarding read), the SLA you need, and the compliance overhead of your environment. The retainer is a fixed monthly figure agreed after the read, and improvement work is priced separately per milestone, so the retainer never creeps.
What is the difference between application support and application managed services?
Scope and ownership. Support keeps a defined application healthy: incidents, patches, small changes. Application managed services (AMS) usually means outsourcing the whole application function, roadmap included, to a vendor. We deliberately sell the first: your team keeps ownership and direction, we keep the system healthy and hand you the evidence trail.
Can you support a system your team did not build?
Yes; most of the systems we support were built by someone else, sometimes someone long gone. That is what the onboarding read is for: the code gets read, the deploy path mapped, a rollback tested, and the runbook written before any retainer starts. If the read finds something too fragile to support responsibly, you get a stabilization list with prices before the retainer starts.
Do you support applications outside regulated industries?
Yes. The page leads with the regulated version because that is where the discipline matters most and where we are most at home, but the same process runs for any production system whose downtime costs real money. The audit trail does not hurt anyone; it is just non-negotiable when a regulator can ask for it.
When is a support contract the wrong answer?
When the system actually needs modernizing. Support keeps a viable system healthy; it cannot make a dying one viable, and a retainer on a platform that needs replacing is money spent twice. Our application modernization roadmap covers how we make that call with a scored portfolio rather than a feeling.
Start with the onboarding read.
Two to three weeks, fixed price agreed before we start. You get the runbook, the risk register, and the stabilization list with prices, whether or not the retainer follows. If the read says the system needs modernizing rather than supporting, that is what the report will say.