After Your Software Goes Live: What to Look for in Maintenance, Support and SLAs
When a project goes live, the work is not over; the real responsibility begins. Without security updates, backups, monitoring, bug fixes and small improvements, even the best software ages. We explain the maintenance types, what to check in an SLA and a contract checklist.
In brief: Software is not a product you build once and leave; it is a living system: operating systems, libraries and browsers are constantly updated, security vulnerabilities are discovered and user needs change. That is why maintenance and support are not an “extra expense” but the ongoing running cost needed to keep software secure, fast and working. A good maintenance and support plan states clearly what it covers (bug fixes, security updates, backups, monitoring, small improvements), how quickly you will get a response and how quickly it will be resolved (the SLA), who you will contact and through which channel, and how much it costs. Put these items in writing before you sign the contract.
Last updated: October 2026
Going live is a beginning, not an end
When a new web application, e-commerce site or mobile app goes live, everything looks fine in the first days. But within months, this happens:
- Security vulnerabilities are found in the libraries you use and patches are published.
- Browser and operating system updates can break some features.
- Performance can drop as users and data grow.
- Outages and changes occur in the server, the database or third-party services (payments, email, SMS, maps).
- Your business processes change; new needs arise.
Unmaintained software does not break suddenly “one day”; it slowly ages and becomes risky. Then when a problem occurs, fixing it is both expensive and urgent.
Four types of maintenance
Maintenance is not a single concept; it has four main types:
| Type | Purpose | Example |
|---|---|---|
| Corrective | Fixing bugs as they appear | The order form throwing an error, a wrongly calculated amount |
| Preventive | Taking precautions before problems occur | Security patches, dependency updates, backup tests, capacity monitoring |
| Adaptive | Adapting to a changing environment | A new browser/OS version, a payment provider's API change, a regulation change |
| Perfective | New features and improvements | A new report, screen or integration, performance improvement |
If a quote or contract says “maintenance,” always ask which types are included. Many vendors keep only corrective maintenance under “warranty”; preventive and perfective maintenance are charged separately.
Warranty and maintenance are not the same
- Warranty period: For a set period after delivery (e.g. a few months), defects in the delivered scope are fixed free of charge. New features, changes or problems caused by third parties are mostly out of scope.
- Maintenance and support: A continuing service after the warranty; its scope and fee are set by contract.
Clarify in writing what the warranty start depends on (the launch date or the acceptance date?) and what is left out of scope.
10 elements a maintenance and support plan should contain
1. Security updates and dependency management
Regularly updating the framework, libraries and server components is the most important preventive maintenance. This is how known vulnerabilities are closed. Ask how often they are checked and how critical vulnerabilities are handled. On security, see our web application security guide.
2. Backup and restore
Taking a backup is not enough; you need to test that it can be restored. Clarify:
- Which data is backed up (database, files, configuration)?
- How often (daily, hourly)?
- Where are backups stored; in a location separate from the main system?
- Is restoration tested regularly?
A common principle for backup strategy is 3-2-1: at least three copies of the data, on two different media, with one in a different location.
3. Monitoring and alerts
Your customer should not be the first to notice when the system goes down. A good plan monitors:
- The availability (uptime) of the site/app
- Error logs and unexpected exceptions
- Server resources (CPU, memory, disk)
- Page speed and basic performance indicators
- “Forgotten” dates such as SSL certificate and domain expiry
Who will receive the alerts, and through which channel, should also be written in the plan.
4. The bug-fixing process
How will bugs be reported (email, support panel, phone)? Who will assess them? How will priority be set? How will the fix be tested and released?
5. SLA: response time and resolution time
An SLA (Service Level Agreement) defines measurable commitments for the support service. Do not confuse two times:
- Response time: The time to the first reply to your request.
- Resolution time: The time for the problem to be fixed.
Times are usually defined by priority:
| Priority | Definition | Example |
|---|---|---|
| Critical | The system is completely down, or there is a data/security risk | Site is down, payments cannot be taken |
| High | An important feature is not working and there is no workaround | Orders cannot be saved |
| Medium | A feature is partly affected, there is a workaround | A report is sorted wrongly |
| Low | Cosmetic or a small improvement | A typo, a minor visual issue |
Also ask about working hours (business hours or 24/7?) and how they work on holidays. Being reachable after hours for a “critical” problem can be crucial depending on your type of business.
6. Availability (uptime) target
Some contracts mention a target like “99.9% availability.” Find out what that number measures (does it include planned maintenance?), how it is measured and what happens if the target is not met (service credit, etc.). The target must fit the infrastructure and budget; not every project needs 99.99%, and it is expensive.
7. Disaster recovery: RTO and RPO
- RTO (Recovery Time Objective): After an outage, what is the longest time in which the system is targeted to be working again?
- RPO (Recovery Point Objective): In the worst case, how much data loss is acceptable? (E.g. the last 1 hour.)
These two targets determine backup frequency and infrastructure cost. Discuss in advance the acceptable loss and downtime for your business.
8. Small enhancements and change requests
Does the maintenance package include a monthly hour bank? If not, how are small changes priced? Which requests count as “maintenance” and which as “a new project”? If this line is not clear, disputes follow.
9. Documentation and knowledge transfer
The system's architecture, setup, configuration and critical procedures should be written down. Documentation should be kept current so continuity is ensured even if the team changes; source code, accounts and passwords must be under your control.
10. Reporting
Ask for a short maintenance report monthly or quarterly: updates made, requests resolved, uptime, risks identified and recommendations. This provides transparency and helps you plan future budget.
Maintenance pricing models
| Model | How does it work? | Advantage | Watch out for |
|---|---|---|---|
| Fixed monthly package | A fixed monthly fee for a defined scope and SLA | Predictable budget | The scope must be clear |
| Hour bank | A set number of hours per month; unused hours may roll over or expire | Flexible | Ask about the rollover/expiry rule |
| Pay as you go | A separate quote for each job | Suitable for small/infrequent needs | Priority and price in an emergency may be unclear |
| Dedicated team | A team assigned to the product for a monthly fee | Ideal for continuous development | Oversized for small projects |
As a general rule, if your product is central to your business (e-commerce, SaaS, operations software), a continuous package fits; for a small, static corporate site a lighter plan may be enough. For details on pricing models, see our software project pricing models article.
The real cost of neglecting maintenance
Setting a maintenance budget looks like a cost; but the bill for neglect is usually bigger:
- Security incidents: A vulnerability in a component that is not updated can lead to a data leak; if personal data is involved, legal obligations arise.
- Downtime: Every hour you cannot sell is lost revenue.
- Technical debt: A system that is not updated becomes harder to change as it grows; eventually a big and expensive rewrite may be needed.
- Reputation: A slow, error-prone system affects customer trust and search rankings.
A practical framework: do not leave your annual maintenance and operations budget at zero; set aside a reasonable share according to the product's criticality. The exact ratio varies by project; evaluate the maintenance item in the quote together with its scope and SLA.
Pre-contract checklist
- Maintenance scope is written: which of corrective, preventive, adaptive and perfective are included?
- SLA: are priority levels, response and resolution times and working hours clear?
- Backup: are frequency, storage location and restore testing defined?
- Monitoring and alerts: what is monitored and who is notified?
- Security updates: how often, and what is the time frame for critical vulnerabilities?
- Have RTO/RPO targets been discussed?
- Is an hour bank or a price set for small changes?
- Do documentation and account/code ownership rest with you?
- Are reporting frequency and content defined?
- Are contract term, renewal and termination conditions clear?
We also included the maintenance and support question in our 15 questions to ask when choosing a software company guide, which covers vendor selection as a whole.
Support and maintenance at Aktaş Digital
We know our work does not end when the software we develop goes live. Depending on the project, we offer support and maintenance plans covering updates, backups, monitoring, bug fixes and development; scope and fees are stated clearly in the quote. In continuously running systems such as web applications, SaaS platforms, e-commerce solutions and operations management systems, these plans ensure the product's security and continuity.
Are you looking for maintenance and support for an existing system, or do you want to plan the maintenance from the start for a new project? You can describe your situation through our quote form.
Frequently Asked Questions
Is a maintenance contract mandatory?
It is not a legal requirement; but it is recommended for software that runs continuously and is critical to the business. Without a contract, who you will reach, how quickly, when a problem occurs remains unclear, and the fix usually costs more.
Do I pay a maintenance fee during the warranty?
The warranty covers free fixes of bugs in the delivered scope. Problems caused by new features, changes or interventions on your side are generally out of scope. Read the warranty clause in the contract carefully.
Is an SLA needed for a small corporate site too?
A detailed SLA is often not needed; but it is still important to know who is responsible for backups, security updates and bug reports. A light plan can be enough.
Can I switch to another company for maintenance?
Yes, if the source code, documentation and account access are with you. That is why settling ownership and access at the start of the project preserves your freedom to change the maintenance provider.
Is out-of-hours emergency support a must?
It depends on your business. In a system that sells online or runs 24/7, after-hours access matters for critical problems; for internal systems used only during business hours a more flexible plan may be enough.
How much of maintenance can be done with AI?
Monitoring, log analysis and routine checks can be supported with automation; but security decisions, releases to production and solving critical bugs still require experienced engineering and accountability. Automation speeds the process up; it does not replace it.
Conclusion
Software maintenance is like a car's periodic service: when it is done you do not notice, and when it is neglected it costs dearly. Bind the maintenance types, SLA terms, backup and monitoring arrangements and the pricing model into a written contract, so it is known who is responsible for what after launch. The first thing you can do today: write down the answer to “if a problem occurs, whom do I reach, from where and how quickly?” for your current system and list the gaps.
