Every legacy platform was new once. Over time it picks up extra features. Bolted on to fix whatever was urgent that quarter. Soon nobody on the team is sure which parts actually matter. We wrote about how that happens in How to Prevent Digital Products Becoming a Frankenstein Platform. This piece is about what to do once you're already there.
We rebuilt NTT Consulting's network lifecycle platform. The brief wasn't just "make it modern." It was "make it modern, and don't let users notice the ground shift." That's the real challenge in most modernisation projects. It's easy to get wrong.
Modernising legacy software means supporting the people who use it
Engineers tend to see this as a technical problem. Old frameworks. Slow builds. Tools that no longer get updates. Those are real, but they rarely sink a project on their own. What sinks it is a team with years of habits built around the old system's quirks. A new build quietly removes a workaround three teams depend on. Nobody notices until it's live.
Users don't read changelogs. They notice when a button moves. Or when a report takes one extra click. Or when a number they trusted suddenly looks different, because the maths behind it was "fixed." Trust lost over something that small takes a long time to win back.
A few things that make the difference
Run the old and new systems side by side. For longer than feels comfortable. This brings up the edge cases nobody wrote down. It also gives users a way back, if something genuinely breaks.
Talk to the people who've found the workarounds, before you change anything. If someone's been exporting data oddly for three years, it's rarely laziness. They've usually found a gap the old system never closed. That gap needs solving properly in the new build.
Move data and logic separately, where you can. Bugs are easier to spot when you're not moving years of data and rewriting the rules at the same time.
Keep one visible owner for the change. Not a project board. A person. Someone users can message when something feels wrong. Someone who can fix it fast, not log a ticket into a queue.
What good modernisation actually looks like
With NTT, the result didn't look very different on day one. It loaded faster. It handled more traffic. It gave the team room to add features the old system couldn't support. All without a single week of disruption to the work the platform was already doing. That's the right way to judge success. Not how much changed, but how little anyone had to notice.
Sitting on a platform you know needs rebuilding, but worried what breaks along the way? Talk to us early. Before the migration plan even gets written. Get in touch and we'll walk through a low-risk path for your system.