Software maintenance services for your existing application

An existing application brings its own history: code decisions, connected services, previous changes and ways of working that may be only partly documented.

The initial assessment can cover the codebase, hosting arrangement, dependencies, release process, known defects and important user journeys. It should identify what can be tested separately from the live application and how a change could affect existing data or users.

Useful handover material includes setup instructions, system diagrams, recent release notes and details of connected accounts. Access should be authorized and appropriate to the work. Ownership of code, hosting, domains and third-party services also needs to be clear.

If information or access is missing, the assessment should explain the resulting uncertainty and the work needed before making a reliable commitment.

Depending on the application and agreed scope, work can include:

• Investigating reported defects and correcting the affected behavior.
• Reviewing dependency updates and addressing compatibility changes.
• Improving a slow or awkward part of an existing workflow.
• Adjusting forms, reports or administrative tools within an agreed scope.
• Adding checks for important behavior and updating operating documentation.
• Preparing releases and reviewing the application after an agreed change.

The scope should identify affected areas, acceptance checks and exclusions. A small interface request can involve deeper changes to data or business rules, so the visible size of a change does not establish its effort.

Illustrative maintenance scenario.

Imagine a business using an application to review monthly operating records. Staff report that an exported file sometimes differs from the filtered view on screen.

The first task would be to reproduce the discrepancy using representative records and understand which filters or account permissions affect it. A proposed fix would need checks for the affected export and the neighboring reporting workflows.

A request to add scheduled reports could be recorded separately while the export issue is investigated. That new capability would need its own scope, including recipients, timing and handling of failed deliveries.

Release review would compare the exported results with the agreed expected records and confirm that the existing permissions still apply.

Prioritize requests by their effect on users, the importance of the affected workflow and the consequences of leaving the issue unresolved. Include any external deadline or dependency that changes the order of work.

For each agreed change, define the expected result and how it will be checked. Where suitable test facilities exist, review the change there before release. If they do not, establishing a workable test environment may be part of the initial scope.

Changes affecting data need an appropriate backup and recovery approach. Release planning should also identify who authorizes deployment, when users may be affected and how a problem will be reported or a change reversed where feasible.

Keep a record of what changed, what was tested and any known limitations so future work has a clearer starting point.

A support arrangement needs defined responsibilities. Agree how requests are submitted, who reviews priorities, what access is available and which application components are covered.

Availability, response expectations, maintenance windows and any monitoring responsibilities should be stated in the arrangement. Acknowledging a request and resolving it are separate steps; investigation may be needed before effort can be estimated.

Ongoing work should have an agreed process for approving changes, handling new requests and handing over information if responsibilities change.

Estimates depend on the application's condition, available documentation, ability to reproduce an issue, test coverage and the systems involved. An initial investigation may be needed before estimating a repair or improvement.

Separate development and maintenance work from hosting, licenses and external service charges. Larger upgrades, migrations or new capabilities may require their own assessment and release plan.

Describe the application, who relies on it and the problems or changes you want to address. Share the available documentation and access arrangements so we can discuss an appropriate assessment and next scope.

Discuss your project