The wrong time to discover that your maintenance company has only one engineer who understands your application is during a Saturday production outage.
The wrong time to discover that deployments are largely manual is when an urgent security fix needs to reach production. And the wrong time to discover that nobody has been keeping your framework current is when an ordinary product change suddenly requires a major upgrade first.
Most of these problems can be uncovered before the contract is signed.
The difficulty is that ordinary supplier questions tend to produce ordinary supplier answers.
Ask whether a company provides application maintenance and the answer will be yes. Ask whether it follows security best practices and the answer will probably be yes. Ask whether its engineers are experienced and you will hear about years of combined expertise.
Useful evaluation requires more specific questions—questions that make the provider explain how maintenance will actually work when it inherits your application.
NIST's 2026 Cybersecurity Supply Chain Risk Management Due Diligence Assessment Quick-Start Guide describes supplier due diligence as researching relevant information about a supplier so acquisition decisions can be made with a better understanding of risk. That principle applies well beyond cybersecurity.
When hiring an application maintenance company, you are trusting another organization with source code, production access, technical knowledge and part of the future health of the application.
These 15 questions help reveal whether that trust is justified.
[Internal Link: “How to Choose an Application Maintenance Company”]
This should be one of the first questions if the provider is taking over existing software.
A strong answer should describe a structured transition rather than simply asking you to send tickets.
That process may include reviewing:
AWS's Operational Readiness guidance recommends assessing workloads, procedures and personnel, supported by runbooks, playbooks and explicit production-support plans.
A maintenance provider should show comparable curiosity about what it is inheriting.
Good sign: They describe an assessment or transition phase and explain what they expect to understand before assuming normal maintenance responsibility.
Warning sign: “Give us Git access and we'll start fixing tickets.”
Do not settle for knowing that the company employs hundreds of developers.
You need to know who your application gets.
Ask about:
A strong arrangement might have a small core team that understands the application continuously, supported by database, security or cloud specialists when required.
That is different from having one developer backed by a theoretical bench of people who have never seen the system.
Ask to meet the likely technical lead during evaluation if possible.
Good sign: The provider can explain both the core team and how specialist expertise becomes available.
Warning sign: The sales team describes extensive company-wide capabilities but cannot tell you who will maintain your application.
This exposes key-person risk.
The answer should involve more than:
“We'll assign somebody else.”
Ask how another person would acquire enough context to continue safely.
Look for:
DORA's research on documentation quality emphasizes qualities such as reliability, findability and usefulness, and shows that strong internal documentation supports the effective implementation of technical practices.
A maintenance company should be building knowledge that can survive individual staff changes.
Good sign: More than one person knows the system, and important knowledge is deliberately captured.
Warning sign: Continuity depends mainly on the assigned engineer remaining on the account.
This question separates companies that wait for work from companies capable of evaluating what the application actually needs.
A credible provider might review areas such as:
For Levelworks, this is where App Health becomes useful. Maintenance should protect relevant qualities such as Observable, Secure, Error Free, Performant, Current & Updated, Tested, Well Documented and Seamlessly Updatable, rather than concentrating exclusively on the latest support ticket.
The provider does not need to use Levelworks' framework.
It should have some structured way of identifying technical risk beyond obvious breakage.
Good sign: They can describe a repeatable health or technical-risk assessment.
Warning sign: Their view of application condition comes almost entirely from open tickets.
This is deliberately different from asking whether they offer “proactive maintenance.”
Almost every provider will say yes to that phrase.
Ask what proactive maintenance actually produces.
Examples might include:
Then ask how those items compete with ordinary defect work.
If proactive work has no place in the backlog or allocated capacity, it probably will not happen once production tickets become busy.
Good sign: The provider can explain how preventive and lifecycle work is identified, prioritized and scheduled.
Warning sign: Proactive maintenance means little more than “we'll let you know if we notice anything.”
Do not ask which monitoring tool the company prefers.
Ask what it needs to see.
A strong answer should cover both technical health and user-facing behavior—for example:
DORA's monitoring and observability guidance emphasizes visibility into overall system health, the state experienced by customers and enough telemetry to diagnose unexpected production behavior.
Also ask what happens if your current application has weak monitoring.
The provider should be able to identify important gaps rather than accepting permanent blindness as part of the engagement.
Good sign: They explain what signals matter and how those signals support diagnosis.
Warning sign: Monitoring is described almost entirely as “we use Tool X.”
The phrasing matters.
Do not ask:
“Do you have an incident-response process?”
Ask them to walk through a realistic incident from detection to recovery.
You should hear about:
Google's Incident Management Guide organizes major response around coordination, communication and control, with distinct responsibilities preventing technical responders from having to manage every aspect of the incident simultaneously.
A smaller maintenance team may use a lighter model, but it should still know who takes charge.
Good sign: Responsibilities and escalation paths are already understood.
Warning sign: The plan amounts to calling whichever developer appears most knowledgeable.
This is one of the most revealing questions in the entire conversation.
Some providers are excellent at restoring service but make little effort to reduce recurrence.
Ask when they perform:
Google's incident guidance explicitly treats learning from outages as part of incident management because unresolved weaknesses tend to resurface and increase operational toil.
Not every small incident requires a formal postmortem.
The provider should, however, be able to explain when an incident deserves deeper follow-up.
Good sign: Significant or repeated failures create tracked improvement work.
Warning sign: Restoring production and closing the ticket normally ends the process.
“QA included” is not an adequate answer.
Ask how testing changes according to risk.
A small UI fix and a database migration should not necessarily follow identical validation.
A mature answer may include:
DORA's test automation research recommends combining automated and manual testing throughout delivery and continually improving test suites so they remain reliable and useful.
Also ask what happens when your inherited application has weak automated coverage.
Good sign: The provider adjusts test depth to the change and improves important coverage over time.
Warning sign: Testing largely means “a developer checks that the fix works.”
This question exposes a surprising amount about maintenance maturity.
Ask the provider to describe the actual release path:
Code change
→ Review
→ Tests
→ Build
→ Deployment
→ Validation
Then ask what happens if validation fails.
DORA's deployment automation guidance notes that manual deployment steps add both time and opportunities for error, and recommends progressively simplifying and automating deployment processes.
Your existing application may not have a mature CI/CD pipeline today.
The important question is whether the maintenance company recognizes that risk and can work toward reducing it.
Good sign: Releases are repeatable, traceable and have an understood recovery path.
Warning sign: Critical deployment knowledge lives in someone's laptop, notes or memory.
A maintenance provider may receive substantial privileges.
Ask specifically about:
NIST's July 2026 supplier due-diligence guidance includes foundational cyber practices and supplier resilience among the areas organizations should consider when assessing ICT suppliers. NIST SP 1326
The UK's National Cyber Security Centre likewise recommends assessing supplier security before selection and incorporating required controls into the contractual relationship. NCSC: Embed Cyber Security Controls Throughout the Contract
Good sign: Access follows defined controls rather than informal trust.
Warning sign: Shared credentials or broad permanent production access are treated as normal convenience.
Your contractual provider may not be the only organization involved.
Ask whether any work may be performed by:
The answer matters more when those people can access sensitive source code, systems or data.
NCSC supply-chain guidance specifically recommends considering subcontractor security and using contractual requirements to address how suppliers extend protection through their own supply chain.
You do not necessarily need to prohibit subcontractors.
You need visibility and appropriate controls.
Good sign: The provider clearly explains who may perform work, what access they receive and how the same requirements are applied to them.
Warning sign: Delivery arrangements are deliberately vague or can change materially without notice.
Phrase the question this way rather than:
“Do you document your work?”
You want to know what becomes part of the application's durable knowledge.
Useful outputs may include:
Ask where that documentation lives and whether you retain access to it.
The objective is not a huge wiki.
DORA's documentation research emphasizes findability, reliability and usefulness, rather than documentation volume.
Good sign: Documentation is updated as maintenance changes the application and is available to the client.
Warning sign: Most operational knowledge remains in provider conversations, ticket comments or individual engineers' heads.
[Internal Link: “The Application Handover Checklist: What Documentation Should Your Development Team Provide?”]
A provider may advertise a 30-minute critical response time.
Ask what happens during those 30 minutes.
Does an automated email count?
Does an engineer begin investigation?
Is the target 24×7 or only during agreed support hours?
Ask about:
Also ask the provider to give an example of a P1, P2 and P3 issue for your application.
That quickly reveals whether both sides interpret severity similarly.
Good sign: The SLA terminology connects directly to a real staffing and escalation model.
Warning sign: Aggressive response numbers are easy to quote, but nobody can explain precisely what they guarantee.
[Internal Link: “What Should Be Included in an App Maintenance SLA?”]
This is a powerful final question because it tests whether the provider's operating model creates dependency.
Ask what would be handed back:
The NCSC recommends considering supplier security throughout the full contract lifecycle, including regaining control of organizational assets and removing unnecessary supplier access when the relationship terminates. NCSC: Contract-Lifecycle Supplier Security
A strong maintenance company should be comfortable with the idea that another competent team could eventually take over.
That is not a threat to the relationship.
It is evidence that the provider maintains the application in a transferable way.
Good sign: Exit responsibilities, knowledge transfer and asset ownership are clear.
Warning sign: The provider would become the only organization capable of operating the application.
The 15 questions reveal different risks.
Their importance depends on your application.
For a high-volume customer-facing platform, incident response, observability and release safety may deserve much more weight.
For a legacy application changing suppliers, transition capability, documentation and knowledge continuity may dominate.
For a regulated application, security and supplier governance may carry the greatest weight.
A simple evaluation sheet can help:
Question area
Importance
Provider evidence
Confidence
Application takeover
High / Medium / Low
Team and continuity
High / Medium / Low
Application health
High / Medium / Low
Preventive maintenance
High / Medium / Low
Monitoring
High / Medium / Low
Incident response
High / Medium / Low
Incident learning
High / Medium / Low
Testing
High / Medium / Low
Deployment
High / Medium / Low
Security
High / Medium / Low
Subcontractors
High / Medium / Low
Documentation
High / Medium / Low
SLA
High / Medium / Low
Exit readiness
High / Medium / Low
Do not award points merely because the provider gave the “correct” answer.
Record the evidence behind it.
A diagram of the provider's incident process is stronger than “we handle incidents well.” A sample anonymized maintenance report is stronger than “we provide transparent reporting.” Meeting the technical lead is stronger than being told the company has excellent engineers.
The purpose of these questions is not to make procurement more complicated.
It is to make the future relationship less mysterious.
By the end of the evaluation, you should be able to imagine the first week of the engagement.
You should know who learns the application, who responds when production fails, how a change is tested and released, how technical risks get raised, where knowledge is stored, and what happens if the person who knows the application best leaves.
You should also know what happens on the final week of the relationship, even if you hope that week is many years away.
A strong maintenance provider should become more convincing as the questions become more specific.
If confidence falls as soon as the conversation moves from capabilities to operating detail, that tells you something important before the company has access to your production system.
