Big-Bang Redesigns vs. Legacy Modernization

Big-bang legacy relaunch is usually the worst way to improve legacy UX. It's painfully expensive, risky, time-consuming — and typically attracts too much attention from everywhere, as everybody has stakes in the project.

Legacy is often business-critical, with many dependencies, stakeholders, integrations and a decades-old customer base. By changing it, you change the entire ecosystem built around it. So how do we move the needle in legacy-ridden environments? By changing slowly — and strategically.

Legacy Software Is Successful Software #

We often perceive legacy as outdated, broken systems that cause friction, delays and unnecessary complexity. They are fragmented, fragile, broken, out of support — a liability that everybody in the organization desperately wants to get rid of.

It's partially true, but it's only one part of the story.

Legacy software is also remarkably successful software. Not many products survive for decades — and because it stayed around all that time, it must have served its initial purpose well. For the company, not necessarily for the user. The latter often don't really have a choice, and so it might not be working well, but it doesn't mean it's broken.

It isn't broken — it's misaligned. It still does exactly what it's supposed to do and what it has been designed for. It might be bulky and complex but it's a consolidated result of complex org constraints, feedback loops and established mental models. It just didn't catch up with the changes throughout all the years.

A legacy system's current behavior is optimal for its initial purpose. Yet over time, it reaches a point where it can no longer support new business requirements and new ways of working — simply because it wasn't designed with them in mind.

And so it becomes a business-critical liability that is very hard to change, very expensive to maintain and very disruptive for existing ways of working. Eventually legacy has to be dealt with — not because it's old, but because maintaining it costs too much. In other words, not dealing with it is too expensive.

So when the opportunity cost spikes, the customer value drops. And when the cost outpaces value, modernization becomes urgent.

That's when it's the time for a change. And typically it's already quite late to be successful without high costs, delays and outages along the way. In practice, rebuilding legacy from scratch almost always costs more and delivers less than expected.

Why Modernization Projects Fail #

According to various studies, 65–79% of modernization projects fail miserably, or get cancelled while on the way. Sometimes the reasons are a shift of priorities, or ambitious goals facing messy reality, or just poor understanding of what we are actually dealing with.

There are a few common reasons for failures:

• Internal/external blockers. Late-discovered contracts, dependencies.
• People get worn down. Lots of changes, severe delays, disruptions, back-and-forth.
• Feature-parity trap. Old legacy workflows recreated in new UIs.
• Innovation theater. Trends-driven hype without any business value.
• Feature factory. Focus on features, ignoring UX, people, business.
• Delivered too late. Massive disruption during delivery.

Two of the most frequent challenges are unknown unknowns and Black Swans. With the former, there is often not enough research done to uncover direct and indirect consequences of an intervention in a legacy system. Its critical dependencies and integrations are rarely documented or visible to the company.

Modernization efforts often take years to complete, and due to a long timeline, there is a high probability of Black Swan events — highly disruptive events that shift priorities, budgets, timelines and people. Anything from reorgs to urgent shifts towards AI.

After all, "finished" modernization rarely reflects what the business really needs at this stage. It's merely a modern rebuild of what the organization actually needed 1–3 years ago. And unsurprisingly, it's often followed up with a new modernization effort to "modernize" the modernized legacy system.

To avoid it, we need to make small changes, frequently — and involve legacy system users from day one.

How To Actually Modernize Legacy UX #

One of the most effective ways to get the project running is to set up a working group with legacy users first. Because legacy systems are poorly documented, you will need their insights to understand their desired outcomes, map the landscape and assess the problem space.

When migrating legacy, we are operating at the very heart of the business — with a large ecosystem of applications, data, integrations, customizations, settings, workflows, workarounds and habits around it. So when we change it, we change everything around it. So we need to understand that space well.

Modernization isn't a redesign. While feature parity might be desired, it's rarely a good outcome as it merely replicates inefficient and dated workflows. Modernization is a dedicated effort to decide what to carry forward and what to leave behind. We modernize the product, not the UI. And the key question to answer is: "What should exist now?"

Also, because legacy is so complex and entangled, usually it won't be enough to understand the goals, break them down into sub-goals, prioritize and then work through them. Because of all the dependencies and non-linear flows, we need to apply systems thinking to map them out.

And once we do, we need to choose the right migration strategy — on the spectrum between small incremental improvements and a big-bang rebuild. With it, we either get a fragmented, disjointed Frankenstein experience or two parallel systems with a long runway. Both require significant effort and time commitment.

Choose Your UX Migration Strategy #

Once you have a big picture in front of you, you need to decide on what to do next. Big-bang relaunch or a small upgrade? Which approach would work best? You might consider the following options before you decide on how to proceed.

• Big-bang relaunch. Sometimes the only available option — but it's very risky, expensive and can take years, without any improvements to the existing setup in the meantime.
• Incremental migration. We slowly retire pieces of legacy, often by replacing small bits one by one with a new design. We get quicker wins with a Frankenstein style, but because we are operating on legacy, it can make the system very unstable and fragile.
• Parallel migration. We run a public beta release of the replacement in parallel to using the legacy system. All users can be involved to shape and test the new design in its early stages. We retire the old system once the new one is stable. But before we can do that, we have to cover the cost of maintaining one system and building another.
• Incremental parallel migration. We list all business requirements that a legacy system must complete and build a new product that must meet them reliably. The new system must match the old system from day one. We still test the product early, but with dedicated testing from power users. Sometimes you might provide an option to switch systems until the old product is retired entirely.
• Legacy UI upgrade + public beta. We do some low-risk fine-tuning work on the legacy system to align the UX with the rest of the product. We build a new system incrementally in the meantime, running a public beta to involve users and stakeholders. We get quicker wins but also long-term wins. A good solution if you need results fast.

Replacing a system that has been carefully refined and heavily customized for a decade is a monolithic task. You can't just redesign something from scratch within a few weeks that others have been refining for years. So whenever possible, try to increment gradually, involving users, stakeholders and engineers along the way — with enough buffer time and continuous feedback loops.

There is a lot of nuance in shaping that strategy, from slicing and the Strangler Fig pattern to an Anti-Corruption Layer (ACL) — but typically, instead of feature parity, we define the outcomes we need to improve, and rethink them first. And then we migrate slice-by-slice, not feature-by-feature, focusing on efficiency optimization across each of those slices.

For example, that means finding key workflows that people frequently use, and slowly detaching, rerouting and then replacing legacy workflows with new ones. It's almost like an operation on a living organism, with the goal to never cause disruptions and failures.

Also, we don't need to know how legacy works under the hood — but how it supports (or hinders) the business process running through it. That's how we find thin slices.

Overcome Resistance #

To stakeholders, in legacy projects, failure is not an option. Because we operate on the very heart of the business, expect a lot of attention, skepticism, doubts, fears and concerns. So build strong relationships with key stakeholders and key users and share ownership with them. You will need their support and buy-in to bring your UX work into action.

Stakeholders will request old and new features. They will focus on edge cases and exceptions. They will question your decisions. They will send mixed signals and change their opinions. And they will expect the new system to run flawlessly from day one.

The best thing you can do is to work with them throughout the entire design process, right from the very beginning. Run a successful pilot project to build trust. Report your progress repeatedly. And account for intense phases of rigorous testing with legacy users.

Wrapping Up #

Dealing with legacy is hard. It's a painfully complicated, time-consuming and incredibly unpredictable challenge. There are many risks, systems, people and unknowns involved, and even if it's all considered and understood well, you'll have to do quite a bit of change management to overcome resistance and mitigate risks before turning on the switch.

Don't dismiss legacy as a liability. Typically, there will be many more people fighting to keep it as-is than there will be people pushing to change it. If you raise a red flag early and slowly improve legacy, you will make a tremendous impact in your org — and that impact will rarely go unnoticed.

Useful Resources #

• Visualizing The Systems Behind Our Designs, by Justin Farrugia
• Report: Why App Modernization Projects Fail, by vFunction
• Facing Complexity: Wicked Design Problems, by Daniel Christian Wahl
• The Knowns And Unknowns Framework For Design Thinking
• Black Swan Theory
• Root Causes vs. Root Systems, by Saeideh Bakhshi

Useful Books #

• Thinking In Systems, by Donella H. Meadows