Business-critical software rarely becomes a problem overnight. It usually starts as a useful system that grows around the business: more users, more integrations, more exceptions, more reports, more manual workarounds and more operational dependency. At some point the question becomes unavoidable: should the company modernise the existing application, rebuild it, replace it with a product, or leave it alone and maintain it more deliberately?
The wrong answer is expensive. A full rewrite can destroy valuable domain knowledge hidden in the existing system. A replacement can force the business into workflows that do not fit. A superficial upgrade can leave the real operational risks untouched. The decision should start with evidence, not frustration.
Start with the role of the system
The first question is not technical. It is operational: what does the system make possible for the business?
A system that supports a minor internal process can be treated differently from a system that handles orders, reporting, customer access, production workflows or compliance-sensitive work. The more the company depends on it, the more important it is to understand the risks before choosing a path.
Useful questions include:
- Which teams use the system every week?
- Which customer, partner or operational processes depend on it?
- Which integrations would break if the system changed?
- Which parts of the system are still valuable?
- Which parts are painful because of technical debt, not because the business process is wrong?
- What would happen if the system was unavailable for a day?
This separates dissatisfaction with the system from the business value it still creates.
Understand the current technical condition
A system can be old without being broken. It can also be new and already fragile. The decision should look at architecture, dependencies, deployment, security, documentation, test coverage, data model, integrations and operational ownership.
A Technical Review should identify where the risk actually sits. Is the main problem the framework version? The database? Missing tests? Manual deployment? One undocumented integration? Authentication and access control? Lack of monitoring? Or the fact that nobody owns the system after launch?
This matters because the remedy depends on the risk. If most of the business logic is sound but the deployment process is fragile, a rewrite is probably not the first move. If the data model no longer reflects reality, a user interface refresh will not solve the problem. If a vendor product can replace a non-differentiating process, custom development may not be necessary.
Four possible paths
1. Maintain deliberately
Sometimes the right answer is not a modernisation project. It is ownership. The system may need dependency updates, documentation, monitoring, backup checks and a clearer release process. This is appropriate when the system still works, current risk is moderate, and the business does not need major change.
2. Modernise incrementally
Incremental modernisation is often the lowest-risk route when useful software has become difficult to change. The work can focus on the highest-risk areas first: authentication, dependencies, deployment, integrations, documentation or the parts of the codebase that block development.
Patterns such as the Strangler Fig approach support this kind of phased transition. Instead of replacing the whole system at once, new capabilities are introduced around or alongside the old application while traffic or functionality is gradually moved to the new implementation.
3. Rebuild selectively
A rebuild is justified when the existing system no longer provides a maintainable foundation, but the company still needs a custom workflow or product capability. The safest rebuilds are not blind copies. They preserve the business knowledge that still matters, remove outdated assumptions and define a clearer operating model.
4. Replace with a product
Replacement is a valid option when the system supports a process that a standard product now handles well. The risk is fit. Vendor software can reduce technical ownership, but it can also create new limitations, integration gaps and workflow compromises.
A practical decision rule
Do not ask “is the system old?” Ask:
- What business value does it still create?
- Which risks are immediate?
- Which risks are structural?
- Which parts must remain custom?
- Which parts could become standard software?
- What is the smallest controlled step that reduces uncertainty?
For many companies, the best first step is a Technical Review & Roadmap. It does not force a conclusion. It creates the evidence needed to decide whether to maintain, modernise, rebuild or replace.
Memory(One) perspective
Memory(One)’s role in this topic is not to push one path. It is to help companies understand the system they depend on, identify practical risks and choose a route that protects operational value. Business-critical software deserves a technical decision based on evidence, not panic.
Sources and inspiration
- Netcompany — AI-powered tool for legacy transformation: https://netcompany.com/digitalisation-at-record-speed-netcompany-sets-a-new-standard-with-ai-powered-it-tool-for-legacy-transformation/
- NNIT — Modernize wisely: application modernization in the public sector: https://www.nnit.com/insights/white-papers/modernize-wisely-application-modernization-in-the-public-sector
- Microsoft Azure Architecture Center — Strangler Fig pattern: https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig
- Martin Fowler — Strangler Fig Application: https://martinfowler.com/bliki/StranglerFigApplication.html