# Software maintenance and support services

> TechSupport Team provides software maintenance for applications already in production. We repair defects, update dependencies, apply security patches and make preventive changes. We test every change, and emergency fixes receive full regression tests after release.

- Publisher: TechSupport Team
- Canonical page: https://techsupport-team.com/services/software-maintenance/
- Updated: 2026-10-25

TechSupport Team's software maintenance fits teams whose production software needs regular engineering work but not a full development team. Our engineers handle defect fixes, framework and dependency updates, patches and regression tests through your review and release process. Add dedicated engineers to your team, or agree on maintenance capacity in your estimate. Planned maintenance is separate from incident response.

## Software maintenance facts

- **Scope:** Corrective, adaptive, preventive and security changes to production code
- **Includes:** Dependency updates, security patches, regression tests and release support
- **Way of working:** Your repository, your review rules and your pipeline
- **Capacity:** Dedicated engineers in your team, or agreed engineering capacity planned with your product owner
- **Live incidents:** Handled under the [service levels](https://techsupport-team.com/service-levels/), not the maintenance backlog
- **Commercial terms:** Scoped after an assessment. See [pricing](https://techsupport-team.com/pricing/)

## What software maintenance covers

Software support services cover more than bug fixes. TechSupport Team groups maintenance work into five types.

Table: Types of software maintenance work

| Type | What it means | Examples |
| --- | --- | --- |
| Corrective | Fix defects found in production. | A rounding error in invoices; a crash on empty input. |
| Adaptive | Keep the software working when its environment changes. | A third-party API version is retired; a browser changes its cookie rules. |
| Preventive | Remove risks before they cause incidents. | Add a missing index; replace code that fails under load; add alerts. |
| Security | Close known vulnerabilities. | Patch a library with a published CVE (Common Vulnerabilities and Exposures) entry. |
| Upgrades | Move to supported versions. | Upgrade an end-of-life runtime or framework version. |

## Maintenance engineers in your team

Dedicated engineers can join your development or support team for maintenance work. They pick items from your backlog, follow your coding standards and submit changes for your review. See how to [hire support engineers](https://techsupport-team.com/hire/support-engineers/).

## Planned changes and incident response are separate

Table: Planned maintenance compared with incident response

|   | Planned maintenance | Incident response |
| --- | --- | --- |
| Starts with | A backlog item that you prioritize. | An alert or an escalated ticket. |
| Timing | Scheduled into your release cycle. | Starts within the agreed response target. |
| Goal | A tested change that lowers future risk. | Restore service, then find the cause. |
| Testing | Full regression tests before release. | Focused checks; full tests follow in the maintenance backlog. |
| Measured by | Delivered changes and fewer repeat incidents. | Response and restoration against the service levels. |

Urgent defects can skip the queue as emergency fixes. They follow your emergency change process and receive full regression tests afterward. Live incidents are handled by [application support](https://techsupport-team.com/services/application-support/). Use the [incident severity levels template](https://techsupport-team.com/templates/incident-severity-levels/) to document business impact before requesting an emergency fix.

## How a maintenance change reaches production

1. **Prioritize.** Review the backlog with your product owner and agree on the priority of each item.
2. **Reproduce.** Reproduce the defect, or confirm the requirement, in a test environment.
3. **Change.** Change the code on a branch with a test that fails before the fix and passes after it.
4. **Test.** Run the regression suite and any manual checks agreed for the affected area.
5. **Review.** Submit the change for review under your merge rules.
6. **Release.** Release through your pipeline in the agreed window, then verify the result in production.
7. **Close.** Close the item with release notes and any runbook updates.

## Maintenance examples

*Illustrative examples. These are not client case studies.*

### An end-of-life runtime

- **Situation:** The application runs on a language version that no longer receives security updates.
- **What TechSupport Team does:** We list the breaking changes, upgrade the runtime and its dependencies in stages, and run regression tests at each stage.
- **Ownership and approvals:** You approve the release plan and the test sign-off.

### A vulnerable dependency

- **Situation:** A security scanner reports a high-severity vulnerability in an open-source library.
- **What TechSupport Team does:** We check whether the application uses the vulnerable code path, update the library and test the affected features.
- **Ownership and approvals:** Your security team accepts the risk rating and approves the release.

### A recurring incident

- **Situation:** The same timeout incident returns every month during billing runs.
- **What TechSupport Team does:** We trace it to a query that locks a large table, rewrite it to process smaller batches and test it at production volume.
- **Ownership and approvals:** You schedule the release before the next billing run.

### A retiring third-party API

- **Situation:** A payment provider announces the end of an API version that you use.
- **What TechSupport Team does:** We map the changed endpoints, update the integration, test it against the provider's sandbox and plan the switch.
- **Ownership and approvals:** You manage the provider account and approve the switch date.

## What we need from you

- Access to the source repository and the issue tracker.
- A test or staging environment that is close to production.
- Your coding standards, review rules and definition of done.
- A product owner who sets priorities and accepts changes.
- Release windows and an emergency change process.

## Ownership and limits

- Code you own: we change it under your review rules, in your repository.
- Licensed products: we cannot change closed vendor code. We configure it, work around defects and escalate them to the vendor.
- Feature development: new features belong in your development plan. Small enhancements can be agreed as part of maintenance capacity.

## Capacity, service levels and cost

Maintenance is planned as engineering capacity, separate from incident coverage. The [pricing page](https://techsupport-team.com/pricing/) explains how capacity and coverage combine. Incident terms are on the [service levels page](https://techsupport-team.com/service-levels/). New engagements start with the [onboarding phases](https://techsupport-team.com/how-we-work/).

## Questions buyers ask

### What is the difference between software maintenance and software support?

Software support usually means responding to problems. Software maintenance means changing the code to fix defects and reduce future risk. TechSupport Team handles incidents through application support and [L2 (second-level) and L3 (third-level) support](https://techsupport-team.com/services/l2-l3-support/). This service covers planned maintenance.

### Can you maintain software that has no automated tests?

Yes. We add tests around the code we change first, so each fix also adds test coverage. We report the areas without tests as risks in the regular review.

### Do you upgrade frameworks and runtimes?

Yes, as planned maintenance. We assess the upgrade path, list the breaking changes and upgrade in stages with regression tests. A major upgrade receives its own estimate.

### Who owns the code changes you make?

Your agreement sets ownership. Our changes go into your repository through your review process, like any other change.

## Related pages

- [Application support](https://techsupport-team.com/services/application-support/): Live-incident diagnosis and recovery, and the handoff to maintenance.
- [L2 and L3 support](https://techsupport-team.com/services/l2-l3-support/): How L3 engineers fix the causes of escalated incidents.
- [Technologies](https://techsupport-team.com/technologies/): Runtimes, frameworks and databases in scope, and version limits.
- [Pricing](https://techsupport-team.com/pricing/): How maintenance capacity is priced next to coverage.
- [Application support takeover case study](https://techsupport-team.com/case-studies/application-support-takeover/): Taking over an undocumented application after its original developers left.

## Contact

Request engineers from TechSupport Team or ask a question: https://techsupport-team.com/contact/