What is cheaper: fixing the old system or building a new one alongside

The main mistake is trying to answer with one word

When a system starts blocking the business, two camps appear fast. One says "don't touch it, fix it point by point". The other answers "rewrite everything". Both work as slogans and both are harmful as management decisions. What you need is not a choice between extremes but a comparison of scenarios by consequence: what it costs to leave things as they are, what it costs to stabilise, and where building a new contour alongside the old one is already cheaper.

When repairing the old system is still justified

• Core business scenarios are still predictable and problems are localised in a limited set of modules.
• Ownership is clear, and the team can change things without a cascade of incidents.
• The system does not block the first phase of the business changes you need within a reasonable timeframe.
• Architectural debt exists but can be reduced in a controlled way without putting the business on pause.

When building alongside is already more profitable

If the old system constantly drags critical releases back, makes any integration risky, depends on knowledge nobody has, and turns each task into an expedition through hidden dependencies, the business is paying far too much for the status quo. In those cases a new contour alongside can be cheaper — not by the price of code, but by total cost of ownership. The company stops overpaying for the fear of change and gets room to move.

What to compare besides the development budget

• The cost of repeated incidents and rollbacks after every change.
• Speed of shipping features and dependence on key specialists.
• Damage from downtime, manual operations and loss of control between departments.
• How much the current system allows the product to grow safely.

The right decision model

Not "rewrite everything", but choosing the first phase: identify which scenarios are genuinely critical and where the problem already costs money, decide what can be stabilised in the current system without extra risk, and separate the areas that logically belong in a separate service or new module alongside.

What the business needs as an outcome

Not an ideological answer of "old or new", but a clear economic model of the next step. That is what ends the abstract architecture debate and leads to a decision that actually reduces risk and gives the product room to grow.