Software Development
Application Support & Maintenance
Ongoing support, updates, and enhancements for applications an agency depends on.
What this covers
Applications need patches, dependency updates, minor enhancements, and someone to call when they misbehave. HQT provides ongoing support for applications we built and for applications an agency inherited.
Typical activities
- Onboarding and knowledge capture for existing applications
- Defined service levels for incidents and requests
- Regular dependency and security updates
- Small enhancements delivered through a managed backlog
- Monitoring and performance management
- Periodic health reviews and roadmap recommendations
What you receive
A support agreement with named contacts and service levels, a maintained application, and regular reporting on incidents, changes, and recommendations.
Considerations for public agencies
Support agreements are structured to fit annual budgets, with fixed monthly fees for defined scope and clear rules for work outside it.
Signals that an application has outgrown informal support
Agencies rarely plan to buy support. They recognize the need after something breaks. The common signals:
- One person, a staff developer or a contractor who has rolled off, is the only one who can deploy the application or explain how it works.
- The runtime, framework, or database version has passed its vendor support date, so security fixes are no longer published for it.
- No one can say who gets called at night, or the answer is a person's name rather than a role.
- A browser release, an identity provider change, or a payment processor migration has broken a workflow the agency never touched.
- Change requests sit in a program manager's inbox because no funded path exists to schedule them.
One of these is manageable. Several together usually mean the next incident gets handled by whoever is available rather than by whoever understands the system.
Boundaries to settle with the vendors around the application
Most agency applications sit between a commercial platform, an identity provider, a hosting environment, and an internal help desk, each with a different owner and a different contract. Three boundaries belong in writing before support starts.
The help desk. Decide which tier the support provider picks up. Many agencies keep tier one with their own service desk, route application defects outward, and agree how a ticket crosses between two ticketing systems, including who talks to the person who reported it.
Integrated platforms. When the application exchanges data with an ERP, permitting, records, or payment system, a failure may belong to the other vendor. Agree on a joint triage path so a case is not closed on both sides for lack of evidence.
Infrastructure. Patching a managed cloud service, an operating system, and application dependencies are three different jobs. Name who performs each, who owns the maintenance window, and who can decide to roll back.
Terms that decide whether a support scope holds up
- Severity defined by what the public or staff cannot do, with response and restoration targets stated separately.
- A split between corrective, adaptive, perfective, and preventive work, the categories used in software maintenance standards such as ISO/IEC 14764. Fixing a defect, keeping pace with a platform change the agency did not choose, and improving something that already functions carry different obligations.
- Patch timelines tied to vulnerability severity and to the agency's own security policy rather than to a flat cadence.
- Accessibility regression checks after changes, since web content and mobile applications of state and local government are covered by a Department of Justice rule under Title II of the ADA that sets a WCAG conformance level, with compliance dates that depend on the size of the entity.
- Personnel screening matched to the data the application holds, with notice to the agency before named staff change.
- Repositories, pipelines, and cloud accounts held in the agency's own tenancy, so the code and the means of deploying it stay with the agency at the end of the term.
- Transition assistance defined as a period of documented handover, on termination for convenience as well as at expiration.
What the reporting should show
Activity counts show effort. These show the condition of the application:
- Time to restore service, tracked separately from time to acknowledge.
- Repeat root causes. The same cause returning means the first fix was a workaround.
- Dependency currency, reported as a list of components inside or outside their support windows rather than as a single score.
- Backlog age, which shows whether enhancement capacity is being used or quietly spent on incidents.
- Depth of coverage: more than one person able to deploy, restore from backup, and rotate credentials, verified in a drill rather than asserted.
Settling these measures before the first reporting period makes the arrangement easier to renew, rebid, or end on evidence.
Working with HQT on this
HQT scopes this kind of work as a fixed-price or time-and-materials engagement with a written statement of work, named staff, and a defined acceptance process. We are candid about what we can take on and prefer a well-run project to an oversized one. Contact us to discuss a requirement, a draft scope, or an upcoming solicitation.
Frequently asked questions
What is the difference between a software warranty and an application support agreement?
A warranty is normally a defined period after acceptance during which the developer corrects defects against the agreed specification at no additional cost. Support covers what comes after, including work caused by changes the agency did not make, such as browser, operating system, identity provider, or payment platform updates. Warranty scope is narrow and time limited, while support is a continuing service with its own service levels and funding source. Agencies often write both into one contract, with the support term starting when the warranty ends.
What does an agency need to provide before support can start on an application another vendor built?
The agency needs to supply access to the source repository or a copy of the source, the hosting environment, the build and deployment path, and the integration endpoints with the names of their owners. Whatever documentation exists helps, and the gaps in it are worth recording as findings rather than leaving them to be discovered during an incident. The agency also needs to confirm that it holds the rights to the code and to understand the license terms of any third party components. If the source or the build process cannot be reproduced, that finding shapes what support can realistically promise, and rebuilding the deployment path usually becomes the first task.
How much should an agency budget each year for application maintenance?
There is no reliable universal figure, and planning conventions that express maintenance as a share of the original build cost vary widely by application type. The practical drivers are the number of integrations, the pace of regulatory change, the size of the user population, the age of the technology stack, and the availability the agency expects. A more defensible approach is to price the defined scope, such as monitoring, patching, and a set enhancement capacity, then hold a separate allowance for work outside it. That produces a number the finance office can explain rather than a rule of thumb.
Does an application support contract have to be rebid every year?
That depends on the jurisdiction's procurement rules and on the terms of the contract itself. Many state and local agencies award a base year with option years, subject to annual appropriation, so the agreement continues without a new solicitation as long as options are exercised and funds are available. Some jurisdictions also allow support to be bought through cooperative or master agreements where their rules permit it. Confirm the route with your purchasing office before scoping, since it affects term length, renewal timing, and how transition assistance is written.
What changes about application support when the system holds criminal justice, health, or federal tax data?
The requirements attach to the people and the access, not only to the software. Criminal justice information brings fingerprint-based background checks, security awareness training, and a signed security addendum for contractor personnel; protected health information generally requires a business associate agreement; and federal tax information carries the contractor conditions in IRS Publication 1075, including limits on where access may occur. Support access is normally routed through agency issued accounts with logging, so shared vendor credentials do not meet the requirement. Settle these points before support begins, since they affect who can be staffed, how quickly they can respond, and cost.