Most budgets treat launch as the finish line. Then the system goes live, and the software maintenance cost starts: bug fixes, framework upgrades, security patches, a pager, a cloud bill and a list of small requests that never gets shorter. This article is for the engineering or operations leader who owns a live system and wants to know what that work consists of, what drives its cost, and whether an offshore team in Vietnam is a sensible way to carry it.
A disclosure: we are a Vietnamese vendor. MOHA Software runs delivery from Hanoi, and maintenance is one of the services listed on our offshore development center page. We have tried to be straight about where an offshore maintenance team helps and where it doesn't.
You won't find dollar ranges per month here. Published ranges for maintenance are so wide that they tell you nothing about your system. What you can reason about is the cost drivers, and those are the same for every system.
What software maintenance cost actually covers
The standard reference is ISO/IEC/IEEE 14764:2022, the international standard for software maintenance. Most articles quote four maintenance types from the older edition. The 2022 edition defines five, because it separates adding features from improving what exists.
| Type (ISO/IEC/IEEE 14764:2022) | What the standard means | What it looks like on your backlog |
|---|---|---|
| Corrective | Fixing problems discovered after delivery | Production bugs, data fixes, hotfixes. Emergency fixes count here too |
| Preventive | Fixing latent faults before they show up in the live system | Dependency updates, security patches, replacing a library before it reaches end of life |
| Adaptive | Keeping the software usable in a changed environment | A new OS version, a payment API being retired, a new privacy rule, a cloud service being deprecated |
| Perfective | Improving performance, maintainability or the information users get | Query tuning, refactoring a module everyone is afraid to touch, better error messages and docs |
| Additive | Adding functionality after delivery | Small features and integrations that go through the maintenance queue |
Two of our published projects show what adaptive work looks like in practice. A WiFi finder app for a Japanese client stopped working for users in China, where Google services are blocked. The fix was to replace Google Maps with Mapbox and Firebase Cloud Messaging with Huawei Push Kit while keeping the app working in other regions. Nothing in the app was broken. Its environment changed.
The second is Draco Help, a Romanian panic-button app built on Vue Native, a framework its creators stopped supporting. That meant no more security patches and a shrinking pool of developers who knew it. A three-person MOHA team migrated the app to React Native. Nobody plans for a framework being abandoned, and a maintenance budget has to absorb it anyway.
The standard also leaves something out. It says in its scope that it does not cover the operation of software: backup, recovery and system administration. Your budget has to cover both. So the full list of what you pay for after launch is longer than the five types:
- Engineering time on the five types above.
- On-call and incident response, including the postmortem and the follow-up fixes.
- Monitoring, logging, error tracking and CI/CD tooling.
- Security patching. NIST's SP 800-40 Rev. 4 describes patching as preventive maintenance and "a cost of doing business", which is a fair way to present it to a finance team.
- The cloud bill and third-party licenses.
- Regression testing, so each fix doesn't break something else.
How much of the lifecycle budget goes to maintenance
You will see "maintenance is 60 to 80% of total cost of ownership" and "budget 15 to 25% of the build cost per year" repeated across the web, usually with no source. We could not trace either figure to a current primary dataset, so we don't use them.
Two things can be said with a source behind them.
The standard itself states the direction without a number. Its introduction says maintenance "consumes a major share of a software life cycle financial resources".
The best public data point on scale comes from government. The US Government Accountability Office reported in July 2025 that the federal government spends more than $100 billion a year on IT and that agencies have typically reported spending about 80% of it on operating and maintaining existing systems. That is a budget share across a very old portfolio, including systems more than 50 years old. It is not a forecast for a five-year-old SaaS product. It does show where a portfolio ends up when maintenance is deferred: most of the money goes to keeping old systems alive.
For your own system, the useful number is the split of engineering hours across the five types over the last two quarters. If you can't produce it, start tagging tickets by type. A team spending most of its hours on corrective work has a quality problem. A team spending almost nothing on preventive work is building up one.
In-house vs offshore in Vietnam: the cost drivers compared
The usual in-house vs outsourcing software development comparison is about building. Maintenance changes the math, because the work is steady, partly unpredictable and often lands at night.
Salaries, as market data
The figures below are public salary data. They are not vendor fees and they are not MOHA prices.
| Role on a maintenance team | US median annual wage (BLS, May 2025) | UK median annual pay, full-time (ONS ASHE 2025, provisional) | Vietnam median (ITviec 2025-2026), monthly x 12 | Vietnam as a share of US / UK |
|---|---|---|---|---|
| Software developer | $135,980 | £56,914 | 453.6 million VND, about $18,800 | 14% / 26% |
| QA and testing | $104,300 | £47,118 | 374.4 million VND, about $15,500 | 15% / 26% |
| User support | $61,860 | £35,128 | 240 million VND, about $9,900 | 16% / 22% |
Sources: the US Bureau of Labor Statistics Occupational Outlook Handbook for software developers and QA analysts and computer user support specialists; the UK Office for National Statistics ASHE Table 14 (programmers and software development professionals, IT quality and testing professionals, IT user support technicians); and ITviec's IT Salary & Recruitment Market Report 2025-2026 (back-end developer, QA-QC, IT support/helpdesk). Conversions use the World Bank's 2024 average official exchange rates: about 24,165 dong and 0.78 pounds per US dollar.
Read the last column with care. Job categories don't match exactly across three statistical systems, the UK figures are provisional, and exchange rates move. More important, a salary is not what either side pays.
In-house, salary is only part of the cost. BLS's Employer Costs for Employee Compensation release for June 2026 puts wages and salaries at 70% of what US private employers spend on an employee, with benefits making up the other 30%. Recruiting, equipment, office space and management time come on top of that.
Offshore, a vendor's fee covers the engineer's salary plus the employer's costs in Vietnam, office, equipment, management and margin. The gap between an offshore fee and an in-house hire is real, but it is narrower than the salary ratio suggests.
Coverage hours
This is the driver most cost articles skip, and for maintenance it often matters more than salary.
Google's SRE book works through the arithmetic of a sustainable on-call rotation. With a primary and a secondary engineer on call around the clock, and no engineer spending more than 25% of their time on call, a single-site team needs at least eight engineers. With two sites, the book suggests six at each. It also puts the average effort of handling one incident, including root-cause analysis, the fix and the postmortem, at six hours.
Few companies with one live product have eight engineers to rotate. Two or three people carry the pager, and they are usually the same people who are supposed to ship the roadmap.
Vietnam is on GMT+7 all year. A 9:00 to 18:00 working day in Hanoi lands here:
| Your location | Hanoi 9:00-18:00 in your local time | What that covers |
|---|---|---|
| US East Coast | 22:00-07:00 in summer, 21:00-06:00 in winter | Your night |
| US West Coast | 19:00-04:00 in summer, 18:00-03:00 in winter | Your evening and most of the night |
| London | 03:00-12:00 in summer, 02:00-11:00 in winter | Early hours and your morning |
| Sydney | 12:00-21:00 in winter, 13:00-22:00 in summer | Your afternoon and evening |
| Singapore | 10:00-19:00 | Your working day |
For a US or UK team, engineers in Hanoi are at their desks during the hours when an in-house rotation is asleep. A page at 3 a.m. in New York arrives mid-afternoon in Hanoi. The reverse also holds: US business hours fall in the Hanoi night, so daytime incidents stay with you unless the engagement is set up otherwise. Which hours a team covers and how an incident reaches your people are set per engagement, so ask us about both.
The drivers side by side
| Cost driver | In-house | Offshore team in Vietnam |
|---|---|---|
| Salaries | US and UK medians above | Market salaries at roughly 14-16% of US and 22-26% of UK levels, before vendor overhead and margin |
| Employer costs | Benefits at about 30% of compensation in the US, plus recruiting, equipment and office | Inside the vendor's fee |
| Utilization | Maintenance rarely fills whole people, so it is borrowed from the product team | Capacity can be sized to the load |
| Night and weekend coverage | An on-call rota drawn from a small team | The Hanoi working day overlaps the US night and the UK early morning |
| Knowledge retention | Lives with the people who built the system and leaves when they do | Has to be transferred and written down, then lives with the vendor team unless the documents stay in your repositories |
| Handover | None | A one-time cost, and a slower first period |
| Your management time | A line manager | A named owner on your side for priorities and approvals |
| Cloud and tooling | The same either way | The same either way; you keep paying the providers directly |
The utilization row is easy to overlook. In-house, the cost of maintenance is partly the salary of whoever does it and partly the roadmap work that person did not do. If your best engineers lose a day or two a week to interruptions, that lost time is a larger cost than any salary difference.
Where an offshore maintenance team falls short
- The first period is slower. A new team needs time to learn a system it did not build, and fixes take longer until it has.
- Undocumented systems cost more to hand over. If the knowledge exists only in one person's head, the handover depends on that person's time.
- Daytime incidents in US hours stay with you by default, as described above.
- Very small systems may not justify it. If the load is a few hours a month, the coordination effort can outweigh the saving.
- Some data can't leave. If regulation or a customer contract requires that production access stays in your country, check this before you plan anything.
- You still need an owner. Someone on your side has to set priorities and approve releases. Offshore maintenance moves the work but leaves the accountability with you.
What to keep in-house and what to hand over
Our rule of thumb: hand over work that is frequent, can be described in a ticket or a runbook, and can be undone. Keep work that is rare, depends on business judgment, or can't be reversed.
| Keep in-house | Hand over |
|---|---|
| Product priorities and the order of the backlog | Corrective work: bug triage, fixes, hotfixes |
| Architecture decisions that are expensive to reverse | Dependency, framework and OS upgrades |
| Ownership of cloud accounts, domains and production credentials | Security patching on an agreed cadence |
| Incident command for security breaches, and any regulatory notification | First response to alerts that have a runbook |
| Release approval for high-risk changes | Regression testing and test-suite upkeep |
| Contracts with cloud and software vendors | CI/CD and monitoring upkeep, cloud cost hygiene |
| Small enhancements and documentation |
If you only need one or two extra people inside your existing rotation, staff augmentation fits better than a separate team. If the load is mostly infrastructure, pipelines and cloud spend, look at our cloud and DevOps services and at what to delegate when you outsource DevOps and platform engineering to Vietnam. We compare the engagement models in staff augmentation vs full outsourcing.
How to hand a system over to a maintenance team
A handover goes wrong when it is treated as a meeting. Treat it as a short project with its own deliverables.
- Take inventory. List repositories, environments, cloud accounts, scheduled jobs, third-party services, certificates and domains with their expiry dates. Most teams find something nobody owns.
- Grant access through accounts you issue and can revoke. Keep code and documents in your own repositories.
- Transfer knowledge in recorded sessions: architecture, the deployment path, known weak spots, and the incidents of the past year.
- Have the new team write the runbook. If they can document how to deploy, roll back and restore a backup, they have understood it. If they can't, you have found the gap before production did.
- Shadow. The new team watches your people handle releases and incidents.
- Reverse the roles. The new team handles releases and incidents while your people watch and can step in.
- Move to steady state, with a regular report that splits hours by maintenance type and lists open risks.
Regression testing deserves attention during steps 4 to 6, because a maintenance team that can't test a fix safely will be slow forever. We built an internal tool, Test-case AI, that drafts test cases from a library of ISTQB-based templates and commits them to a repository linked to CI pipelines. Whatever the tooling, ask how the suite will be kept current as the system changes.
How to read a maintenance quote
Application maintenance and support outsourcing is priced in several ways: a monthly retainer of hours, a dedicated team, or per ticket. The model matters less than what sits inside it. These are the questions we expect to answer when you talk to us.
- Which of the five maintenance types are in scope? A quote that covers only corrective work will look cheaper and leave upgrades and patching unfunded.
- Which hours are covered, stated in your time zone, and what happens outside them?
- How is capacity sized, and what happens to hours you don't use in a quiet month?
- Who decides how severe an incident is, and how does it reach your on-call person?
- Is the handover priced separately or included?
- What is excluded? Cloud bills, licenses and third-party support contracts normally stay with you.
- How is knowledge of your system kept if a team member moves on?
- What do you get back if the engagement ends: runbooks, documents, access logs?
We don't publish a rate card. The cost of software maintenance outsourcing depends on the system's size, its condition and the coverage you need, so a generic figure would mislead you. Describe the system and we'll talk through what a team for it would look like.
FAQ
What is included in software maintenance cost?
Engineering time for corrective, preventive, adaptive, perfective and additive changes, plus the operating costs the ISO standard leaves out of its scope: on-call, monitoring, backups, security patching, cloud infrastructure and licenses.
Is it true that maintenance is 60 to 80% of software cost?
The figure is widely repeated but rarely sourced. ISO/IEC/IEEE 14764 says only that maintenance consumes a major share of lifecycle resources. The GAO's 80% figure is the share of US federal IT spending that goes to operating and maintaining existing systems, which is a different measure. Measure your own split instead.
Can an offshore team in Vietnam cover our nights?
In summer, a normal Hanoi working day runs from 22:00 to 07:00 US Eastern time and from 03:00 to 12:00 in London, so the overlap with your night is there by default. Coverage beyond the Hanoi working day depends on how the engagement is set up. Ask us about it.
Should the team that built the system maintain it?
It is the easiest option, because no handover is needed. It is also the most expensive use of those engineers if they are meant to be building the next thing. A common split is to keep the builders on architecture and priorities and hand over the recurring work in the table above.
Next step
If you have a live system and want to talk through what handing over its maintenance would involve, contact us. Tell us the stack, how the work is covered today and which hours hurt most.
