Evaluating a company for ongoing software maintenance is different from evaluating one for new development. The skills and processes that matter for building new software overlap significantly but not completely with those that matter for maintaining existing systems. The evaluation criteria should reflect that difference.

Experience With Legacy Codebases

A software maintenance company should have genuine experience working with codebases they didn’t build — reading existing code, understanding existing architecture, and extending or fixing systems without the benefit of having made the original design decisions. This is a different skill than greenfield development and not every development team does it well.

See also: What the FDA Crackdown on Compounded GLP-1 Means in 2026

Documentation Practices

The Software Engineering Institute at Carnegie Mellon has documented that poor documentation is the most common factor in extended maintenance costs — teams spend significant time rediscovering how systems work rather than applying that time to actual maintenance. Ask prospective maintenance partners what documentation they produce and how they manage knowledge transfer when team members change.

Security and Dependency Management

Software maintenance increasingly means security maintenance. Dependencies have vulnerability lifecycles, and an unmaintained codebase accumulates security exposure over time. Ask specifically how a prospective maintenance partner tracks and addresses dependency vulnerabilities, what their process is for applying security patches, and how they handle end-of-life dependencies.

Communication and Reporting

Ongoing maintenance relationships require consistent communication — regular reports on what work has been done, what issues were found and how they were addressed, and what’s being deferred and why. A maintenance vendor who doesn’t offer structured reporting is harder to hold accountable and harder to evaluate for value over time.