DEV Community

Cover image for Software Maintenance and Support: What Happens After Go-Live?
Sanjay Katariya
Sanjay Katariya

Posted on

Software Maintenance and Support: What Happens After Go-Live?

The software is live. The build team has moved on. Now, who owns it?
The riskiest point in a custom software project may not be launch.
It may be month seven.
The warranty has expired. The delivery team is working on something else. Nobody has clearly decided who owns the live system.
Nothing has failed yet.
That is what makes it dangerous. Pasted text
Maintenance Is More Than Fixing Bugs
Software maintenance keeps a working system working.
Corrective maintenance fixes discovered problems. Adaptive maintenance keeps the system compatible as browsers, operating systems, APIs, SDKs and other dependencies change. Perfective and preventive work improve the system or address issues before they surface. Pasted text
Your software can need maintenance even when nothing appears broken.
Which Support Model Fits?
There are four common approaches:
Warranty — Covers defects against the agreed scope for a fixed period after launch.
AMC — Provides ongoing corrective fixes, dependency updates and agreed minor changes.
Retained hours — Gives you a monthly engineering block that can be directed toward fixes or improvements.
Managed service with SLA — Adds monitoring, incident response, on-call coverage and contractual response and restoration targets. Pasted text
The simplest test is downtime tolerance.
If four hours offline is inconvenient, an AMC may be enough.
If four hours offline stops invoicing, orders or field operations, you need clearly defined SLA coverage. Pasted text
What Should an SLA Actually Tell You?
A useful SLA should define severity in business language.
S1 Critical: Core operations cannot continue.
S2 High: A core process is seriously degraded.
S3 Medium: A secondary function fails, but work can continue.
S4 Low: Cosmetic issues, questions or minor changes.
And one distinction matters:
Response is not resolution.
A response means an engineer has acknowledged the incident and started work. Resolution means the service has actually been restored, potentially through a workaround. Pasted text
AI Needs Another Layer of Support
Traditional application support asks:
Did the software run?
AI operations must also ask:
Was the answer right?
An AI application can be technically healthy while producing the wrong output. That means monitoring needs to extend beyond uptime and error rates to output quality, evaluation results, fallback rates and model behaviour. Pasted text
The Question to Ask Before the Build Team Leaves
Whatever support model you choose, clarify ownership.
Keep documentation current. Maintain incident runbooks. Have a named engineer who understands the system—and a named backup who can step in. Pasted text
Because the biggest post-launch risk is not always broken software.
It is software that still works, but nobody owns.
At Accucia, that is why we prefer defining warranty, corrective maintenance, adaptive maintenance and new feature work separately instead of hiding everything inside one support line item. Pasted text
How does your organisation handle software ownership once the original build team moves on?

read full blog

Top comments (0)