Software Maintenance and Support: Choosing the Right Model

The riskiest month of any custom build is month seven. The project team has moved on, the warranty has expired, and nobody has decided who owns the system.

Nothing has failed yet.

That is what makes it dangerous.

What software maintenance services actually cover

Software maintenance services keep a working system working. They are not a slower version of the build.

ISO/IEC/IEEE 14764:2022, the international standard for software maintenance, separates the work into named types.

Corrective maintenance is modification of a software product performed after delivery to correct discovered problems.

Adaptive maintenance is modification to keep a software product usable in a changed or changing environment.

Perfective maintenance improves performance or maintainability.

Preventive maintenance corrects latent faults before they surface.

Additive maintenance adds functionality.

Notice that only one of those is fixing bugs. The other four are work you will need even in a year where the software never breaks.

The four kinds of work that get bundled and should not be

Most support disputes we see are not about quality. They are about a single number covering four different obligations.

Warranty. Defects measured against the signed scope, found within a fixed window after go-live. This is included in the build. It is not maintenance and it does not renew.

Corrective maintenance. Faults found after the warranty window closes, including faults caused by data volume, edge cases nobody tested, or a user doing something reasonable that the build did not anticipate.

Adaptive maintenance. The system did not change. Everything around it did. Operating systems, browsers, mobile SDKs, payment gateways, tax rules, certificate expiries and library versions all move on their own schedule. Skip this for a year and you get a catch-up project instead of a quiet upgrade.

New feature work. Anything that did not exist at handover.

When these four sit under one line item, every request becomes an argument about which bucket it belongs to.

Write them as four scopes in one contract. Give each its own definition, its own approval route and its own budget line.

We would not sign a support agreement that does not do this, and we would tell you not to sign one either.

The month seven problem

Here is how it usually goes.

The build lands in month one. Warranty runs to month four. The delivery team rolls onto the next project in month five.

In month six somebody applies a routine platform update.

In month seven a scheduled job fails silently for eleven days and nobody notices, because the person who knew what that job did has left the account.

The system is not broken in month seven.

It is unowned.

Unowned systems degrade quietly: alerts route to a mailbox nobody reads, credentials expire, backups run but are never restored to test, and the documentation drifts from the code.

The commercial damage is worse than the technical damage.

When the first real incident arrives in month nine, you are negotiating a support contract under pressure, with a vendor who has to re-learn your system before they can help.

That is the most expensive moment to buy support.

The adoption gap that kills enterprise software usually opens here, not at launch.

Comparing the four support models

There are four common ways to structure software support after go-live.

Warranty only

What it covers: Defects against the signed scope, found inside a fixed window after go-live.

What it excludes: Anything outside the signed scope, including new features, data corrected after user error and third-party outages.

How it is priced: Included in the build, with no separate charge.

Best fit: Simple internal systems with a stable user base and no compliance exposure.

Annual Maintenance Contract (AMC)

What it covers: An agreed annual scope including corrective fixes, platform and dependency updates, and minor changes.

What it excludes: New features beyond the agreed change budget, major version upgrades and new integrations.

How it is priced: A percentage of the original build value, agreed at contract signature.

Best fit: Stable line-of-business systems where change is predictable.

Retained hours

What it covers: A block of engineering hours each month, spent as you direct.

What it excludes: Nothing by definition, but unused hours usually lapse and urgent work competes with planned work.

How it is priced: A rate per hour or per day against a committed monthly block.

Best fit: Systems that are still evolving, where you want to control what gets built next.

Managed service with SLA

What it covers: Everything in an AMC plus monitoring, on-call cover, incident response and contractual response and restore targets.

What it excludes: Cloud or hardware infrastructure charges, work outside the supported application and changes you have not approved.

How it is priced: A monthly fee set by cover hours, severity targets, system complexity and estate size.

Best fit: Systems the business genuinely cannot run without for more than a few hours.

The honest test is downtime tolerance.

If four hours offline on a Tuesday is an inconvenience, an AMC is enough.

If four hours offline stops invoicing or field crews, you need an SLA, and paying AMC money for SLA expectations will end badly for both sides.

What an SLA should promise, and how to read one

An SLA is only as good as its severity definitions, and most are written by engineers for engineers.

Yours should be written so that a branch manager can classify a ticket correctly at 9pm without calling anyone.

This is the block to copy into your RFP.

S1 Critical

What it means for your business: The system is down, or a core process cannot run at all. Orders cannot be taken, invoices cannot be raised, field staff cannot log a job. No workaround exists.

First response: 30 minutes, 24x7.

Restore or workaround: 4 hours.

S2 High

What it means for your business: A core process runs but is degraded, or the only workaround is manual and costly. One site, branch or department is blocked.

First response: 2 hours within cover hours.

Restore or workaround: 1 working day.

S3 Medium

What it means for your business: A secondary function is broken. Work continues with a reasonable workaround. Reporting, exports or a non-blocking screen may be affected.

First response: 1 working day.

Restore or workaround: 5 working days.

S4 Low

What it means for your business: Cosmetic defects, minor usability issues, questions and small change requests. Nothing is blocked.

First response: 3 working days.

Restore or workaround: Next scheduled release.

Four things to check before you sign one.

Response is not resolution. Response is a named engineer acknowledging and starting. Resolution is service restored, which may legitimately be a workaround.

Vendors who quote only response times are quoting the easy half.

For reference, AWS publishes a first response target of under 15 minutes on its Enterprise Support plan for its highest severity tier, and under 24 hours for general guidance.

Cover hours in your timezone. "Business hours" means nothing across borders. Write IST, GST or the client's local zone, and write the public holiday calendar that applies.

Escalation with names. Level one, level two, and a director with a mobile number, each with a time after which the ticket moves up automatically.

A consequence. Service credits against the next invoice are standard. A credit that is trivial to the vendor changes no behaviour. A right to terminate for repeated S1 breaches does.

Who is responsible for what during an incident

This is the question most support contracts answer badly, and it depends entirely on where the system runs.

We deploy in-region on request to AWS, Azure or Google Cloud Platform, with the region chosen to meet your requirement, or to your own on-premise servers.

Infrastructure is billed to you at cost.

On cloud infrastructure we manage for you

Under the AWS shared responsibility model, AWS is responsible for security "of" the cloud and the customer for security "in" the cloud, including the guest operating system, patches and application configuration.

Microsoft publishes the same split for Azure.

In practice we own the application, the guest OS patching, deployment, monitoring, backups and restore testing.

You own commercial decisions, data classification and user access approvals.

Platform-level outages go to the provider under their terms, and we manage that escalation on your behalf.

On your own cloud account

Same technical split, different commercial one.

You hold the billing relationship and the provider support plan.

Our restore targets then depend on your account limits and your provider tier, so the SLA has to say so.

On premise

Microsoft's own guidance is blunt: on premise, you own the entire stack.

Hardware, power, network, physical access and backups are yours.

We can still own the application layer, but an S1 restore target of four hours is undeliverable if a failed disk needs a vendor visit.

Agree hardware response separately, and agree in writing who holds root access and who tests the restore.

Two Indian obligations sit alongside all of this.

CERT-In's directions of 28 April 2022, issued under section 70B(6) of the Information Technology Act 2000, require covered entities to report listed cyber incidents within six hours of noticing them, and to keep ICT system logs securely for a rolling 180 days within Indian jurisdiction.

The Digital Personal Data Protection Rules 2025, notified in November 2025, carry an 18 month phased compliance window and require affected individuals to be informed promptly and in plain language after a personal data breach.

Both obligations sit with you as the entity, not with your vendor.

Your support contract should say who prepares the evidence and inside what timeframe.

On our own position, plainly: ISO 27001 is not held, implementation is underway with an auditor appointed and certification targeted for Q1 2027, January to March.

ISO 9001 is in progress.

We do not hold CERT-In empanelment.

Where an empanelled audit is required, you commission the auditor, we build to the auditor's requirements and implement every finding.

The AI operations layer

If you are running models in production, classic application support does not cover you.

The failure mode is different: the code runs perfectly and the output is wrong.

Classic application support

What you watch: Uptime, error rates, response times and failed jobs.

What "broken" means: The code threw an error or the page did not load.

What triggers work: An alert or a user ticket.

Evidence to close a ticket: Logs, a reproduction, a fix and a regression test.

Who signs off: The product owner.

Change cadence: Scheduled releases.

AI operations

What you watch: Everything monitored in classic application support, plus output quality, confidence distribution, refusal and fallback rates, and cost per call.

What "broken" means: The code ran fine and the answer was wrong.

What triggers work: An alert, a ticket, or a scheduled evaluation run that falls below threshold.

Evidence to close a ticket: Logs, a reproduction, a fix and a regression test, plus a scored evaluation set showing other cases did not degrade.

Who signs off: The product owner plus the risk owner, because a model change alters behaviour across every case.

Change cadence: Scheduled releases plus retraining or prompt changes driven by drift.

NIST's AI Risk Management Framework 1.0 puts this in its core functions: system behaviour is "monitored when in production" under MEASURE 2.4, and MANAGE 4.1 calls for post-deployment monitoring plans covering incident response, override and change management.

That is a standing operational commitment, not a launch checklist.

Price it separately from application support.

The skills, the tooling and the review path are different, and bundling it hides the cost of the thing that actually needs attention.

Knowledge continuity

Support quality is mostly a function of who remembers.

Three things protect that.

A documentation standard, updated as part of the release, not as a quarterly cleanup: architecture, integrations, environment variables, scheduled jobs and what each one does.

Runbooks for the incidents you can predict, written so an engineer who has never seen the system can follow them at 2am.

And a named engineer who has actually touched your code, with a named backup who has shadowed a real incident on your system rather than read about it.

Ask for the names in the contract.

Ask what happens when that person leaves.

A vendor who cannot answer the second question is selling you a queue, not a team.

In eight years and 730+ projects, the accounts that ran smoothly were the ones where the client knew who to call by name.

What to negotiate

Notice period. Mutual, sixty to ninety days on an annual contract. Shorter leaves you uncovered while you procure a replacement. Longer traps you.

Rate protection. Fix the rate card for the contract term and cap the uplift at renewal. Without it, year two is a fresh negotiation with a vendor who knows switching is painful.

Escalation path. Named people, defined timers, and an agreed route to a director on both sides.

Non-solicit. Ours is mutual, twelve or twenty four months, agreed per engagement and always in writing. Mutual matters. A one-way clause tells you how the vendor sees the relationship.

Exit assistance. The clause nobody reads and everybody eventually needs.

Current documentation, runbooks, credential handover, a knowledge transfer window with the named engineer, and a final backup you can restore without help.

Agree the number of handover days when you sign.

Accucia's view

We will not quote a retainer before we have seen the system.

That costs us deals, regularly, to firms who will name a monthly figure on a first call.

We think a number given before anyone has counted your integrations, checked your cover hours and read your incident history is a guess that one side will resent within two quarters.

We would rather spend an hour scoping and give you a number we can hold.

The drivers are set out on our how-we-work page.

We also tell clients when they do not need us.

Plenty of internal systems are fine on a warranty and an occasional adaptive maintenance sprint.

Buying 24x7 cover for a system where a day of downtime costs nothing is money that should have gone into the product.

Where we do argue hard is the split.

One line item covering warranty, corrective work, adaptive maintenance and features is how good relationships end.

Four scopes, one contract, and an SLA whose severity table your branch manager can read.

If you want to see how we structure an engagement before you talk commercials, that is set out in how we work.

When you are ready to scope one, talk to us.

Frequently Asked Questions

What do software maintenance services actually include?

Software maintenance services cover four separate kinds of work.

Warranty fixes for defects against the signed scope. Corrective maintenance for faults found later. Adaptive maintenance to keep the system working as operating systems, browsers and libraries change. And new feature work.

ISO/IEC/IEEE 14764:2022 defines these types formally.

What is the difference between a warranty and an AMC?

A warranty is included in the build price and covers defects against the agreed scope for a fixed window after go-live.

An annual maintenance contract is a separate paid agreement that starts when the warranty ends and covers ongoing corrective and adaptive work for a year.

How is an AMC for custom software usually priced?

An annual maintenance contract for custom software is usually priced as a percentage of the original build value, agreed when the contract is signed.

The percentage moves with system complexity, integration count, cover hours and expected change volume.

Ask what the percentage buys before you compare two quotes.

What should a software support SLA contain?

A software support SLA should contain severity levels written in business language, a separate first response target and a restore target for each level, cover hours stated in your timezone, an escalation path with named people, reporting frequency, and an agreed consequence when a target is missed.

What is the difference between response time and resolution time?

Response time is how long before a named engineer acknowledges your ticket and starts work.

Resolution time is how long before service is restored, which may be a workaround rather than a permanent fix.

Vendors often quote only response time. Insist that both appear in the contract.

Who is responsible during an incident if the system runs on AWS?

Under the AWS shared responsibility model, AWS secures the infrastructure and the customer remains responsible for the guest operating system, the application and the data.

In practice your support partner handles patching, configuration, monitoring and application recovery, while platform outages are escalated to the provider under their own terms.

What changes if we host on our own servers?

On your own servers you own hardware, power, network, backups and physical access.

Your support partner can still own the application layer, but restore targets have to account for hardware you control.

Agree in writing who holds root access, who takes backups, and who tests the restore.

Do we need support if nothing is broken?

Yes.

Operating systems, browsers, payment gateways, tax rules and third party APIs change whether or not you touch the code.

This is adaptive maintenance under ISO/IEC/IEEE 14764:2022.

A system left untouched for a year usually needs an expensive catch-up project rather than a quiet upgrade.

What are application support services?

Application support services keep a live business application running: monitoring, incident response, defect fixes, user queries, minor configuration changes and platform updates.

They differ from development, which builds new capability.

Most disputes start when one contract covers both and neither party wrote down where support ends.

How is AI operations different from application support?

Classic application support asks whether the code ran.

AI operations also asks whether the answer was right.

It needs an evaluation set, thresholds, drift monitoring, retraining or prompt change triggers, and a human review path.

NIST's AI Risk Management Framework calls for post-deployment monitoring plans.

What notice period should a support contract have?

Ask for a mutual notice period of sixty to ninety days on an annual contract.

Anything shorter leaves you without cover while you procure a replacement. Anything longer traps you.

Pair it with rate protection for the contract term so renewal is not a fresh negotiation.

What happens to our system if we end the contract?

A support contract should name exit assistance as a deliverable: current documentation, runbooks, credential handover, a knowledge transfer window with the named engineer, and a final backup you can restore independently.

Agree the number of handover days when you sign, not when you are leaving.