Replacing one system (typically referred to as legacy - almost in a pejorative way) with another new system can be a big improvement.
Or it can be a complete waste of time and money.
It all depends on the actual quality of the old system, and the actual quality of the new system.
The most common way this manifests is with technology changes. We must rewrite in a modern language like c#. We must switch our JavaScript framework to React. From my experience 90% of these transitions fail precisely because the legacy system is working fine, and _doesn't_ fail. The new system is always 2 years behind, so is never adopted.
Good architecture trumps new language. And there are a lot of legacy systems with good architecture.
There are also plenty of systems with bad architecture. Ones with too much tech debt. Ones that will fail. And these need to be rebuilt, hopefully with better architecture.
So how does a non-technical person tell the difference (hint: they can't). So they rely on their tech team to tell them. But tech teams want to play with new toys all the time so they're not easily trusted. Changing has huge consequences (usability, training, deployment etc) all of which the tech guys don't care about.
The sweet spot is a well architected legacy system, managed by people who both understand tech, and understand the needs of the business,and importantly, understand the architecture so can limit the tech debt created.
Such systems exist, but it's rare. And ironically all too often management doesn't even know they have it, so some upstart convinces them to "rewrite in React".
Agree, but there is also one more point, always allow people that created legacy system to work on new one.
In one of projects I worked there was legacy system that had enough issues causes by architecture, that 95% of workforce was assigned into fixing new and new bugs/regressions.
So business decided to rewrite that system, but mistake they made was to create complete new team for that task. The new team didn't know why previous solution failed, as this was on first sight very simple system, and not knowing all of the hidden complexity made similar mistakes that caused previous system to fail.
And in that way we ended up brand new legacy system that also failed in similar ways.
Fortunately I convinced them to create third version with the same team as this second failed system and it all looked well until..
some well known consulting company was hired and they decided to rewrite everything on react, and 90% of people just resigned from work.
> So business decided to rewrite that system, but mistake they made was to create complete new team for that task. The new team didn't know why previous solution failed, as this was on first sight very simple system, and not knowing all of the hidden complexity made similar mistakes that caused previous system to fail.
The most nightmarish company I ever worked for did this, but took it even further: The two teams (old and new) were set up as competing with each other to see who could create the better solution. The team that lost (for some unclear definition of losing) would often see several people laid off and the remaining members assigned to lower seniority positions on the winning team.
It created chaos every time the CEO set up competitions like this. Few things create infighting and information hoarding quite like setting two teams against each other with the threat of losing their jobs if they let the other team succeed.
One of the big issues with legacy systems is the hidden edge cases that everyone that uses said legacy system doesn't talk about. I call this the 'silent specification'. If you look at the real specification of the legacy system and try to make a modern system with it, the modern system won't work for the users needs. The users attempt to implement the silent specification on the new system and workflows break down, or huge amount of manual mental work need done. So to use the new system it involves a huge amount of retraining to the point you realize you designed the wrong new system for what the user/workflow/job requires.
Or it can be a complete waste of time and money.
It all depends on the actual quality of the old system, and the actual quality of the new system.
The most common way this manifests is with technology changes. We must rewrite in a modern language like c#. We must switch our JavaScript framework to React. From my experience 90% of these transitions fail precisely because the legacy system is working fine, and _doesn't_ fail. The new system is always 2 years behind, so is never adopted.
Good architecture trumps new language. And there are a lot of legacy systems with good architecture.
There are also plenty of systems with bad architecture. Ones with too much tech debt. Ones that will fail. And these need to be rebuilt, hopefully with better architecture.
So how does a non-technical person tell the difference (hint: they can't). So they rely on their tech team to tell them. But tech teams want to play with new toys all the time so they're not easily trusted. Changing has huge consequences (usability, training, deployment etc) all of which the tech guys don't care about.
The sweet spot is a well architected legacy system, managed by people who both understand tech, and understand the needs of the business,and importantly, understand the architecture so can limit the tech debt created.
Such systems exist, but it's rare. And ironically all too often management doesn't even know they have it, so some upstart convinces them to "rewrite in React".