There’s a particular kind of organizational paralysis that sets in around large legacy systems. Everyone knows the system needs to go. Everyone agrees it’s a liability. And yet, nothing happens — sometimes for years. The system keeps running, the risk keeps accumulating, and the conversations about what to do next keep going in circles.

We’ve seen this pattern across industries. But one of the clearest examples we’ve worked through involved a monolithic platform at a large coffee retailer — a system so deeply embedded in the business that more than 20 teams either used it directly or relied on its output to do their jobs. It had reached end-of-life. The technologies it was built on — Silverlight, Internet Explorer — were no longer supported anywhere. The vendor wasn’t coming back to rescue it. And yet the system still ran, because it had to.

What made it difficult wasn’t the technology. It was everything around the technology.

The real problem with legacy systems isn’t the code

When a system touches 20-plus teams across an organization, it means 20-plus teams have built their workflows around it. Their processes, their tribal knowledge, their muscle memory — all of it shaped by a platform that was designed for a different era and a different set of requirements. The technical debt is visible. The organizational debt is invisible, and it’s usually heavier.

In this case, the teams affected spanned both business and technology functions. Some were power users who had workarounds built on top of workarounds. Some had reporting pipelines that depended on the system’s data structure. Some had almost no visibility into how the system worked but would feel the effects immediately if it went down or changed behavior unexpectedly. Getting all of them into a room to agree on a modernization roadmap would have been an exercise in managed conflict — months of competing priorities, different definitions of success, and leaders from different organizations who had no particular incentive to prioritize each other’s needs.

We didn’t try to get them all to agree. That was the first decision that mattered.

“Getting 20 teams aligned on a roadmap before writing a line of code isn’t a prerequisite for progress. It’s a substitute for it.” — Sirrus7

Start small. Show something real.

The approach we took was deliberately modest to start. Rather than mapping the entire system, drafting a comprehensive migration plan, and presenting it to leadership for approval, we worked closely with the engineering teams and the business users to identify one process — not the most important one, not the most complex one, but one that was representative enough to be meaningful and contained enough to move quickly.

We built a UI for it. Iteratively, in close collaboration with the people who actually used that part of the system every day. Not a prototype. Not a wireframe deck. Something that worked, that they could touch, that showed them what modern could look like for their specific workflow.

That changed the conversation entirely. Abstract modernization debates — what platform, what architecture, what vendor, what timeline — are almost impossible to resolve when everyone is arguing about the future in the abstract. When you put something real in front of people, the conversation shifts. Suddenly the question isn’t “what should we build?” It’s “can we add this?” and “what about this edge case?” and “this is actually better than what we had.” That’s a productive conversation. It’s also how you build the organizational trust that large modernization efforts require.

The counterintuitive lesson about where to start

One of the most consistent mistakes we see in modernization projects is the instinct to start with the hardest problem. The reasoning sounds logical: if we can solve the hardest thing first, everything else will be easier. In practice, it almost always produces the opposite result. Hard problems take longer, generate more disagreement, and consume organizational goodwill before you’ve had a chance to build any momentum.

The other instinct we see — and this one is more subtle — is the impulse to design for the end customer first. It makes sense in theory. The customer is ultimately who the system serves. But in a recovery situation, the end customer never sees the legacy system. The internal users do. They’re the ones who know where the bodies are buried, which workarounds are load-bearing, and which parts of the current system are actually working well beneath the outdated interface. Designing with them, not just for them, is what turns a modernization project from a technology exercise into something the organization can actually adopt.

In this engagement, that meant spending real time with the people who used the system — understanding not just their workflows but their frustrations, their unofficial documentation, their accumulated institutional knowledge. Some of what they knew wasn’t written down anywhere. Some of it contradicted what the official system documentation said. All of it was essential.

What this project taught us

1. Not every team needs to align on every decision. With 20-plus stakeholder groups, universal consensus is a fantasy. The goal isn’t agreement — it’s enough shared understanding to move forward without creating blockers downstream.

2. Competing priorities at the leadership level are a given, not a problem to solve. Leaders from different organizations have different mandates. Trying to get them to agree on a comprehensive roadmap before work begins is a way to ensure work never begins. Show progress first. Alignment follows momentum.

3. Don’t start with the hardest process or the most complex technology. Start with something representative and completable. The goal of the first iteration isn’t to solve everything — it’s to prove that progress is possible and build the organizational confidence that larger decisions require.

4. Start with the internal user, not the end customer. In a recovery situation, the people who know the system best are the ones who use it every day. Their institutional knowledge is irreplaceable. Design with them first — their buy-in is what makes adoption possible.

5. Something real beats something comprehensive. A working UI for one process creates more organizational momentum than a 40-slide roadmap for the entire system. Tangible progress changes the conversation in ways that planning documents never do.

What this looks like beyond coffee

The specifics of this engagement are particular to a large food and beverage retailer with a sprawling internal technology footprint. But the pattern is not. We’ve seen the same dynamic in financial services organizations where a core processing system has outlived the team that built it. We’ve seen it in healthcare, where a clinical workflow tool is held together by institutional memory and workarounds accumulated over a decade. We’ve seen it in logistics, where a platform no one fully understands has become too critical to touch and too expensive to keep.

In every case, the path forward looks similar: start smaller than feels comfortable, build something real faster than feels responsible, and prioritize the people inside the organization before you worry about anyone outside it. The technology problems are almost always solvable. The organizational ones are where modernization efforts actually live or die.

If your organization has a system like this — past its expiration date, deeply embedded, and surrounded by a conversation that keeps going in circles — we’d like to talk. The context window is always open.

This article was written with the help of Claude, Anthropic’s AI assistant. The experience, observations, and opinions are Sirrus7’s. Claude helped shape them into something worth reading.

Tags: Project Recovery  ·  Modernization  ·  Legacy Systems  ·  Change Management