Application maintenance and support planner

What kind of maintenance does your application need?

Answer 12 questions about the importance of the system, monitoring, backups, updates and issue handling. You will receive a practical list of points to agree before an individual maintenance proposal can be prepared.

Start the planner View the maintenance service

A Domin Software specialist and a client define the scope of application maintenance, monitoring and backups

What kind of maintenance does your application need?

Application maintenance and support planner

The result is a direction for discussion, not a contract, SLA, technical audit or confirmation that the system has been accepted for maintenance.

Choose the answer closest to the current situation. An “I do not know” answer identifies a point to agree and is not a mistake.

Do not enter passwords, tokens, customer data, database copies or access configuration.

System importance

1. What needs to be maintained? An informational website or a simple company site. A store, customer portal or application that receives requests. An internal system employees need for daily work. Integrations, imports, queues or background jobs. Several applications or environments. We cannot define the scope yet.

2. What happens when the system stops working? It is inconvenient, but the business can wait for a scheduled repair. Work slows down significantly, but core tasks can continue. An important process stops, but a temporary workaround exists. A critical process stops without a practical workaround, or there is a risk of data loss or an active security threat. This has not been assessed yet.

3. When is support required? Sunday to Friday, 08:00-17:00 Polish time is sufficient. Additional evening or overnight cover may be needed from Sunday to Friday. Pre-agreed support for critical incidents may be needed on public holidays. The system requires Saturday support or full 24/7 cover. We cannot define the required hours yet.

Current safeguards

4. What is known about monitoring? Availability and key processes, integrations or background jobs are monitored, and alerts have a named recipient. We mainly check whether the site or server responds. Alerts exist, but nobody knows who should react or when. There is no monitoring, or we do not know its scope.

5. What is the state of backups? We know what is backed up, where it is stored and have completed a controlled restore test. Backups run, but restoration has not been tested recently. Only part of the system is backed up, or the scope is unclear. There are no backups, or we do not know whether they work.

6. How are updates and releases handled? Changes pass an agreed check, and larger releases have a rollback plan. Updates are planned, but testing or rollback needs to be organised. Changes go directly to production, or updates are postponed for fear of an outage. We do not know the current process.

Ownership and access

7. Who owns the accounts and materials needed for maintenance? The company owns the hosting, domains, repository and required materials and can grant limited access. The company owns some accounts and materials, but gaps remain. Important accounts or materials remain with the previous supplier. Nobody knows who owns the accounts or where the code and configuration are held.

8. What dependencies on other suppliers exist? We know the hosting, payment, email, API and other suppliers and who is responsible for each element. We know the main services, but responsibilities are not documented. We suspect additional dependencies that have not been inventoried. The system does not use significant external services. We do not know.

9. Who sets priorities and accepts the result for the company? One person owns priorities, decisions and acceptance. A lead person exists, but some decisions need other stakeholders. Responsibility is distributed and there is no clear approval route. No such person has been assigned.

Expected cooperation model

10. What is the most important need today? One repair, update, migration or configuration. Regular monitoring, backup checks and planned updates. Ongoing defect handling and modest changes within an agreed allowance. Documented severity levels and first-response times for key incidents. The system needs to be assessed and scoped first.

11. How should issues be submitted? Email or an agreed ticketing system is sufficient. Critical incidents also need a telephone channel under an active maintenance agreement. Issues currently arrive through many channels and need to be organised. This has not been agreed yet.

12. How should larger application development be handled? Maintenance should remain separate from larger changes and new features. Care may include modest development within a written allowance, while larger work is estimated separately. We expect frequent development and need a separate roadmap alongside maintenance. This has not been agreed yet.

Describe your project

Fields marked with * are required.

Full name (optional)

Phone (optional)

Existing system URL (optional)

Describe the need, problem, or expected outcome

Project documents and files (optional)

Another field will appear after you select a file. Every attachment is checked before the message is sent. Up to 5 files, no more than 5 MB each and 10 MB in total. Formats: PDF, DOCX, XLSX, PPTX, ODT, ODS, ODP, TXT, CSV, MD, JSON, XML, JPG, JPEG, PNG, WEBP, ZIP.

Do not attach passwords, API keys, production database copies or customer data.

The form data and source-page address will be sent directly to our email solely so that we can reply. Privacy policy

What kind of maintenance does your application need?

What kind of maintenance does your application need?

Application maintenance and support planner

System importance

Current safeguards

Ownership and access

Expected cooperation model

Your maintenance plan

Describe your project