How to redesign legacy systems without losing what made them work
Legacy systems are the quiet backbone of modern life. They power hospitals, governments, banks, factories and transport networks, often running on code older than the people who now use them. Many of these interfaces were built decades ago, when the graphical user interface itself was revolutionary. They did the job. Over time new features were bolted on, rules patched, workflows re-routed. What started elegant became a Frankenstein of buttons, tables and shortcuts. Still it worked.
For years that was acceptable. The previous generation grew up with these tools. They learned the quirks, memorised the pathways and took pride in mastering systems that looked intimidating to outsiders. But that generation is retiring. The next wave of end users expect software to guide them, not the other way around. They’ve grown up with intuitive apps, immediate feedback and contextual help. To them, legacy systems feel like walking into a control room where every switch looks the same.
We’re at an inflection point. These systems can’t simply be reskinned or patched indefinitely. The technical debt is so entangled with the back-end logic that true progress means re-platforming. But rebuilding isn’t just a technical exercise; it’s a human transition.
When the old world meets the new
In healthcare I’ve seen this play out first-hand. A clinical management system I worked on had evolved for over twenty years. Every screen was a story of compromise, with features requested by different hospitals and compliance rules layered one on top of another. To add a new field you had to touch five modules. The UI was functional but dense, the product of a thousand “just one more thing” requests.
When we started modernising it, the instinct was to achieve parity and replicate every existing screen and workflow in a modern UI. But that’s the wrong goal. Recreating inefficiency in a new coat of paint doesn’t move the industry forward. Instead we started by mapping the high-frequency, high-pain interactions — the tasks that clinicians performed dozens of times a day and where friction was highest.
That’s where real change happens. You can’t uplift everything at once, but you can identify the critical paths that define people’s day-to-day experience.
Designing for transition, not replacement
Modernising a legacy platform is not like building a greenfield product. You’re not designing for an untapped market; you’re asking a loyal user base to unlearn years of muscle memory. Change management becomes design work.
In one hospital-care project we found long-time coordinators could navigate the old system with amazing speed, using keyboard shortcuts, tab sequences and mental maps of where data lived. The new interface was clearer, but their hands slowed down. Familiarity had become efficiency.
So we blended the old with the new. The refreshed UI used modern design patterns such as clear hierarchy, progressive disclosure and responsive layouts, but kept small cues from the legacy environment: column naming conventions, the order of tabs, even some shortcut keys. That sense of familiarity helped users trust the new system faster.
It’s a delicate balance. Too much change and you alienate your experts; too little and you lose the opportunity to evolve.
It takes more than design
Transforming entrenched systems isn’t a design sprint. It’s an organisational movement. In healthcare, the product quad of design, product, clinical and engineering needs sponsorship at the highest levels. Without executive and government backing, legacy transformations stall under their own weight.
These projects also require patience from clients who’ve lived through countless “modernisation” promises. What moves the needle is not the technology alone but the governance around it: shared design systems, interoperability standards and a clear roadmap that values human workflow as much as system performance.
Cloud-based infrastructure and API-driven architecture make this more feasible than ever, enabling modular releases and interoperability between systems that were once silos. But even with cloud capabilities, success hinges on one principle: don’t design to mirror the old world; design to make the new one easier to adopt.
The validation paradox
Validating a legacy redesign isn’t like testing a new app. You can’t rely solely on A/B tests or usability scores. The real measure is behavioural: do users trust it enough to switch?
That means involving them early, not just in feedback sessions but in co-design. Let them see the trade-offs. Show what’s being simplified and why. Legacy systems are full of embedded knowledge; extracting that knowledge requires conversation, not just analytics.
One small win came from shadowing users for a week and mapping where their attention fragmented between paper forms, Excel trackers and the system itself. By consolidating those steps and automating the admin tasks behind the scenes we gained back hours per week per clinician. That’s when adoption happens, when design removes friction without erasing familiarity.
Closing
Every legacy system has a shelf life. At some point the cost of keeping it alive is more than the cost of letting it go. But retirement should be intentional, guided by principles and compassion.
Redesigning legacy systems isn’t about modernising for the sake of modernising; it’s about continuity through change. It’s extracting decades of embedded knowledge into a simpler, more connected experience. The goal isn’t to recreate the past; it’s to build a bridge to the future that existing users can cross with ease.
The next generation shouldn’t have to inherit our workarounds. They should inherit our learnings.
