Most application maintenance companies look fairly similar during a sales process.
They can fix bugs. They support modern technologies. They monitor production. They respond to incidents. They keep applications secure and updated.
The differences become visible later.
They become visible when a production failure crosses three services and nobody knows where it started. When an old integration has almost no documentation. When a framework upgrade cannot be postponed any longer. When the engineer who originally learned the application leaves the supplier. Or when a supposedly small change turns out to affect billing, permissions and a database migration.
That is when you discover whether you hired a company that can genuinely maintain an application or one that is simply capable of completing development tickets.
Choosing an application maintenance company means evaluating how well a provider can understand your existing system, take responsibility for its ongoing technical condition, respond when it fails, manage predictable maintenance before it becomes urgent, and preserve enough knowledge that the application remains maintainable over time.
Price and technical-stack familiarity matter, but they are only parts of that decision.
NIST's July 2026 Cybersecurity Supply Chain Risk Management Due Diligence Assessment Quick-Start Guide makes the broader procurement principle explicit: supplier decisions should be informed by due diligence rather than simply by claimed capability. Its framework considers areas including supplier resilience and foundational cyber practices because supplier risk becomes part of the acquiring organization's risk.
The same principle applies more broadly to application maintenance.
You are not only buying engineering hours. You are placing part of the application's operational knowledge, production access and future technical condition in another company's hands.
Here is how to evaluate that decision properly.
Do not begin by collecting vendor proposals.
Begin with the application.
A provider suitable for maintaining a relatively stable internal business application may be a poor choice for a high-volume SaaS platform that releases several times each week.
Before evaluating suppliers, understand:
This determines what capability you are actually buying.
If you need 24×7 incident coverage, occasional database expertise and a team capable of maintaining both mobile and backend systems, a proposal centred on one full-stack developer is structurally wrong even if that developer is excellent.
Likewise, a large managed-services arrangement may be unnecessary for a stable application requiring modest business-hours maintenance.
[Internal Link: “How to Scope an Application Maintenance Engagement”]
A provider should be evaluated against a defined operating need, not against a generic idea of what “good maintenance” looks like.
Maintaining an application somebody else built is a particular engineering skill.
The provider needs to enter a system whose architecture, conventions and historical decisions already exist. Documentation may be incomplete. Tests may be uneven. Some dependencies may be outdated, while unusual code may exist for reasons nobody remembers clearly.
Ask how the provider approaches the first few weeks of an engagement.
A credible takeover process should usually involve some combination of:
Be cautious if the proposed transition is essentially:
Give us repository access and send us tickets.
The incoming company cannot responsibly estimate, prioritize or support an application it has not yet understood.
AWS's Operational Readiness guidance recommends evaluating workload readiness across processes, procedures and personnel, with runbooks for routine activities, playbooks for issue investigation and explicit support plans for production workloads.
A maintenance takeover deserves similar discipline.
The provider should want to understand not only the code but how the application is actually operated.
[Internal Link: “How to Take Over an App Built by Another Development Team”]
A provider may employ 300 engineers.
That does not tell you who will maintain your application.
Ask about the actual engagement structure:
A strong provider should be able to distinguish between core team capability and specialist access.
You might have two application engineers who understand the system continuously while drawing on security, DevOps, database or accessibility expertise when necessary.
That can be considerably stronger than either extreme: paying for every specialist full-time or depending on one generalist to solve everything.
Also ask what happens when people leave.
If the entire engagement depends on one engineer retaining the application in their head, you have transferred key-person risk rather than removed it.
“Do you know React and Node.js?” is not enough.
Framework familiarity tells you whether someone can write code in the application.
Maintenance requires a wider skill set.
A provider may need to:
A good evaluation therefore uses real technical conversations rather than a stack checklist.
Give the prospective provider enough architecture context to discuss how they would approach:
You are not looking for an instant solution.
You are looking at how they reason.
Do they immediately propose rewriting things?
Do they ask about monitoring, tests and production behavior?
Do they distinguish symptoms from root causes?
Do they identify assumptions before recommending action?
The quality of that conversation often reveals more than a long capability presentation.
Many companies can run a break/fix service.
A ticket arrives. Someone investigates. The defect is corrected. The ticket closes.
That may be sufficient for some applications.
It is not enough for applications that need their condition actively maintained.
Ask how the provider handles work that does not arrive through a user complaint:
A strong maintenance provider should be capable of identifying risks before they become emergency tickets.
That does not mean inventing unnecessary projects.
It means maintaining a technical view of the application alongside the incoming work queue.
For Levelworks, this is where App Health provides a useful evaluation lens. A provider should be able to reason about whether the application remains Observable, Secure, Resilient, Error Free, Performant, Current & Updated, Tested, Well Documented and Seamlessly Updatable where those aspects are relevant.
The objective is not to score every maintenance company against 17 labels during procurement.
It is to determine whether the supplier thinks beyond “what ticket is next?”
If the provider is expected to support production, ask what evidence they need to do it well.
DORA's guidance on monitoring and observability describes effective observability as giving teams visibility into both system health and the state customers actually experience, while helping engineers debug production behavior and detect degradation.
A credible provider should be interested in:
Ask what happens if your existing observability is poor.
Will they simply operate with limited evidence, or identify the highest-value gaps and improve them?
Also ask who has access to monitoring.
A maintenance organization where only one operations specialist understands production telemetry creates unnecessary dependency inside the provider itself.
Do not ask:
“Do you have incident management?”
Almost everyone will say yes.
Give them a scenario.
For example:
The application's primary checkout workflow begins failing intermittently on Saturday evening. Monitoring shows elevated API errors, but the cause is not immediately obvious.
Then ask what happens next.
You want to understand:
Google's Incident Management Guide organizes effective incident response around three core responsibilities: coordination, communication and control. Those responsibilities matter because technical investigation and stakeholder communication cannot always be managed effectively by one person during a significant incident.
The provider does not need Google's organizational structure.
It should have a structure of its own.
If the answer is simply:
“Your assigned developer will investigate,”
ask what happens when that developer is unavailable or the problem sits outside their expertise.
A maintenance provider should not repeatedly charge you to solve the same problem.
Ask what happens after meaningful incidents or recurring defects.
Do they:
The strongest providers should be able to show that incident response feeds maintenance improvement.
Otherwise, good response times can disguise an unhealthy pattern in which the same application weakness keeps generating paid support work.
A maintenance supplier should benefit from making your application easier to maintain—not from maximizing the number of tickets it receives.
A company may be excellent at writing code but weak at delivering it safely.
Ask how changes normally move from development to production.
Look for practices such as:
DORA's deployment automation guidance emphasizes reducing manual deployment steps because each manual step adds both delay and opportunity for error.
This matters particularly for maintenance because many releases are small.
If correcting a minor production defect requires a fragile two-hour manual release ceremony, every maintenance task becomes unnecessarily expensive and risky.
Do not insist that the provider replace your entire deployment pipeline on day one.
Do expect them to recognize release risk when they see it.
A maintenance company may receive access to:
Supplier security therefore belongs in the selection process.
The UK's National Cyber Security Centre recommends conducting supplier due diligence, assessing the supplier's ability to meet required security controls before selection, incorporating those controls into contracts, and continuing to monitor security performance throughout the relationship. NCSC: Embed Cyber Security Controls Throughout the Contract
NIST's Secure Software Development Framework is also explicitly intended to provide a common language that software purchasers can use when discussing secure development expectations with suppliers.
Depending on application risk, investigate areas such as:
Certifications can contribute evidence.
They should not replace understanding how the provider will handle your application.
Some providers deliver work through a combination of employees, affiliates and subcontractors.
That is not automatically a problem.
It should not be invisible.
You should understand:
The NCSC's supply-chain guidance specifically recommends understanding subcontractor security where suppliers form part of a wider chain rather than evaluating only the organization with which you directly contracted. NCSC: Supply Chain Cyber Security
For sensitive applications, this can materially affect risk.
One of the most important questions is:
What application knowledge will still belong to us two years from now?
A provider will learn a great deal about your system during maintenance.
That knowledge should increasingly appear in:
DORA's research on documentation quality identifies clarity, findability and reliability as important characteristics and finds documentation quality closely connected with effective technical practices.
This matters commercially as well as technically.
Poor documentation creates switching cost.
If the provider becomes the only place that understands the application, changing suppliers later becomes disproportionately difficult.
Healthy outsourcing should gradually make the system better understood, not more dependent on the supplier's memory.
A maintenance provider may administer your technical systems.
It should not casually become their ultimate owner.
Where appropriate, your organization should retain control over:
Supplier engineers can receive the access needed to perform their responsibilities.
Ownership should remain clear.
This becomes especially important during termination.
The NCSC recommends ensuring that organizations regain control of their assets and remove unauthorized or unnecessary supplier access when a contractual relationship ends. NCSC: Supplier Security Through the Contract Lifecycle
A good provider should not resist this model.
Maintenance improves as engineers learn the application.
High staff turnover continually resets that learning.
Ask:
You may not receive guarantees that the same engineers will remain forever.
That would be unrealistic.
What you want is evidence that the provider has a continuity mechanism, not a continuity promise based entirely on individual employees staying.
Documentation, secondary coverage and structured onboarding all matter here.
Companies often promise excellent communication.
You can test some of that before hiring them.
Notice what happens during the evaluation process.
Do they ask useful questions about the application?
Do technical people join technical conversations?
Do they identify uncertainty rather than pretending to know the answer?
Do follow-ups arrive with clear ownership?
Do commercial and technical answers agree with one another?
Procurement is usually when a supplier is trying hardest to make a good impression.
Persistent confusion at this stage rarely becomes better after the contract is signed.
A maintenance relationship needs a way to discuss more than individual tickets.
Depending on the application's scale, useful governance might include:
Topics may include:
Avoid governance that exists only to create slide decks.
A thirty-minute technical review that exposes an approaching framework deadline is more valuable than a polished report showing that 97 tickets were closed.
Do not choose a provider simply because it advertises the fastest response time.
A 15-minute critical response commitment is meaningless if nobody with application knowledge is actually available at that time.
Evaluate:
The SLA should correspond to staffing the provider can demonstrate.
[Internal Link: “What Should Be Included in an App Maintenance SLA?”]
Ask what happens operationally when a P1 case arrives.
If the company cannot connect the contractual promise to a real escalation and staffing model, the number deserves skepticism.
Maintenance can be priced through:
No model is universally best.
What matters is whether it fits the application's demand pattern.
A stable app with modest support demand might work well under retained capacity.
A large product with continuous maintenance work may justify a dedicated team.
A highly unpredictable environment may require a base retainer plus flexible additional capacity.
When comparing proposals, normalize them.
Understand:
The lowest monthly price can be expensive if every database, security or infrastructure problem triggers a separate specialist charge.
A famous client logo proves very little by itself.
Look for experience that resembles the maintenance challenge you actually have.
Relevant evidence might involve:
When reviewing references or case studies, concentrate on the maintenance problem.
What condition was the application in when the provider took over?
What did they change?
How was reliability, release capability or maintainability improved?
A vague case study saying the provider “delivered digital transformation” tells you very little about maintenance capability.
Sometimes an application genuinely should be modernized or rebuilt.
But a maintenance company's first answer should not automatically be:
Rewrite it.
A provider that financially benefits from a large redevelopment project has an obvious incentive to see legacy code as irredeemable.
A stronger provider should be capable of distinguishing among:
You want recommendations based on risk and economics, not aesthetic preference for newer technology.
Maintenance often means improving an existing system incrementally rather than replacing everything imperfect about it.
The opposite problem exists too.
A provider can become comfortable completing whatever tickets arrive while avoiding difficult conversations about the application's condition.
That may feel convenient until:
Good maintenance includes enough technical leadership to say:
This has not failed yet, but leaving it unchanged is creating a growing risk.
The provider does not need final authority over the roadmap.
It should be capable of providing that evidence.
Sometimes you do not know enough about the application to select the final maintenance model confidently.
Perhaps another agency built it.
Documentation is incomplete.
The internal team cannot clearly explain the infrastructure.
In that situation, consider making the first engagement an assessment or transition phase rather than immediately signing a long-term operating arrangement based on assumptions.
The provider can review:
Both sides then have better information for determining required team size, priorities and commercial structure.
This is often more reliable than asking several suppliers to price a system none has seen.
Once proposals become detailed, a weighted comparison can stop decisions being dominated by price or presentation quality.
An example:
Evaluation area
Suggested question
Technical fit
Can they maintain the technologies and architecture involved?
Takeover capability
Do they have a structured way to learn an inherited application?
Team depth
Is there appropriate engineering and specialist coverage?
Production operations
Can they monitor, diagnose and respond to real incidents?
Preventive maintenance
Do they identify risk beyond incoming tickets?
Security
Can they meet required access and secure-development controls?
Testing & releases
Can they make changes safely and repeatedly?
Documentation
Will knowledge become more durable over time?
Continuity
What happens when key engineers change?
Communication
Is technical and operational communication clear?
Commercial fit
Does the pricing model match expected demand?
Exit readiness
Can another team take over without rebuilding all application knowledge?
Weight those areas according to the application.
For a highly regulated platform, security may receive significantly more weight. For a legacy system being transferred from another supplier, takeover capability and documentation may matter more.
A scorecard should support judgment, not replace it.
By the end of the evaluation, you should be able to picture what happens after the contract begins.
A production error appears.
Who sees it?
A developer needs to understand an unfamiliar module.
Where is the documentation?
A major dependency approaches end of support.
Who notices?
A release needs to go live.
How is it tested and deployed?
The primary engineer leaves.
Who else knows the application?
Those scenarios reveal the operating company behind the sales presentation.
For Levelworks, that is ultimately the most useful way to evaluate an application maintenance partner. Maintenance should protect and improve the application's condition across the App Health aspects that matter to that system, while leaving the business with better visibility, stronger documentation and a safer application—not simply a smaller ticket queue.
Choose the company based on the application you need them to maintain on its hardest day, not on how polished everything looks during the easiest sales meeting.
