The budget is usually wrong before the project starts
Most modernisation budgets are wrong before the project begins, because they assume modernising means building more. It rarely does. The biggest lever in a modernisation is not what you build. It is what you decide not to carry forward.
There is a popular idea that good engineers delete more than they add. True, but that is about your own code, where you know why every line exists and you can retire it with confidence. A modernisation project is a different and harder thing. You are judging someone else’s decade of decisions, made by people who have moved on, under pressures you never saw. Subtraction is still the goal; it is just that the judgement required to subtract safely is far rarer than the skill required to rebuild faithfully.
The pattern: the faithful 1:1 rebuild
Here is the pattern I see again and again. A team scopes the rebuild as a one-to-one replacement of the legacy system. Every screen, every report, every integration, ported faithfully into the new stack. It feels responsible. It feels safe. It is the expensive mistake.
Because a real share of that old system is dead weight. Features nobody has opened in years. Integrations to partners the business no longer works with. Workarounds built for problems that were fixed three vendors ago. In most ageing custom systems, that is somewhere between a fifth and two-fifths of the surface area, openly estimated, but consistent across the systems I have worked on. Porting it faithfully means paying full price to rebuild complexity you should have interrogated, and handing the new system a head start on its own technical debt. The clock on the next legacy system resets on day one.
The skill that actually moves the needle
The capability that changes the outcome of a modernisation is not framework knowledge. Frameworks are learnable and, frankly, commoditised. The thing that is hard to hire for is the judgement to walk into unfamiliar legacy code and decide what earns a place in the new system and what gets retired.
That judgement is uncomfortable because it cannot be made purely from the code. A feature that looks abandoned might be the one thing a regulator checks once a year. A workaround that looks absurd might be encoding a real constraint nobody documented, the same undocumented business logic that, missed, gets the new system bypassed on day one. So subtraction is not slash-and-burn. It is the disciplined work of separating the dead weight from the load-bearing, and that requires sitting with the people who use the system, not just reading it. It is the same discipline that distinguishes a serious legacy audit from a rewrite that simply re-implements yesterday on newer infrastructure.
I have spent most of my career on both ends of this: large-scale delivery where scope discipline is the difference between shipping and not, and smaller systems where one quiet, well-meaning workaround can derail a quarter. The lesson is the same at both scales. The team that wins is the one allowed to say no.
Measure by scope removed, not features re-implemented
So if you are scoping a modernisation, change the metric. Measure success by scope removed, not features re-implemented. A smaller, sharper target system is the win, not the consolation prize. It is cheaper to build, faster to operate, and it does not inherit the accumulated weight of decisions the business has already outgrown. This is also why composability and subtraction go together: a composable architecture lets you retire a capability cleanly instead of dragging it along because it is tangled into everything else.
The hard part is organisational, not technical. Faithful porting feels safe precisely because nobody can be blamed for keeping something. Retiring a feature is a decision with a name attached, and names attract risk. Which is why the real question worth sitting with is not what should we build? but: how does your team decide what does not make the cut, and who is allowed to say no?
If you are about to fund a rebuild and the scope is “everything the old system did, but new,” that is the moment to stop and interrogate it. Talk to TrueForge and we will help you find the share that should not move at all.