--- title: "What software maintenance should actually include — Orvun Labs" description: "Separate defects, product changes, security work and operations before agreeing a maintenance scope." canonical: "https://orvunlabs.com/en/journal/what-software-maintenance-should-actually-include" language: "en" last_modified: "2026-09-13" --- # What software maintenance should actually include Separate defects, product changes, security work and operations before agreeing a maintenance scope. ![Separate defects, product changes, security work and operations before agreeing a maintenance scope.](https://orvunlabs.com/images/blog/rescue.svg) - Published: 2026-09-13T09:00:00.000Z - [Software modernisation](https://orvunlabs.com/en/journal/topic/rescue.md) ## A maintenance label hides several different jobs Maintenance works better when the agreement distinguishes restoring expected behavior from adding new behavior. It should also describe dependency and security work, monitoring, backups and deployment support. A monthly allowance alone does not establish who notices an incident or who is authorized to change production. Define supported systems, operating hours and escalation contacts in plain language. ## Classify work by the promised behavior A fictional booking form that stopped accepting a previously supported date format is a defect. Supporting a new recurring-booking model is a product change. Updating a vulnerable dependency is security work; checking failed jobs and recovery readiness is operations. Some incidents cross categories, so permit initial diagnosis before final classification. Otherwise the team can argue about labels while users remain blocked. ## Describe what happens when an incident is reported Define where reports arrive, the information needed for initial diagnosis and the person who assigns severity. Ask for the affected task, observed error, approximate time and a safe reference to the record; do not request passwords or unnecessary personal data. State who can authorise an emergency change and how the business is informed while investigation continues. A prompt acknowledgement is useful, but it should not be presented as proof that service has been restored. Keep the distinctions between acknowledgement, investigation, workaround and resolution visible in the operating agreement. ## Give preventive work a concrete place List recurring checks that are appropriate for the product: reviewing failed jobs, testing restore procedures, inspecting dependency notices and confirming that operational contacts still receive alerts. Assign each a frequency or a trigger, an owner and a record of completion. Not every product needs the same schedule, and a generic checklist should not claim work that nobody actually performed. Where an update affects integrations or stored data, include verification and a recovery plan in its scope. Preventive maintenance is easier to defend when it produces evidence the business can inspect rather than an unexplained monthly block of hours. ## Make a maintenance exit possible Keep current runbooks, account ownership, recent changes and open incidents available to an authorised successor. State how unused reserved capacity, unfinished work and third-party subscriptions are handled when the arrangement ends. Transfer necessary access securely and remove obsolete access after verification. If an unresolved incident continues across the handover, name its owner and the next action rather than closing it administratively. A useful maintenance agreement preserves continuity while the relationship exists and makes a controlled transfer possible afterwards. That is a more practical promise than suggesting that the same provider must remain responsible forever. ## Compare reserved capacity with work on demand Reserved capacity improves continuity and provides room for preventive work, but unused time and priorities need an explicit policy. Work on demand can fit an infrequently changed product, though availability must be agreed for urgent issues. A response commitment is different from a resolution promise: a third-party outage may be outside the maintainer’s control. Avoid “unlimited support” without boundaries. ## Write the operating agreement Orvun Labs’s software-rescue and maintenance work can begin with an inventory and a short recovery review. Turn the findings into a service scope that both product and operational owners understand. - Which applications, integrations and environments are included? - Who monitors alerts and approves emergency changes? - What is the distinction between response, workaround and resolution? - How are preventive work, releases, documentation and handover reported? ## Software rescue & care A considered next chapter for existing software. - [Discuss this service](https://orvunlabs.com/en/services/software-rescue.md) ## Related reading - [Rewrite or improve gradually? A decision grounded in the business](https://orvunlabs.com/en/journal/rewrite-or-improve-gradually-a-decision-grounded-in-the-business.md) - [Prioritize technical debt by its effect on the business](https://orvunlabs.com/en/journal/prioritize-technical-debt-by-its-effect-on-the-business.md) - [Plan a migration around data, cutover and a credible way back](https://orvunlabs.com/en/journal/plan-a-migration-around-data-cutover-and-a-credible-way-back.md) ## Let's make something useful. A first product, a difficult workflow or software that needs a fresh start. Tell us where you are. - [Tell us about your project](https://orvunlabs.com/en/contact) ## Structured data ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://orvunlabs.com/#organization", "name": "Orvun Labs", "url": "https://orvunlabs.com", "logo": "https://orvunlabs.com/orvunlabs-icon-512.png", "description": "Custom software, SaaS products and AI-powered tools — designed around your business.", "knowsAbout": [ "Custom software", "SaaS product development", "AI integration" ] }, { "@type": "WebSite", "@id": "https://orvunlabs.com/#website", "name": "Orvun Labs", "url": "https://orvunlabs.com", "inLanguage": [ "en", "es", "de", "fr", "pt", "ja", "hi", "ar", "id", "tr", "pl" ], "publisher": { "@id": "https://orvunlabs.com/#organization" } }, { "@type": "WebPage", "@id": "https://orvunlabs.com/en/journal/what-software-maintenance-should-actually-include#webpage", "url": "https://orvunlabs.com/en/journal/what-software-maintenance-should-actually-include", "name": "What software maintenance should actually include", "description": "Separate defects, product changes, security work and operations before agreeing a maintenance scope.", "inLanguage": "en", "isPartOf": { "@id": "https://orvunlabs.com/#website" }, "about": { "@id": "https://orvunlabs.com/#organization" }, "breadcrumb": { "@id": "https://orvunlabs.com/en/journal/what-software-maintenance-should-actually-include#breadcrumb" } }, { "@type": "BreadcrumbList", "@id": "https://orvunlabs.com/en/journal/what-software-maintenance-should-actually-include#breadcrumb", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Orvun Labs", "item": "https://orvunlabs.com/en" }, { "@type": "ListItem", "position": 2, "name": "What software maintenance should actually include", "item": "https://orvunlabs.com/en/journal/what-software-maintenance-should-actually-include" } ] }, { "@type": "BlogPosting", "headline": "What software maintenance should actually include", "description": "Separate defects, product changes, security work and operations before agreeing a maintenance scope.", "datePublished": "2026-09-13T09:00:00.000Z", "dateModified": "2026-09-13T09:00:00.000Z", "inLanguage": "en", "author": { "@id": "https://orvunlabs.com/#organization" }, "publisher": { "@id": "https://orvunlabs.com/#organization" }, "image": [ "https://orvunlabs.com/images/blog/rescue.svg" ], "mainEntityOfPage": { "@id": "https://orvunlabs.com/en/journal/what-software-maintenance-should-actually-include#webpage" } } ] } ```