If a system still supports important work and holds valuable data, a complete rewrite should not be the automatic response. The first task is to locate the real constraint. It may affect the whole architecture, one troublesome module, the data model, an integration or the way changes reach production.
Starting again makes sense when the useful parts cannot be retained safely or when the old solution prevents the business from reaching an essential goal. In many other cases, stabilising the application, replacing the weakest module or moving in controlled stages is a better starting point.
The decision must be based on the actual code, data and operating process. The age of an application or the name of its technology is not enough.
“Let’s rewrite everything” sounds simpler than it is
An old system can be frustrating. Releases take too long, one fix breaks another area and the documentation no longer reflects daily work. A new application promises a clean start, but it can also remove business rules that nobody has written down even though staff and customers rely on them every day.
Data, permissions, reports, integrations and manually handled exceptions all need to be understood and recreated where necessary. If they are overlooked at the beginning, the replacement may be technically cleaner while fitting the business less well.
New code is not valuable merely because it is new. It should solve a defined problem: reduce risk, make future changes safer, improve stability or simplify work for users.
Four possible directions
| Direction | When to consider it | What must be protected |
|---|---|---|
| Stabilise and continue developing | The core system works, while failures and costly changes are concentrated in a few areas. | Critical processes, backups, tests for key journeys, deployment and useful error visibility. |
| Replace one module in stages | One part blocks progress, but the rest of the application still has value. | Data and integration boundaries, plus the period in which old and new modules run side by side. |
| Controlled migration | The current platform or data model has fundamental limits, but the transition can be divided into stages. | Data comparison, the order of switching processes, continuity of service and a way back. |
| Build from scratch | Valuable parts cannot be retained or their constraints make the business goal unattainable. | The full functional scope, hidden rules built up over years, data migration, parallel operation and retirement of the old system. |
This table helps structure the discussion, but it is not a substitute for an audit. The same symptom, such as slow delivery of changes, may come from application architecture, missing tests, an unreliable release process or several causes at once.
Four questions to answer first
- Does the system still handle its essential processes and data correctly?
- Which areas cause the most failures, manual work or expensive fixes?
- Does the technology still receive security updates and run in a maintained environment?
- Can modules be separated and replaced without stopping the whole business?
If the problem is confined to one area, there is no reason to recreate the entire application automatically. A new build becomes more reasonable when the system cannot be reproduced in a dependable environment, key dependencies are unsupported and its data and modules cannot be separated safely.
If a critical PHP vulnerability prompted the decision, first separate the urgent runtime update from the longer-term modernisation. Our guide “Critical PHP vulnerabilities in October 2026: what should you do with an old application?” explains the order of work.
What to inspect before deciding
The assessment has to go beyond the source code. It should establish:
- which processes cannot be interrupted;
- where the data is stored and how it is backed up;
- which external systems exchange information with the application;
- which roles and permissions are genuinely used;
- how testing, deployment, monitoring and rollback work today;
- which workarounds have become part of normal operations;
- what measurable outcome the first stage should deliver.
Without these answers, it is easy to compare the cost of fixing a few visible problems with the cost of an incomplete replacement. That is not a fair comparison. A new system must also account for migration, integrations, retained data, the transition period and acceptance of the critical processes.
When modernisation is the better choice
Staged modernisation has a strong basis when the system is still operating, contains valuable data, serves active users and allows meaningful boundaries to be drawn between modules. The first step can then stabilise critical areas, protect important behaviour with tests and improve error visibility.
The parts that restrict the business most can be replaced next. Each stage should have its own scope, acceptance criteria and rollback plan. Decisions about later work can then use what we have learned from the real system instead of relying only on assumptions made at the start.
When a new build makes sense
A new application deserves serious consideration when the current platform is no longer supported, the data model prevents the required development, the business has changed fundamentally or separating the old system safely would cost more than replacing it in a controlled way.
That still does not require a single high-risk cutover. One process can be moved first, results can be compared and the scope can expand afterwards. Data migration, parallel operation and a route back are parts of the project, not tasks to add shortly before launch.
Portfolio example: different stages of Tempus
The Domin Software portfolio documents several pieces of work completed for the Tempus store. They included cleaning up existing code and developing dedicated modules, updating the platform and visual layer, and migrating from sStore to PrestaShop with products and customers transferred.
This does not mean every application should follow the same path. It shows that “develop or rewrite” does not have to be one permanent decision for the whole life of a system. Repair and further development may be valuable at one stage, while a controlled move to a new foundation becomes appropriate later.
The documented scope is available in the Domin Software portfolio. We do not present it as proof of a particular commercial result or as a ready-made prescription for another business.
OBIBOOK: a repair before the rebuild
In the OBIBOOK project, we first repaired the CSV import and mobile behaviour. Rebuilding the book catalogue was a later, separate stage. A repair needed today and a decision about the system’s future do not have to share the same scope.
Build a bridge instead of making one large leap
During a substantial change, old and new parts may operate together for a time. Selected processes can be directed to the new module, data can move in batches and results can be compared before the scope expands. Users may move in groups rather than changing their whole working environment on one day.
This approach reflects the Strangler Fig pattern described by Martin Fowler. It does not make a complex project simple, but it can reduce the risk of recreating everything in one attempt and allows each stage to be checked.
Where DominPress may fit
When the change concerns public pages, content, forms or new web modules, DominPress can be introduced as a new layer without immediately replacing the company’s entire back office. It is not an automatic answer to every legacy system. The choice should follow the processes, data, integrations and long-term maintenance plan.
What to include in your first message
For an initial discussion, prepare:
- a short description of the system and its users;
- the most important process that cannot be interrupted;
- the specific problem that blocks development or causes errors;
- the technology and version, if known;
- a list of important integrations;
- the expected outcome of the first stage;
- information about current backups, a test environment and documentation.
Do not send passwords, keys, a production database copy or real customer data. At this point, a description of the problem and enough context to distinguish a focused task, a technical assessment or a first modernisation stage is sufficient.
If modernisation involves changing provider, read how to start handing an application over to a new developer. The guide covers the information needed before transferring code and accounts.
Let’s choose the right direction for your existing system
We do not assume that an application must be rewritten. We first establish what still has value, what genuinely blocks the business and how the risk of change can be limited. Our system modernisation service explains the scope of this work.
To begin with a specific case, describe the problem in your existing system.