Contact
Skip to main content
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?
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:
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 our experience with more than 200 clients, we have identified a recognizable pattern: moving from Legacy to Innovation.
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.
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.
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.
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.
Old systems are finally switched off, the new system is optimised, and feedback is collected to secure knowledge within the organisation.
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.
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.
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.
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?
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.
.jpg)
Feel free to contact me!
