How long should software maintenance and production operations continue after delivery?
There is no universal maintenance period. A defect warranty needs a contractual end date. Monitoring, backups, security updates, and incident response should continue for as long as the system supports the business. New features are separately scoped iterations rather than work hidden inside maintenance.
A promotional page retired after two weeks and an equipment platform running for five years do not need the same long-term service. “One to three months free maintenance” describes one supplier's commercial arrangement, not an industry rule. Wavesteam first identifies system lifetime, operating hours, and downtime consequence, then recommends service coverage and whether it is monthly, annual, internal, or externally operated.
When planning milestones, resources, and acceptance, also compare Does Wavesteam continue supporting a system after it goes live? and Can Wavesteam operate and maintain a system after launch?; the linked guidance adds context that should be considered in the same decision.
| Timeline | Start and end | Work during it | After it |
|---|---|---|---|
| Defect warranty | From acceptance or launch to the agreed date | Correct reproducible deviations from delivered scope | Paid maintenance or client team |
| Production operations | From production activation to retirement or handover | Monitoring, incident, backup, recovery, capacity, security | Renew, transfer, or retire—never leave unmanaged |
| Feature iteration | Per release or requirement package | New workflow, reports, supplier adaptation, performance | Next version, not defect correction |
| Third-party asset lifecycle | Domain, certificate, cloud, and platform expiry | Renewal, rotation, review, compatibility | Expiry may stop service; assign an owner |
Classify warranty by whether the system deviates from confirmed requirements and acceptance, not who found the problem. A calculation or permission error and reproducible crash normally indicate a defect. A new approval level, supplier API redesign, or capacity for traffic growth normally does not. The SOW, acceptance record, and change history decide the actual boundary.
Production operations are active work. Continue checking external availability, core-flow success, errors, capacity, backup, certificates, and critical dependencies and keep contacts and runbooks current. Google's production service best practices and incident management guide provide methods for user-facing objectives, roles, work records, and structured response; a small system does not automatically need a dedicated SRE team.
Define incident levels, first response, restoration, coverage hours, supplier exclusions, and consequences. Business-hours service may fit a low-impact internal tool. Revenue, equipment safety, and continuous production may justify 24/7 staffing, redundancy, and recovery exercises, with higher cost. DORA research helps teams observe delivery and restoration, but Wavesteam sets targets from this system's measured baseline and business risk rather than importing an external number.
Before warranty ends, review incidents and tickets and list coming supplier renewals, risks, changes, and recommended coverage. The client may continue with Wavesteam, transfer internally, or engage another supplier. If the business has ended, formally retire services, backups, personal information, DNS, and billable resources instead of leaving an abandoned public system.
Transferability is part of delivery. The client receives source and version, build and deployment instructions, architecture and data definitions, administrator access, key-transfer record, monitoring and backup setup, open issues, and supplier assets. Wavesteam works through named client-authorized accounts and removes its access after handover. Declining renewal must not deprive the client of its system.