Software Maintenance and Support 

Before assigning any roles or thinking about tools, define what needs to be supported — technically and from the business standpoint. Key tasks:

• Identify components to be supported. It could be back-end services, front-end apps, databases, third-party integrations, cloud infrastructure, CI/CD pipelines, etc.
• Assess software complexity. Consider codebase size, known bugs, system age, architectural style, compliance demands, and other factors that will influence how much support your system will need.
• Build a software map. You’ll need a visual representation of modules, interdependencies, and high-risk zones (e.g., legacy code).

• Define the support type. Support may cover one or more of the following:
  • Corrective — bug fixes.
  • Adaptive — adjustments to changes in OS, API, or infrastructure.
  • Perfective — enhancements, new features.
  • Preventive — tech debt clean-up, refactoring, risk mitigation.
• Map out the support levels and roles:

Decide whether to outsource support, build it in-house, or combine. Your choice should reflect resource availability, time-to-market needs, and risk tolerance.

Outsourced maintenance

Time to onboard: 3–12 weeks

Pros:

• Faster team ramp-up than hiring in-house specialists.
• Direct access to skilled experts and tried-and-tested software support practices.
• Easier to scale up and down.

Common pitfalls:

• Vendor mismatch. Choosing a vendor without deep domain knowledge or a compatible working culture can lead to poor communication, delays in resolution, or a lack of shared expectations regarding quality and priorities.
• Weak SLAs. Without well-defined service level agreements (SLAs), you risk inconsistent performance, unmet expectations, or misaligned priorities.
• Unclear handoffs. If escalation paths and responsibilities between the vendor and your internal team aren’t clearly defined, it can lead to delays, duplicated efforts, or dropped tickets — especially during high-pressure incidents.

How to avoid the pitfalls of outsourcing:

• Examine top listings of software engineering companies, as 90% of them offer maintenance services. Software engineering companies have, on average, higher seniority and more diverse skills among their developers compared to pure IT support outsourcing firms, who are traditionally more focused on help desk.
• Shortlist vendors with certifications: look for ITIL, AWS/Azure, Red Hat, Microsoft, ISO badges.
• Ask vendors to clarify their tool stack: What tools do they use for monitoring (e.g., Zabbix, Prometheus, Datadog), alerting (e.g., Grafana, Graphite), ticketing and collaboration (e.g., Jira, ServiceNow, Zendesk), and how these are integrated into their workflows. A pre-integrated setup can cut weeks off your onboarding and reduce tool compatibility risks.
• Run a pilot test with the top two vendors: e.g., ask them to resolve a known bug or stabilize staging.
• Evaluate how fast they can replicate your testing and production setup — it is a good indicator of their ability to fast they can dive into real work and start delivering results.
• Demand a detailed reverse knowledge transfer plan in case you bring in-house support later.

In-house maintenance

Time to hire and onboard: 6–20 weeks

Pros:

• Full control over the software support team, maintenance processes, and their alignment with internal policies.

Cons:

• Longer setup time due to the need to hire and train staff.
• Potential lack of necessary talent on the market, especially for legacy and niche technologies.
• Lower team scalability compared to the outsourced option.
• Higher overhead for tool integration and process setup. Unlike with outsourcing providers that already have mature toolchains and workflows, in-house teams may face a longer tool ramp-up curve and additional licensing or customization costs.

Structured knowledge transfer is essential, especially If the L3 support team is different from the original development team. Knowledge handoff should cover sharing:

• Architecture and data flow diagrams.
• Known issues, performance bottlenecks.
• Deployment and rollback procedures.
• Access to code, CI/CD pipelines, databases, and cloud dashboards.
• Configuration details for all environments.

Create a shared unified knowledge base for all support teams and update it regularly instead of relying on the memory or locally stored notes of support engineers. This pays off long-term, enabling faster onboarding, smoother escalations, and fewer avoidable mistakes.

Avoid the chaos of informal requests. Instead, create a structured and scalable support flow:

• Сhoose, set up, and customize a ticketing system (like Jira or Zoho Desk) to serve as the central hub for managing support requests.

• Standardize ticket submissions with required fields such as issue title, detailed description, urgency, affected users or systems, steps to reproduce, and relevant screenshots or logs. This makes sorting faster and ensures consistent data for all levels of support.

• Optionally, provide additional communication channels, such as a dedicated support email or chat (e.g., Slack, Teams) — but make it clear that all actionable issues must still be logged as tickets to ensure traceability and accountability.
• Introduce a severity classification system and decide what response each priority level requires:

• Critical outage (P1): a system is down or unusable; immediate action is required.
• Major functionality broken (P2): a key feature is not working, impacting business operations.
• Minor bug or performance issue (P3): a workaround is available; not business-critical.
• Cosmetic or low-impact requests (P4): UI issues or general suggestions.

• Define clear escalation paths so that support doesn’t stall when problems escalate in complexity. Clarify:

• What types of issues L1 support should escalate to L2.
• When L3 engineers (developers, DevOps, architects) must step in.
• How cross-level communication should flow during active incidents, especially for P1 issues, and who’ll be the incident lead (usually they’re selected from L2 or L3 team managers).

Tip: A well-maintained knowledge base can empower L1 engineers to resolve up to ~60% of issues without escalation.

Define measurable indicators for support team performance, e.g.,:

• The percentage of tickets resolved at L1.
• Average resolution time per severity.
• The percentage of incidents resolved before being reported by users (a marker of proactivity).
• The number of changes/updates delivered and the number of changes/updates waiting in a backlog.
• Stakeholder (e.g., user, employee) satisfaction.
• SLA compliance (e.g., meeting system uptime and performance targets, response times per support level and per communication channel).

• Request regular reports on the most telling indicators of support health. These should cover system stability (SLA breaches and trend patterns, resolution timelines, incident heatmaps, tech debt trends), user satisfaction (feedback from software users and business units), and team productivity (repetitive issues, postponed fixes, and root cause patterns).
• Schedule cross-level support team retrospectives quarterly to discuss what escalations could’ve been handled earlier, where documentation or automation is lacking, which communication gaps caused delays or confusion, and more.
• Run planned mock drills — such as database outages, DDoS attacks, or cascading service failures — to test your support team’s escalation and resolution flows, response speed under pressure, and coordination across levels and with business stakeholders.
• Use insights from the reports, retrospectives, and drills to make smart adjustments:
  • Rebalance support team roles or shift coverage.
  • Introduce better automation or alerting.
  • Expand the knowledge base to reduce escalations.
  • Refactor support workflows as the software evolves.
  • Adjust the support and monitoring tools.