Why Your System Replacement Made Everyone Angry

I have rarely seen a core system replacement welcomed by the people who have to use it. Two years of work, the budget spent, and the week after cutover somebody says the old one was faster.

Technically it succeeded. It runs. Nobody thinks anything got better.

The background everyone knows

In September 2018, METI published its DX Report. It warned that if companies left existing system problems unaddressed and management reform was delayed, Japan could face economic losses of up to 12 trillion yen a year from 2025. That became the "2025 Digital Cliff". At the time roughly 80% of corporate IT systems were described as legacy.

The work continued. Under the Priority Plan for the Realization of a Digital Society, a Cabinet decision of 21 June 2024, a Legacy Systems Modernization Committee was set up with METI, the Digital Agency and IPA as secretariat. Its comprehensive report, covering discussions from July 2024 to March 2025, was published on 28 May 2025.

Seven years on, it is not finished.

The data says something less obvious

IPA's DX Trends 2025 asks companies about the state of their legacy systems and compares Japan, the US and Germany. Japan's answers are unusual.

The share answering "we have no legacy systems" is the highest of the three countries. The shares answering "almost everything is legacy" and "we do not know" are also the highest. Both extremes at once, a split between companies that finished and companies that have not started.

Comparing 2023 and 2024, the pattern barely moved. IPA writes that modernisation has plateaued.

There is a second result that gets almost no attention. Asked whether remaining legacy systems are holding back DX, fewer than 20% of companies in all three countries said legacy is a major obstacle.

That does not mean legacy is fine. But companies themselves are not naming it as their main blocker, and replacement projects are running anyway, and the people using the results are not happy. Why those things are true at the same time interests me more than the cliff does.

The screens are being treated as a specification

A replacement project usually starts with an inventory of the current system. Count every screen. Count every report. List every function.

That is correct work. The problem is what happens next, when the inventory becomes the requirements.

Current screens are not requirements. They are sediment. Break one open and you generally find a mixture of things.

Work that is genuinely still needed. Something added years ago for a regulatory change that a later change made unnecessary. A confirmation step added after one incident that happened once. A field that existed for a specific person who left the company. And, most often, a workaround the team invented to get around a limitation of the old system, which hardened over time into an official procedure and then got a screen.

That last category is the dangerous one. A workaround has become the process. The new system does not have the limitation. The workaround gets migrated anyway.

So the team receives a system that still makes them work around a constraint that no longer exists. Of course it is not faster. No step was removed.

What "the old one was faster" actually means

That complaint is usually accurate.

Someone who used the old system for ten years has internalised optimisations built around its slowness. Where to press tab. Which order avoids triggering a recalculation. Which screen to enter from to skip two steps. All of that becomes worthless on day one.

If the new system has the same number of steps and zero accumulated skill, it will feel slower. If you did not reduce the number of steps, that judgement stays correct forever.

Which is why the real test of a replacement is not how noisy the first month is. It is whether the step count went down. If it did, the verdict reverses as familiarity builds. If it did not, it will still be true in two years.

Change the order of the work

Stop deciding the architecture first. Decide the shape of the work first.

Decide what you are not migrating, before anything else. Split the inventory into keep, drop and decide later. Decide later always becomes keep, so give it a deadline. Done seriously, this usually drops 20% to 30% of the inventory. If nothing drops, the exercise has not really been done.

Write the flow of work, not the screens. Who does what, in what order, and who is waiting for whom. Screens come last. Look at screens first and you will never escape the structure of the old system.

For everything you keep, write one line saying why. Anything you cannot justify in a line does not need to be kept. "It has always been like this" is not a reason, but it is an honest answer, and having it written down moves the discussion along.

Count states, not screens. Error, empty, loading, no permission, connection lost. The state count is the real size of the project. Twenty screens routinely means sixty to eighty states. A plan built without counting them falls apart during implementation, every time.

Put the people who do the work in the room in week one. Not for acceptance testing. For the meeting that decides what does not get migrated. They know which steps are load bearing, and they are the ones who will operate the result.

The question that does the most work

In replacement meetings I always ask one thing.

Are you doing it this way because the current system works this way?

Every time, there are a few steps where the room goes quiet. Those are the ones you can remove. And if you migrate them without finding them, the old constraint survives inside the process long after it has left the software.

Ten years from now, whoever runs the next replacement will look at the same screen and find that nobody knows why the procedure exists. This project will be the reason.

Replacing a system is not the same as replacing the work. Do only the first and all you have modernised is the invoice.

References

• METI, DXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～, 7 September 2018. Source of the projection of up to 12 trillion yen in annual economic losses from 2025 if existing system problems are left unaddressed
• METI, Comprehensive Report Compiled by the Legacy Systems Modernization Committee, 28 May 2025. Secretariat of METI, the Digital Agency and IPA, covering discussions from July 2024 to March 2025
• IPA, DX動向2025 and the full report PDF, section 2.5, figures 2-17 and 2-18