Define what application management means
Management might mean availability monitoring, incident response, dependency maintenance, feature changes, domain administration or user support. Each activity needs different staffing and access. Before agreeing to a service, list the systems, environments and types of work included. State separately what remains with the client or another supplier. Without that boundary, even a small outage can become an argument about who was expected to act. The definition is part of the service, not paperwork added after it.
A useful first deliverable is an operating map: application, database, hosting, external APIs, DNS, certificate, backups and people with access. Give each component an owner and escalation contact. This is not documentation for its own sake. If payments stop working, the team needs to know who can inspect the integration, who contacts the provider and who informs users. A clear map reduces the time spent identifying the fault and the person able to address it.
Availability and SLAs depend on the user journey
An availability promise must say what is measured: the home page responding, an order reaching completion or an administrator being able to process a request. Each measure describes a different service state. Define the period, planned maintenance, incident threshold and response time. The objective should reflect actual value and the cost of an outage. A high availability percentage is not useful if the critical process regularly fails while the server itself is healthy.
Google SRE uses service level objectives and error budgets to balance release speed with stability. A small organisation need not copy the entire process, but the principle is useful: when the service misses its goals, a new feature may not be the first priority. Distinguish a quality objective, a contractual commitment and an internal alert. An SLA is a commercial agreement with exceptions and consequences. It cannot honestly be promised without understanding infrastructure, dependencies and staffing.
Incidents need an order of action
During an outage, first establish user impact and stop the problem spreading. Then assign a lead, decide whether to repair or return to a previous version and communicate the known state. Diagnosis benefits from a timeline: when the issue began, what changed and which services are affected. Disputes about who can restart a process or contact a provider are particularly expensive at this moment. Agree those permissions and contacts while the system is healthy.
AWS Operational Readiness Reviews recommend checking people, procedures, monitoring and event response before a public launch. A small site can use a proportionate checklist and short instructions. One covers a faulty release, another database failure and another an external integration. A controlled failure exercise can expose an expired contact or missing permission before a real incident does. Afterwards, record the cause and a specific change that lowers the chance or impact of recurrence.
Monitoring should follow completed work
An HTTP status check is not enough. An application can render pages but fail to accept messages, issue invoices or show current data. Measures should reflect its main tasks: completed operations, error states, queue age, response time and external connection health. Every signal needs a threshold, owner and procedure. An alert without someone who can act does not provide safety. Conversely, a quiet failure in a critical flow may last for hours if nobody measures the outcome.
Too many alarms cause fatigue and hide meaningful changes. Reconsider notifications that often fire without impact, and add checks for silent failure. Logs should trace an individual operation without storing passwords, tokens or unnecessary personal data. Also track the quality of repairs: how many cases require manual intervention and why? Operational stability belongs to the complete service, not simply the physical server running it.
Maintenance includes change and security
Regular management covers operating system, library and container updates, certificates and access reviews. Each change needs appropriate testing, a deployment window and a return path. A dependency that no longer receives security fixes may need a replacement plan. This does not mean installing every new version on release day. It means recording the risk, priority and owner. Plan feature development and operational maintenance together so one does not permanently displace the other.
When taking over an older application, first check versions, current error rates, backups and repository access. A supplier cannot responsibly promise stability for a product it has not inspected. For significant changes, tell the client about expected effects and the verification method. If operational risk exceeds the likely benefit of an adjustment, it can be sensible to add diagnosis or a test environment before making that adjustment.
A backup needs a regular recovery test
A management agreement should specify what is backed up, how often, where copies are kept and who may start a restore. The existence of a file does not demonstrate that it is usable. A recovered database has to match the application version and include necessary files or configuration. PostgreSQL offers several backup and recovery approaches for different sizes and point-in-time needs; its documentation explains their trade-offs. Choose according to acceptable data loss and recovery time.
Regularly restore a copy into an isolated environment and test one essential function. Record duration, recovered scope and any obstacle. A copy on the same disk as the application does not protect against losing that disk. Review who can delete backups and how access is controlled. At the same time, do not keep old copies of sensitive information indefinitely without a reason. A retention rule should make both recovery and data handling predictable.
Domains, hosting and suppliers have boundaries
A working web service depends on DNS, certificates, hosting, email, payment systems and other providers. A dependency list should identify account owner, access recovery, renewal date and escalation path. If a domain owned by someone else expires, an application team cannot fix it through code alone. Nor can it guarantee repair of an external API without its operator. It should still recognise the fault promptly and pass on concrete evidence.
Access should belong to the organisation rather than one person's private account with no alternative. Throughout the relationship, review who may change it and where audit records remain. A supplier change must not cause loss of data, repository or domain access. Handover should include exports, documented procedures and removal of permissions no longer needed. This routine hygiene is less visible than a new feature, but it determines whether a service can remain maintainable.
Scope cooperation without vague promises
For an initial brief, prepare a list of applications, operating hours, user numbers, recent incidents, desired response times and existing suppliers. Decide whether you need technical management only, user support as well or ongoing feature development. These activities need different capacity and pricing. The first stage may be an operational readiness review and a near-term repair plan. A realistic recurring support scope can then be based on observed conditions.
A sound agreement describes service boundaries, contacts, measurements, change process, backup, incident response and the end of the relationship. Exclusions should be as visible as included tasks. This page does not assert an unverified EXCOIN SLA, continuous on-call service or owned data centre. A real commitment can only be defined for a particular application and available staff. Management should let the client know what is happening, how a problem will be handled and who owns the next action.