Web application maintenance checklist: monthly, quarterly and yearly tasks

This list covers custom software maintenance tasks for the systems that operations teams run on: customer and dealer portals, internal tools, order and scheduling apps, production data systems. Unlike a marketing website, a business application has a database people write to all day, logins for employees and outside users, scheduled jobs and connections to other systems, and each needs its own checks.

It’s also the list to pick up when someone says, “Our developer is moving on, and someone needs to keep this running.” Walk through it with the outgoing developer and you’ll learn quickly what has been done and what hasn’t.

What software maintenance covers, and what counts as new work

Maintenance is the planned work that keeps an application healthy while everything around it changes. Even if nobody touches the code, the operating system, database, framework and outside services underneath it keep shipping security fixes, new versions and end-of-support dates. Support is the other half: answering questions and fixing problems as people run into them. Many arrangements include both.

What does software maintenance include? Four kinds of work:

• Corrective: fixing what’s broken, like a report that double-counts.
• Adaptive: keeping the app working as its surroundings change, such as a new browser version or an outside service retiring an API version.
• Preventive: patches, upgrades and clean-up that head off outages.
• Small improvements: a new filter, an extra column, clearer wording on a form.

New work is anything that changes what the system does or who uses it: a new workflow, new screens, a new integration or a new group of users. It needs its own scoping and testing, and when it gets squeezed into “maintenance”, the routine tasks below are what gets skipped.

Agree on gray areas in writing before work starts. A simple rule: if the change keeps the system doing what it already does, it’s maintenance. If it changes what the system does or who uses it, scope it as a project.

Monthly web application maintenance checklist

Monthly tasks are short once they’re routine. Several can be automated, but someone still has to read the results.

• Apply security patches to the operating system, web server, language runtime, framework and database. Do anything marked as a security fix first.
• Update dependencies. Libraries pull in other libraries, and a vulnerability can turn up anywhere in that chain. Run your stack’s dependency scanner; for JavaScript projects, npm audit reports known vulnerabilities in your dependencies.
• Test updates on a staging copy first: a separate copy of the app with test data. Run the main workflows there, then release to production.
• Read the error logs for new errors, errors that repeat daily and errors people have learned to live with (“just refresh and try again”).
• Check scheduled jobs and outgoing email. Imports, exports, nightly calculations and password-reset emails fail quietly. Confirm they ran and the output looks right.
• Confirm backups ran. Both the database and uploaded files, stored outside the production server and account, at a normal size. A suddenly smaller backup is a warning sign.
• Check disk space and database growth. Logs, uploads and history tables grow until something fills up.
• Run the transactions the business depends on. Log in, submit the main form, create a test record and confirm the notification arrives.
• Check that alerts reach a person. An uptime alert that goes to a former employee’s inbox is the same as no alert. Then note everything in the log.

Quarterly application maintenance checklist

Every three months, test the things that only matter on a bad day.

• Restore a backup to a separate copy and use it. Steps below.
• Review access to the app, server, database, code repository and outside services. Remove anyone who has left or changed roles (see the access section).
• Check performance. Compare page and report times with last quarter and find the slowest queries. Tables that grow every day are the usual suspects.
• Test on real phones and browsers. Run the main workflows on the devices your users have, where they work. When a manager says, “Our contractors need to do this from their phones,” this test shows whether they can. Our mobile-friendly test is a quick first check.
• Read notices from outside services. Payment, email, mapping and shipping services retire API versions on announced dates, and the notice goes to whoever signed up.
• Collect workarounds from daily users. A workaround is a bug report nobody filed.
• Check certificate expiry dates and the renewal automation. Lifetimes are shrinking (see the yearly list).

How to run a backup restore test

CISA tells organizations to “regularly test the availability and integrity of backups in a disaster recovery scenario” (#StopRansomware Guide), and the NIST Cybersecurity Framework 2.0 lists backups that are “created, protected, maintained, and tested” as an outcome (PR.DS-11). For a web application:

1. Restore the latest database backup and uploaded files to a separate environment, never over production.
2. Time it, from “we need the backup” to “people can log in”. That’s your real recovery time.
3. Open the newest records and check that recent uploads and settings came back too.
4. Note what was missing: configuration, keys, scheduled jobs, steps someone had to remember.
5. Log the date, the time it took and the gaps, and close the gaps before the next test.

Yearly checklist: renewals, documentation and platform lifecycle

Once a year, review everything with an expiry date and every decision that needs lead time.

• Certificates. Make sure renewal is automated and monitored; a yearly check no longer works. A CA/Browser Forum ballot cuts the maximum lifetime of public TLS certificates from 398 days to 47 days in steps between March 2026 and March 2029. If you relied on Let’s Encrypt’s reminder emails, it announced it would stop sending them on June 4, 2025.
• Domains and DNS. Confirm auto-renew, a current payment card and registration in the company’s name. For .com and other generic domains, ICANN’s Expired Registration Recovery Policy requires renewal reminders about a month and a week before expiration, sent to the registrant on file. If that’s a former employee, nobody reads them.
• Licenses and subscriptions. Paid libraries, hosting plans, email and map services, app-store developer accounts: list each with its renewal date, cost approver and billing card.
• Platform end-of-support dates. List the versions of the operating system, database, runtime and framework, and when each loses support. Microsoft’s extended support for SQL Server 2016 ended in July 2026. The Node.js release page is blunt: “Production applications should only use Active LTS or Maintenance LTS releases.” Plan upgrades while they’re still optional. On Classic ASP? Read our Classic ASP end-of-life guide.
• Documentation. Update the runbook: how to build, release and restore the app, what runs on a schedule, which outside services it uses and where credentials are kept.
• Rotate credentials: API keys and service and database passwords, starting with anything a departed person knew.
• Walk through a disaster. If the server vanished, who rebuilds it, from what, and how long would the business wait?
• Review the backlog with the business. Separate maintenance from new work, and ask whether the system still fits how the operation runs. If not, weigh rewrite vs refactor.

Access and accounts: the maintenance item everyone skips

Patches get attention because tools nag about them. Nothing nags you about the contractor who finished in March and can still log in, or the domain registered to a developer’s personal email.

Review two layers: the people who use the app and the people who can change it. NIST’s Cybersecurity Framework 2.0 lists access permissions that are “managed, enforced, and reviewed” under least privilege as a core outcome (PR.AA-05).

When someone leaves: six offboarding steps

1. Switch off their app login and admin roles on their last day.
2. Remove them from the repository, hosting, database and outside services.
3. Change every shared password and API key they knew.
4. Move two-factor recovery off their personal phone.
5. Reassign scheduled jobs, reports and alert emails that run under their name.
6. Record it in the maintenance log.

Contractors and outside developers need the same steps, and an HR exit process may not catch them. If the person leaving built the system, collect everything on our software handover checklist before their last day; it writes the request for you. If an employee built the tool on a personal account, see employee-built apps your team depends on. If the developer has stopped answering, start with what to do when your developer disappears.

Signs web application maintenance has been neglected

Look for these when you assess a system nobody has looked after for a while.

One or two of these is housekeeping. Several at once means the app needs a stabilization pass first: overdue security updates, then backups, access and documentation. If the code itself is the problem, see how to modernize an old web application.

In-house maintenance or a maintenance partner?

Either can work. What matters is whether someone actually does these tasks every month, and whether more than one person can fix the system.

A split often works: your team handles user accounts, reports and first-line questions; an outside engineering team handles patches, upgrades, backups and fixes.

Questions to ask any maintenance partner

• Will we talk to the engineers who work on our system, or to an account manager?
• What’s included, and how will you tell us when a request is new work?
• Do you start with a review of the code, hosting and documentation?
• How are updates tested before they reach production?
• Can we see your maintenance log and runbook?

How we work: you talk directly to the engineers doing the work. We provide ongoing maintenance for Amusement Advantage’s contractor portal, which we’re modernizing page by page for its network of 60,000+ contractors, each page tested on a staging copy before production. We host and maintain a national retail chain’s careers website (a confidential client, so we don’t name it), and we designed, built and still run Just A Menu, our own platform. See maintenance and support for how an engagement starts, or browse our guides.