A comprehensive application maintenance engagement includes: security vulnerability monitoring and patching (addressing CVEs in application dependencies promptly); framework and library dependency updates (keeping the technology stack current and supported); bug investigation and fixing (with root cause analysis rather than symptomatic workarounds); performance monitoring and optimisation (maintaining response times as data volume and traffic grow); code quality improvement (gradual reduction of technical debt over time); compatibility maintenance (OS, browser, API version changes that affect the application); and incident response (rapid assessment and resolution of production incidents).

Security-critical dependency updates should be applied promptly — ideally within days for critical vulnerabilities, within weeks for high-severity issues. Non-security dependency updates are typically managed on a scheduled basis — monthly or quarterly — with breaking changes researched and planned before application. Framework major version upgrades (e.g., Ruby 3 to 3.3, Node 18 to 20) are planned projects, typically undertaken annually or when the current version approaches end-of-life. Allowing dependencies to fall significantly behind current versions increases both security risk and the eventual cost of updating.

We treat all maintenance changes with production-change discipline: changes are developed and tested in a staging environment that mirrors production; automated test suites are run before deployment; changes are reviewed before merging; deployments follow defined procedures with monitoring enabled; and rollback plans are prepared before any significant change. For dependency updates with breaking changes, we conduct additional regression testing of affected application areas. We never apply untested changes directly to production.

Maintenance covers work to keep the existing application running correctly, securely, and at acceptable performance: fixing bugs, patching security vulnerabilities, updating dependencies, addressing technical debt. New feature development adds capabilities that are not in the existing application. Both types of work can be managed within a maintenance engagement — typically with a defined allocation of capacity between maintenance (keeping the lights on) and small enhancements (improving existing functionality). Significant new features are typically scoped as separate development projects.

Transition begins with an application audit — we assess the codebase, infrastructure, deployment procedures, monitoring, and known issues. We then spend a defined onboarding period (typically 2–4 weeks) gaining familiarity with the application — reviewing code architecture, running the application in a test environment, reviewing recent git history to understand recent changes. We establish the maintenance toolchain — CI/CD access, monitoring, issue tracking — before taking responsibility for production incidents. We manage this transition carefully to avoid any service disruption during handover.

SLA commitments are structured by incident severity: critical (production down, data at risk) — acknowledgement within 1 hour, active response ongoing; high (significant functionality broken, performance severely degraded) — acknowledgement within 4 hours, resolution within 1 business day; medium (partial functionality affected, workaround available) — acknowledgement within 1 business day, resolution within 3 business days; low (minor issues, cosmetic, no business impact) — addressed in regular maintenance cycle. Specific SLA commitments are agreed as part of the maintenance contract based on the business criticality of the application.

We assess accumulated technical debt during the initial application audit — cataloguing debt items, estimating their business risk (which debts are most likely to cause future problems), and estimating remediation effort. We then develop a debt reduction plan that addresses the highest-risk items first, within the capacity available alongside ongoing maintenance. We typically recommend a maintenance engagement that includes a defined allocation of capacity for debt reduction — making steady progress over time rather than attempting a large-scale rewrite that carries its own risk and disruption.