Replacing legacy software: From limitation to opportunity
Legacy software – we all know the image. Those old, familiar systems that have been running for years, but which no one dares to touch anymore. They are like your grandmother's handwritten recipe book: full of wisdom and proven recipes, but difficult to explain to new chefs.
At Hike One, we have helped countless organisations replace their legacy software. From Dura Vermeer's ‘Project Master’ in the construction industry, to the energy- and financial markets– time and again, we see the same pattern. And it always starts with a simple question: how do you transform old systems and make them future-proof again?
Why legacy software is so persistent
Legacy software doesn't just appear out of nowhere. These are systems that have provided loyal service for years, often custom-built for specific business processes. Frequently, they have pushed the boundaries of what is technically possible and what is justifiable in terms of usability.
Legacy software typically:
- Supports complex processes – they contain years of accumulated business logic.
- Has deep integrations – they are interwoven with other systems.
- Contains institutional knowledge – often only a handful of employees know how they truly work.
The problem? The world around these systems changes faster than they can keep up. New employees struggle with the steep learning curve, performance becomes an issue, and innovation is blocked by technical limitations.
Full replacement of the software is risky and difficult to estimate in terms of time and investment. When faced with the choice between investing a hundred thousand in new solutions and potential extra revenue, or replacing existing software that isn't causing major problems today, most choose the innovative solutions. But building a porch makes no sense if the foundation of the house isn't in order.
Fortunately, Hike One has extensive experience supporting trajectories where these kinds of choices must be made.
From Legacy to innovation roadmap
From our experience with more than 200 clients, we have identified a recognizable pattern: moving from Legacy to Innovation.
Fase 1: Status quo
Users and developers experience inefficiency and frustration, but the impact remains under the radar. Workarounds are devised, and real problems haven't come to light yet. The negative aspects do not yet outweigh the investment and risk of replacement.
Fase 2: Boardroom
A business problem arises: technical end-of-life, business-critical processes at risk, or new opportunities that demand renewal. Now, choices are made based on business cases and KPIs.
Fase 3: Exploration
Work processes are mapped out: technology, dependencies, users, risks, and opportunities. This is often the phase with the most resistance from the 'legacy team' – ironically, the team with the most crucial knowledge.
Fase 4: Transition
The newly designed system is built and rolled out gradually while the old one continues to run. This means parallel worlds and high pressure on the legacy team. The balance between building and adding value becomes crucial.
Fase 5: Continuous development
Old systems are finally switched off, the new system is optimised, and feedback is collected to secure knowledge within the organisation.
Lessons from the field
Deep dive into the business case (even as a designer)
At Dura Vermeer, we worked on their Project Master – a complex operational tool for one of the Netherlands' leading construction companies. The key to success? We dove deep into their business case. As a designer, you cannot settle for just beautiful interfaces; you must understand exactly what concrete value your solution creates. Link design to opportunities, revenue, risks, or costs. Only then will you get the boardroom on board and make a real impact.
Keep your troublemakers close
During legacy transitions, we usaually notice the same patterns: the people who were most critical of the plans often turned out to have the most valuable insights. They knew the edge cases and the challenges no one else saw. Don't just design the product, but also the transition to it. The experts—the critical colleagues with in-depth knowledge—can become your most important allies.
New software requires more than a good product; it is a change process. If you only focus on the product and ignore the sensitivities involved (from phasing out certain roles to adjusting a product an employee has worked on for years to keep running), you risk facing significant opposition. This piece of "change management" also requires a design.
Scale up the legacy team temporarily"
With business-critical legacy software, you eventually deal with two parallel worlds: the old software and the new software. Both require the original team of users and developers—either to maintain the old solution or to provide input for the new one. Aside from workload, uncertainty plays a big role: Will there still be a place for me? How much will my role change? The most important thing for the organisation is that everything keeps running. It might feel counter-intuitive because the new software will eventually require a smaller legacy team (or phase it out entirely), but the worst choice you can make during the transition is to downscale this team too early.
Don't fall into the feature factory trap
After the successful transition at Dura Vermeer, we saw a familiar phenomenon: the team wanted to rebuild all old functionalities one-to-one ("feature parity"). But this is exactly the moment to reconsider what is truly valuable. Focus on outcomes, not output. Which business goals do you want to achieve? Which user problems are you solving? What is the user actually trying to accomplish?
From limitation to opportunity
Replacing legacy software is not about technology – it is about organisational change. It’s about embracing change while ensuring continuity. It’s about respecting what was, while building what can be.
The organisations that succeed in this have one thing in common: they approach legacy not as a problem to be solved, but as an opportunity to be seized. An opportunity to rethink processes, create new value, and prepare their organisation for the future.
Because at the end of the day, it’s not about the software – it’s about the people who work with it and the value it delivers. And that is a story always worth telling.