Maintaining and Developing Existing Software: When Is Rework Needed?

Maintaining and developing existing software starts with assessing business needs, code, the database, security and integrations. A sound technical foundation can be extended. When the architecture makes necessary changes difficult, targeted rework may be justified while preserving business rules and data. The choice should be supported by the client's future operational needs.

A system can work every day while becoming increasingly difficult to develop. Connecting another external service requires extensive changes. Errors come to light after a customer reports them. The team knows something has failed but struggles to find out what.

When discussing software maintenance, it is important to establish what comes next for the business. The company may need specific problems fixed, ongoing development, or an objective assessment of the available approaches.

The following case from Sirius Software's experience shows how that assessment can work. The client and identifying details have been omitted; the technical problem, decisions and observed outcome are described below.

What does software maintenance include?

Software maintenance can include bug fixes, updates, security checks and monitoring how the system operates. Ongoing development adds features, integrations and changes to business processes. The scope needs to be defined because “maintenance” often covers different expectations.

If the business plans to add partners, automate more work or change how it serves customers, the team needs to assess whether the current architecture can support those changes. Otherwise, each subsequent task may require more effort.

A useful opening question is: what will the system need to do during the company's next stage of development?

A real case: a Symfony system that needed more integrations

This project combined preserving the business rules and public interface with reworking the technical implementation. The reason was the planned development: the existing architecture made adding and monitoring integrations with external services difficult.

The client contacted Georgi Papucharov by phone. They had a system built in Symfony by another team, but its development had become constrained. The existing provider had explained that it could not supply the required specialists.

What did the internal review reveal?

After signing a non-disclosure agreement (NDA), Sirius Software received access to the code and reviewed the application, database structure and integrations. No documentation was available for the system.

The review covered code organisation, relationships between data, including the use of foreign keys to maintain valid relationships between records, and the implementation of external services. Security was also part of the assessment.

The client received a summary of what had been done well and where improvements were possible. The aim was to provide a reasoned basis for the next decision.

Why was rework recommended?

Implementing the required new integrations on the existing architecture would have been less efficient than reworking the relevant foundation first. Some behaviour was hardcoded, and there was no suitable mechanism for monitoring the integrations.

There were also departures from Symfony conventions. Differences in coding style or organisation alone, however, do not justify rewriting a system. The material issues were their consequences for future development, reliability and visibility into processes.

What was preserved, and what changed?

The business rules, data and public user interface were preserved. The technical implementation was reworked where necessary, including the structure of integrations and error tracking.

Scripts and migration mechanisms were developed to transform data from the old structure into the new one. During the switchover, the platform was unavailable for approximately one hour.

Sirius Software continued working on the project for around a year and a half. The team observed fewer incidents and easier implementation of new features. Automated tests and an administrative integration-monitoring interface were introduced, with the monitoring also accessible to the client.

How is existing software assessed before maintenance is taken on?

The assessment starts with business goals and a demonstration of the system, with technical conclusions established through an internal review. The public interface can reveal usability or visible behaviour problems, but it cannot prove code quality, security or the quality of the data structure.

A review of an existing system can cover:

• Code and dependencies: organisation, technologies and versions in use, and the ability to make changes.
• Database: structure, relationships, data consistency and migration requirements.
• Security: access permissions, handling of sensitive information and implementation risks.
• Integrations: data exchange, behaviour when an error occurs and monitoring capabilities.
• Maintenance and deployment: available documentation, tests and the process for releasing changes.

These are areas to assess, rather than a list of defects necessarily present in every project. Conclusions should distinguish confirmed findings, risks and questions requiring further investigation.

When should the code be retained, and when should it be reworked?

Existing code is worth retaining when it provides a sound foundation for secure, predictable development. Targeted rework is justified when a particular part of the system repeatedly creates limitations. A full rewrite requires its own justification covering scope, cost and risk.

At Sirius Software, we maintain and develop systems created by other teams. Rework decisions are based on the software's condition and the client's needs. A developer's personal preference for a particular style is not sufficient reason for additional expenditure.

Why is integration monitoring part of reliable software maintenance?

Monitoring helps establish which integration has encountered a problem, what has been affected and what action is needed. When software depends on external services, that visibility matters to the client's daily operations.

In this project, the team added logs, notifications, retries, an administrative monitoring interface and a classification of errors. Different problems could then be examined in a structured way.

For the business owner, the benefit is practical: they can check integration status through the administration interface instead of waiting for a developer to investigate every question.

Retries also need rules. A temporary connection failure and invalid input data should not be handled identically. Operations with side effects need safeguards against duplication.

For Symfony, the official Messenger documentation describes retry mechanisms and handling of failed messages. An available tool still needs appropriate configuration and business rules.

For a practical example involving stock and orders, see our guide to connecting an online store to warehouse or ERP software.

Can modernisation preserve day-to-day operations?

Modernisation can preserve data, core business rules and the familiar public interface. Whether downtime is needed, and how long it lasts, depends on the system structure, data volume and migration approach.

In this case, the interruption lasted around an hour. That was the outcome for this project, rather than a standard timeframe for other platforms.

When planning a migration, it is sensible to define data transformation and validation, when writes to the old system will stop, what happens if the switchover fails, and the checks after launch. Automated tests help verify the scenarios they cover but cannot rule out every possible problem.

A useful plan explains what will change, what will be preserved and how the outcome will be checked.

What determines the cost and timing of software maintenance?

Cost and timing depend on the system's current condition, the required scope and its planned development. Without a review, a fixed figure may overlook important dependencies or problems.

The estimate should distinguish ongoing maintenance from one-off rework and new development. Adding an integration, updating dependencies and responding to an incident are different tasks.

Priorities, the criticality of processes, expected response times and the included scope should be clarified. Response times need to be agreed explicitly.

When comparing proposals, consider the total effort for the next planned changes too. An initial, limited rework can make sense if it removes a constraint that would otherwise increase the cost of every new integration.

How does working with Sirius Software begin?

The first step is a free consultation about the business case and the existing system. The aim is to understand the difficulties, the required development and a reasonable next step.

1. Enquiry: describe your system, the difficulties you face and what you want to add.
2. Conversation and demonstration: we examine the public interface or a demo and clarify the important processes.
3. Confidentiality and access: when an internal review is needed, we sign an NDA and agree access to the code and related resources.
4. Analysis and recommendations: we review the structure, versions and dependencies, and explain what should be retained or improved.

You do not need to send source code or passwords with the initial enquiry. A system URL, a description of the current problem and the most important planned changes are useful starting points.

Sirius Software can also provide objective recommendations for improving an existing codebase, regardless of whether it subsequently takes on maintenance. The consultation does not commit you to commissioning development.

Frequently asked questions

Can a system be maintained without documentation?

A lack of documentation does not prevent another team from taking on maintenance, as this case demonstrates. Behaviour, dependencies and business rules need to be established through the code, data and discussions with the client. The effort depends on the system's complexity.

Does another team's code always need to be rewritten?

No. A codebase with a sound foundation, suitable technologies and an acceptable security condition can be maintained and developed. Rework should solve a specific problem and have a clear justification.

Can the design be preserved during technical rework?

Yes, when the technical dependencies allow it. The public user interface was retained in this project. Changes to the database and internal implementation do not automatically require a complete redesign.

Discuss maintenance and development of your system

If your existing software has become difficult to develop, send an enquiry for a free consultation. Include the main problem, important integrations and the changes you are planning.

We will contact you to understand the business case and discuss possible next steps. You can find more about our approach in our software development service.

About the author: Georgi Papucharov is a co-founder of Sirius Software with practical experience in maintaining, developing and reworking business systems. The case is based on his account.

Technical sources: Symfony Best Practices and Symfony Messenger: retries and failures. Checked on 16 October 2026.