A company hires a maintenance partner for “40 hours of application support per month.”
The agreement sounds straightforward until the first month begins.
Support wants user issues investigated. Engineering expects an old framework to be upgraded. A production incident consumes most of one week. Product asks for two “small” enhancements, while infrastructure needs certificate renewal and a database upgrade.
By the end of the month, everyone agrees that the team was busy.
Nobody agrees whether it did the work it was hired to do.
The problem is not necessarily capacity. It is scope.
A well-scoped application maintenance engagement defines exactly what application is being maintained, which responsibilities belong to the maintenance team, what work is included, which service expectations apply, and how planned and unplanned work will compete for available capacity.
Simply purchasing developer hours does not establish any of those things.
Good maintenance scoping creates an operating boundary before routine tickets, incidents and upgrade work begin pulling the team in different directions.
AWS's Well-Architected Framework recommends evaluating the operational readiness of the workload, its processes, procedures and personnel before taking on support responsibility. It also stresses having defined support plans and clear owners for operational activities. AWS Well-Architected: Operational Readiness and Change Management
For Levelworks, this is also where App Health can be useful before an engagement starts. The App Health framework helps reveal what condition the application is currently in; the scope then determines which aspects the maintenance team is responsible for protecting or improving.
Before defining maintenance work, establish exactly what constitutes “the application.”
A modern application is rarely one repository and one server.
The maintenance boundary may include:
Microsoft's Well-Architected Framework defines a workload broadly as the application resources, code, data and supporting infrastructure that work together to deliver a business outcome. That is a useful starting point for maintenance scope because maintaining only the visible application code may leave critical supporting components without ownership. Microsoft Azure Well-Architected: Workloads
Create a simple inventory:
Component
Included?
Current owner
Web application
Yes
Maintenance team
Mobile apps
No
Internal mobile team
Backend API
Yes
Maintenance team
Production database
Shared
Internal platform + maintenance
Cloud infrastructure
Yes
Maintenance team
Payment integration
Yes
Maintenance team
Corporate identity platform
No
Enterprise IT
This prevents responsibility from being discovered during an incident.
An engagement cannot be scoped accurately from an architecture diagram alone.
Two applications with identical technology stacks can require very different levels of maintenance because one has strong test coverage, current dependencies and reliable monitoring while the other has unresolved incidents, outdated frameworks and almost no documentation.
Before finalizing the scope, perform a baseline review of the existing application.
Look for evidence such as:
This is not necessarily a full technical audit.
The objective is to understand what operational condition the incoming team is actually inheriting.
AWS recommends assessing operational readiness through a consistent review of workloads, processes, procedures and personnel, using the review to expose risks that need planned remediation.
For Levelworks, an App Health assessment can provide a structured way to do this. If the application is weak in Observable, Tested, Current & Updated or Well Documented, those weaknesses may materially affect the maintenance effort from day one.
An important distinction should also be recorded:
Inherited backlog is not the same thing as ongoing maintenance demand.
If an incoming team discovers 200 existing defects, those issues should not quietly consume the entire future maintenance allocation unless both sides intentionally agree that backlog remediation is part of the engagement.
Not every part of an application deserves the same service expectations.
Identify the workflows whose failure would create significant business impact.
Examples might include:
Microsoft's Well-Architected guidance recommends identifying business-critical user and system flows and linking their criticality to reliability targets and escalation requirements. Microsoft: Optimize Workload Design Using Flows
This matters during maintenance because the same technical defect can deserve very different treatment depending on where it occurs.
A formatting problem on an internal administration page is not equivalent to payment failure.
The scope should identify which flows receive the highest operational priority before the first production incident forces that discussion.
Do not scope an engagement with language such as:
“Ongoing maintenance and support as required.”
That wording hides almost every important decision.
Instead, define work categories explicitly.
A scope might include:
Fixing defects in existing functionality.
Addressing issues intended to reduce future failure risk, such as dependency updates or recurring problem remediation.
Changes needed because the environment around the application has changed—for example, browser, OS, API or platform updates.
Small improvements to existing functionality where specifically allowed by the engagement.
These categories align with common maintenance concepts, but the scope should concentrate on how they apply to this application rather than turning the contract into a textbook definition.
[Internal Link: “What Do Application Maintenance Services Actually Include?”]
The most important issue is deciding how substantial new features are handled.
If a request changes business capability rather than maintaining or modestly improving what already exists, it may belong in separate project work.
The phrase small enhancement causes endless maintenance-scope disputes.
One stakeholder may think:
Add another field to the form.
Engineering may discover that the field requires database changes, API updates, new permissions, migration logic, analytics changes and modifications to two mobile apps.
Avoid defining included enhancements purely by how simple the request sounds.
A stronger boundary might use factors such as:
For example:
Minor modifications to existing workflows may be handled within maintenance capacity after estimation. New modules, substantial workflow redesigns or changes requiring significant architecture work are separately scoped.
The exact rule can vary.
It simply needs to exist before the first ambiguous request arrives.
The team needs to know when it is expected to respond.
Possible models include:
Do not assume “maintenance” automatically means someone is watching production around the clock.
AWS recommends validating that enough trained personnel are available for the periods when a workload needs support, including realistic on-call and leave coverage. AWS Well-Architected: Ensure Personnel Capability
Availability expectations should follow business requirements.
An internal application used only Monday through Friday may not justify the same support model as a global ecommerce platform.
Detailed contractual response and resolution commitments belong in the SLA.
[Internal Link: “What Should Be Included in an App Maintenance SLA?”]
The scope should establish the operating model; the SLA can formalize measurable service commitments.
Maintenance is unusual because the workload contains both predictable and unpredictable work.
Predictable work includes:
Unplanned work includes:
If every available hour is allocated to planned work, one production incident destroys the plan.
If all capacity is reserved for unpredictable work, preventive maintenance never happens.
The engagement should therefore define how capacity is allocated and what happens when urgent work consumes planned capacity.
For example:
Monthly maintenance capacity
50% planned maintenance
25% defect/support work
15% technical health improvements
10% contingency
Allocation reviewed monthly based on actual demand
The percentages are illustrative, not universal.
The important point is that the trade-off is deliberate.
The backlog will eventually contain more work than can be completed immediately.
Someone needs authority to decide what moves first.
The scope should identify who represents:
A typical model might involve the maintenance lead and product owner reviewing priorities together, with critical incidents or security issues entering an expedited path.
Do not create a situation where five stakeholders can independently declare their request “urgent.”
The maintenance engagement should define both the decision-maker and the escalation route when priorities conflict.
Even a well-scoped maintenance provider rarely owns everything.
Responsibility may be shared with:
AWS recommends identifying owners for workloads, infrastructure, applications and operational activities so teams know who performs actions, validates outcomes and responds when problems occur.
A lightweight responsibility matrix can help:
Activity
Maintenance team
Client/internal team
Application bug fixes
Own
Prioritize
Production deployment
Own
Approve where required
Cloud infrastructure
Own
Governance
Security penetration test
Support
Security team owns
User-support intake
Escalation
Support team owns
Product roadmap
Estimate
Product owns
Vendor billing
Technical input
Business owns
Scope clarity becomes especially important at boundaries.
“Shared ownership” without specifying who acts first often means nobody acts confidently.
A maintenance team cannot own outcomes for systems it cannot reach.
Confirm access to the systems included in scope:
Do not wait for the first incident to discover that production logs require approval from somebody unavailable that day.
Access should also match responsibility.
A team expected to deploy production should have an approved production-deployment path. A team responsible for monitoring should be able to access dashboards and configure relevant alerts.
An existing development team may understand the application deeply while the incoming maintenance team knows very little.
That knowledge gap belongs in the scope.
DORA's research identifies documentation quality—including clarity, reliability and findability—as an important foundation for effective technical practices. DORA: Documentation Quality
The engagement may therefore need an initial transition period covering:
If significant documentation is missing, creating it may itself be legitimate early maintenance work.
[Internal Link: “How to Take Over an App Built by Another Development Team”]
Some applications should not move directly into steady-state maintenance.
Imagine taking ownership of an app with:
Treating that as ordinary ongoing support hides substantial one-time work.
A better engagement can include:
Phase 1: Transition and stabilization
Resolve immediate operational gaps, establish access, understand architecture, improve critical monitoring and create minimum documentation.
Phase 2: Steady-state maintenance
Move into recurring support, preventive work, defect resolution and planned updates.
This prevents the first several months from appearing to “underperform” because maintenance capacity is actually being spent making the application maintainable.
Scope should include not just activities but important outputs.
Depending on the engagement, these might include:
Do not request reporting simply to create documents.
Every artefact should help somebody make a maintenance decision.
For example, a monthly review could cover:
That is much more useful than reporting “46 tickets closed.”
Maintenance requirements evolve.
The application may add another mobile client. The business may become international. An integration can become mission-critical. Regulatory requirements may change.
The original maintenance scope should therefore include a mechanism for revisiting itself.
Microsoft's workload guidance emphasizes that workloads evolve as their purpose and requirements change, and their teams and operating practices need to adapt with them.
A quarterly or semiannual scope review can ask:
Scope should be controlled without becoming frozen.
Several patterns repeatedly create weak maintenance engagements.
Hours define capacity, not responsibility.
Legacy backlog needs explicit treatment.
This gradually converts maintenance into feature development.
The application may depend on systems nobody has agreed to maintain.
24/7 expectations require actual coverage.
The first weeks become access administration instead of maintenance.
Ticket volume does not tell you whether the application is becoming healthier.
Before signing off an engagement, both sides should be able to answer:
Scope area
Required clarity
Application boundary
Which applications, services and environments are covered?
Current state
What risks and inherited backlog exist?
Critical workflows
Which user/business flows deserve highest priority?
Work included
Which maintenance categories are covered?
Feature boundary
When does a request require separate project scope?
Service hours
When is support available?
Capacity
How is planned versus unplanned work handled?
Prioritization
Who decides what gets worked on first?
Responsibilities
Which team owns each operational activity?
Access
Can the maintenance team reach the systems it owns?
Documentation
Is enough knowledge available to operate safely?
Transition
Is a stabilization phase required?
Reporting
What information will demonstrate progress and risk?
Scope review
How will the engagement adapt when the application changes?
A good scope should feel almost boringly explicit.
That is a strength.
Ambiguity can look flexible when an engagement begins, but in maintenance it usually turns into competing expectations later: product assumes enhancements are included, engineering expects preventive upgrades, support expects instant investigation, and the maintenance team is left deciding which promise to break.
The strongest maintenance engagements remove those surprises early. They establish the system boundary, the inherited condition, the responsibilities, the priorities and the capacity available to act on them.
Once those boundaries are clear, maintenance stops being an undefined pool of technical effort and becomes an operating model both sides can actually manage.
