Launching software is not the end of the project.

Once an application is live, it still needs support, security updates, bug fixes, monitoring, infrastructure maintenance and compatibility updates.

A software maintenance and support agreement defines what happens after development is complete.

It should make clear:

• What is supported
• What maintenance is included
• How incidents are handled
• What service levels apply
• What counts as a bug
• What counts as new development
• Who is responsible for the system
• What is excluded
• How additional work is priced
• How the relationship can be ended

The objective is simple:

Define exactly what "support" means before a production problem occurs.

This is the thirteenth guide in our documentation series covering the full software project lifecycle: the documentation checklist, technical documentation, the architecture document, the requirement document, the scope document, requirements vs scope vs specifications vs SOW, acceptance criteria, what information a client should provide, questions to ask before hiring a development company, how to compare proposals, the Statement of Work, and the handover document. Where the handover document covers the moment responsibility transfers, this one covers what happens in every month after that.

---

Quick Answer: What Should a Software Maintenance Agreement Include?

Area	What It Should Define
Covered Software	Applications, environments and infrastructure
Services	Support, bug fixing, maintenance and monitoring
Support	Channels, hours and emergency coverage
Incidents	Severity levels and escalation
SLA	Response, restoration and resolution targets
Bugs	What qualifies as a covered defect
Maintenance	Security, dependency, compatibility and performance work
Operations	Infrastructure, monitoring, backups and deployment
Third Parties	External services and integration changes
New Development	Features and change-request process
Responsibilities	Client and provider obligations
Exclusions	Work outside the agreement
Commercial Terms	Fees, included capacity and additional rates
Ownership	Code, data, infrastructure and new work
Exit	Termination and final handover

---

What Is a Software Maintenance and Support Agreement?

It is an agreement that defines how a software system will be supported and maintained after launch.

It may cover:

• Corrective maintenance
• Preventive maintenance
• Security updates
• Compatibility updates
• Performance improvements
• Monitoring
• Incident response
• Technical assistance

It can be standalone or part of a broader contract, SOW or service arrangement.

---

Software Support vs Software Maintenance

Software support

Focuses mainly on operational problems.

Examples:

• Users cannot log in
• A payment fails
• The application is unavailable
• A report is not generating

Software maintenance

Keeps the system secure, reliable and compatible over time.

Examples:

• Updating dependencies
• Applying security patches
• Upgrading runtimes
• Refactoring
• Updating third-party integrations

A strong agreement should define both.

---

1. Define the Covered System and Services

Start by identifying exactly what the agreement covers.

For a SaaS platform, this might include:

• Customer application
• Admin portal
• Backend APIs
• Production database
• Background jobs
• Payment integration

Also specify whether the agreement includes:

• Development
• Testing
• Staging
• Production
• Infrastructure
• Mobile applications
• Third-party integrations

Then define the actual services included, such as:

• Bug fixing
• Monitoring
• Security maintenance
• Dependency updates
• Deployment support
• Performance maintenance
• Technical assistance

Do not assume every system associated with the original project is automatically covered.

---

2. Support Channels, Hours, Severity and SLA

Support expectations should be measurable.

Define:

• Support channels
• Support hours
• Time zone
• Working days
• Emergency coverage
• Incident severity
• Response targets
• Restoration targets
• Resolution targets

A practical severity model is:

Severity	Example
Critical	Production unavailable for all users
High	Core business function unavailable
Medium	Important feature affected with workaround
Low	Minor or cosmetic defect

Response, restoration and resolution are different.

Response time is how quickly the provider acknowledges or starts investigating.

Restoration time is how quickly normal service is restored.

Resolution time is how quickly the underlying problem is permanently fixed.

Example SLA targets might be:

Priority	Response Target
Critical	30 minutes
High	2 hours
Medium	1 business day
Low	2 business days

These are illustrative targets. Actual commitments should reflect the system, support model and commercial agreement.

---

3. Bugs, Maintenance and Change Requests

One of the most important boundaries is the difference between a defect and new development.

A useful definition is:

A bug is a reproducible failure of agreed functionality that materially deviates from the approved or accepted software behaviour.

For example:

Bug: An approved checkout process calculates the wrong tax.

New feature: The client wants to introduce a completely new tax calculation system.

Maintenance can also be divided into:

Corrective maintenance

Fixing defects and regressions.

Preventive maintenance

Reducing future problems through refactoring, dependency updates and optimization.

Adaptive maintenance

Keeping software compatible with changes in browsers, operating systems, cloud platforms or third-party APIs.

Security maintenance

Applying patches and addressing vulnerabilities.

The agreement should state which of these are included.

New features, major redesigns, large migrations and significant architecture changes should normally follow a separate change-request process:

1. Client submits the requirement.
2. Provider classifies the work.
3. Estimate is prepared if required.
4. Client approves it.
5. Development and testing begin.
6. The change is deployed.

---

4. Infrastructure, Security, Monitoring, Backups and Third Parties

Operational responsibilities should be grouped together because they are closely connected.

Define who is responsible for:

• Cloud infrastructure
• Servers and containers
• Databases
• DNS and SSL
• Application monitoring
• Infrastructure monitoring
• Error tracking
• Alerts
• Backups
• Restoration
• Deployment
• Security patches
• Vulnerability response
• Production access

For example, the client may own the cloud account while the development company manages application infrastructure inside it.

The agreement should also define third-party responsibility.

Typical dependencies include:

• Payment providers
• Email services
• SMS providers
• Authentication providers
• Cloud services
• Analytics
• Search
• AI providers

Clarify what happens when an external provider changes an API, retires a service or experiences an outage.

A routine compatibility update may be included.

A major replacement or migration may require a separate project.

---

5. Client Responsibilities, Provider Responsibilities and Exclusions

Support works only when both sides understand their responsibilities.

Client responsibilities

The client may need to provide:

• Required access
• Timely approvals
• Test accounts
• Reproduction steps
• Third-party credentials
• Business decisions
• Infrastructure permissions

Provider responsibilities

The provider may be responsible for:

• Incident investigation
• Bug fixing
• Maintenance releases
• Monitoring
• Security updates
• Deployment support
• Technical documentation

The agreement should also identify exclusions, such as:

• New features
• Major redesigns
• Large data migrations
• Major architecture changes
• Unsupported legacy systems
• Hardware problems
• Third-party outages
• Unauthorized system modifications

Both sides should understand how missing access or delayed approvals affect service targets.

---

6. Emergency Response and Escalation

Critical incidents require a defined process.

Specify:

• Emergency contact
• Incident owner
• Technical escalation levels
• Management escalation
• Client communication
• Status-update expectations
• Recovery process

For major incidents, a root cause analysis may be required.

It should cover:

• What happened
• Customer or business impact
• Technical cause
• Recovery actions
• Permanent fix
• Preventive action

This is especially important for systems where downtime has significant business consequences.

---

7. Commercial Terms, Warranty and Ownership

The commercial model should be explicit.

Common options include:

Fixed monthly retainer

Recurring fee for defined services or capacity.

Time and materials

Billing based on actual engineering effort.

Support-hour package

A defined pool of support capacity.

Hybrid

Recurring support plus separate charges for additional development.

Define:

• Fees
• Included hours or capacity
• Overage rates
• Billing cycle
• Payment terms
• Emergency pricing where applicable

Also distinguish warranty from maintenance.

Warranty

Usually covers defects in delivered software for a defined period.

Maintenance and support

Covers ongoing operational support after or alongside the warranty period.

The agreement should also clarify ownership of:

• Source code
• New code
• Documentation
• Client data
• Infrastructure
• Third-party components

These terms should remain consistent with the original SOW and contract.

---

8. Documentation, Reporting and Technology Changes

Ongoing maintenance can change the system, so documentation should remain current.

Depending on the project, this can include:

• Architecture documentation
• API documentation
• Deployment procedures
• Runbooks
• Operational procedures

A support report may include:

• Tickets received
• Tickets resolved
• Major incidents
• SLA performance
• Maintenance performed
• Outstanding issues
• Planned work

The agreement should also explain how technology upgrades are treated.

Routine updates such as minor dependency or runtime changes may be included.

Major modernization—such as migrating a legacy application to a different architecture—may require separate estimation.

For AI applications, specifically clarify responsibility for:

• Model-provider changes
• Prompt updates
• Retrieval quality
• Knowledge-base maintenance
• Evaluation
• AI monitoring
• Usage and cost controls

---

9. Performance and Capacity

For important applications, maintenance may include monitoring:

• Response times
• Database performance
• CPU and memory
• Storage
• Traffic
• Queue depth

But monitoring performance is different from redesigning the application for significant growth.

For example:

Monitoring database performance may be included in maintenance.

While:

Re-architecting a system to support ten times the current traffic may be a separate project.

This distinction helps prevent major engineering work from being treated as routine support.

---

10. Exit and Handover

A maintenance relationship should not create permanent vendor dependency.

Define what happens when the agreement ends.

The exit process may include:

• Source-code confirmation
• Documentation transfer
• Account and access transfer
• Open issue list
• Support history
• Knowledge-transfer sessions
• Final operational handover

The receiving team should be able to continue operating the system after the support relationship ends.

For the full breakdown of what a proper technical handover requires, see what should be included in a software development handover document.

---

Practical Maintenance and Support Agreement Structure

A reusable agreement can follow this structure:

1. Parties and agreement information
2. Covered software and services
3. Support channels, hours and SLA
4. Incident severity and escalation
5. Bugs, maintenance and change requests
6. Infrastructure, security and monitoring
7. Backups and third-party services
8. Client and provider responsibilities
9. Exclusions
10. Commercial terms
11. Warranty
12. Ownership
13. Documentation and reporting
14. Technology upgrades
15. Termination and exit handover

---

Practical Example

Consider a SaaS platform used by hundreds of business customers.

Included

• Production monitoring
• Critical incident support
• Bug fixes
• Security patches
• Routine dependency updates
• Backup monitoring
• Deployment support

Separately estimated

• New features
• Major redesign
• New mobile application
• Major architecture migration
• Large-scale data migration
• New enterprise integration

This simple distinction prevents ongoing support from becoming an undefined development commitment.

---

Common Mistakes

1. "Support Included" Without Definition

The phrase means little without scope, hours and service levels.

2. Defining Only Response Time

Fast acknowledgement does not guarantee fast restoration or resolution.

3. Treating Every Change as a Bug

New requirements should be classified separately.

4. Ignoring Security and Third Parties

Both can create serious production issues.

5. No Client Responsibilities

Support may depend on access, approvals or information from the client.

6. No Emergency Process

Critical incidents need dedicated escalation.

7. Treating Maintenance as Unlimited Development

Routine support and major product development are different services.

8. No Exit Process

The client should be able to change providers without losing control of the software.

---

Software Maintenance Agreement Checklist

Before signing, verify:

Scope & Services

• Covered applications and environments are identified.
• Included maintenance services are defined.
• Exclusions are documented.

Support & SLA

• Support channels and hours are defined.
• Incident priorities are defined.
• Response, restoration and resolution targets are defined.
• Emergency escalation is defined.

Engineering

• Bug definition is clear.
• Feature requests are separate.
• Security maintenance is defined.
• Dependency and compatibility updates are defined.

Operations

• Monitoring responsibility is defined.
• Backup and recovery responsibility is defined.
• Infrastructure responsibility is defined.
• Third-party responsibility is defined.

Commercial & Ownership

• Fees and included capacity are clear.
• Additional work rates are clear.
• Warranty terms are clear.
• Code and data ownership are clear.
• Exit and handover obligations are defined.

---

Ortem Software Maintenance Framework

At Ortem Technologies, post-launch support can be viewed across five practical layers:

1. Keep It Running

Monitoring, incidents and production support.

2. Keep It Correct

Bug fixing and regression handling.

3. Keep It Secure

Security patches, access reviews and vulnerability response.

4. Keep It Compatible

Framework, runtime and third-party compatibility updates.

5. Keep It Improving

Performance improvements, refactoring and new features.

The first four are primarily operational maintenance.

The fifth often becomes product development and should be commercially separated where appropriate.

---

How Can Ortem Technologies Support Your Software After Launch?

Launching your product is only the beginning. The real test is whether it remains stable, secure, scalable and supported as your business grows.

If you already have a software product that needs reliable ongoing maintenance, Ortem Technologies can help with:

• Production support and incident resolution
• Application and infrastructure maintenance
• Security and dependency updates
• Performance and scalability improvements
• Third-party API and integration maintenance
• Cloud and deployment support
• AI application maintenance and optimization
• Ongoing engineering and feature development

Whether you are looking for a long-term technology partner, a dedicated maintenance team, or a replacement for an existing development vendor, the first step is to understand the current state of your software.

Talk to Ortem Technologies about your application, existing support arrangement and upcoming requirements. We can help you identify support gaps, define the right maintenance model and build a practical post-launch engineering plan.

Start a Software Maintenance & Support Conversation →

---

Final Takeaway

A production application needs more than an original development team and a promise of support.

It needs clearly defined responsibilities.

A strong maintenance agreement explains:

What is covered

Who responds

How quickly they respond

What counts as a bug

What requires additional development

How security and infrastructure are handled

How emergencies are escalated

What each side is responsible for

What happens when support ends

The most useful question is:

When something breaks after launch, does the agreement clearly tell both sides what happens next?

If the answer is yes, the maintenance relationship has a strong foundation.

At Ortem Technologies, we believe post-launch support should be treated as an operational responsibility, not an undefined promise.

Clear maintenance terms help both the client and development partner manage expectations, control costs and keep software reliable over the long term.

Once the terms are defined, the next question is naturally what they should actually cost — see our guide to how much software maintenance and support costs.

Talk to us about your maintenance needs →