Modernizing with Respect: Acknowledging the Best Intentions Behind Legacy Code

When we kick off a major system modernization, we often fixate on the new tech stack and the shiny architecture. We map out microservices, choose cloud providers, and plan agile sprints. What we sometimes forget is that the “legacy” isn’t just old code. It’s often someone’s life’s work, a system they built and nurtured for decades. Dismissing that work as “crap” guarantees resistance. It turns potential allies into roadblocks.

That exact frustration is what Michael Plöd shared with us in this installment of Stories on Facilitating Software Architecture and Design. It’s a story about a veteran architect, a stubborn system, and the surprising power of simply asking “why.”

The Modernization Mandate Meets Reality

Michael was leading the architecture for a large legacy system modernization. This wasn’t a small project. We’re talking 20-30 year old systems, COBOL, very old UIs, all embedded in a rigid, hierarchical organization. The company had decided to modernize, throwing around every buzzword in the book: microservices, cloud, agile, DDD, Angular, Spring Boot, DevOps, Kubernetes. Michael called it “conference-driven development.” His job was to sort through the hype and bring some sense to the frenzy.

A Wall of Resistance

Amidst all the modernization talk, Michael encountered heavy resistance from one particular person. This wasn’t just minor pushback; it was outright vetoes in steering committees. Other managers suggested getting this person “under control.” Michael, initially frustrated, found himself struggling to understand the root of this resistance. Why was this person acting like this?

Michael decided to confront the issue head-on. He approached the individual, who was clearly annoyed by Michael’s modernization efforts. “Can I have 30 minutes of your time?” Michael asked. The response was dismissive: “What do you want? Why should I spend time with you?”

Despite the cold reception, they met. Michael started honestly: “I don’t understand the resistance you have towards the modernization efforts”. There’s something you see that I don’t. You have over 30 years here; you know more than I do. I want to understand where your resistance comes from so we can avoid costly mistakes.” The veteran brushed him off, accusing Michael of wanting to “throw everything under the bus.” Michael left dissatisfied.

The Unlikely Confession

Two weeks later, to Michael’s surprise, the veteran approached him. “Let’s meet again,” he said. In the meeting, the veteran revealed: “You need to thank my wife for this meeting.” Apparently, Michael’s initial approach had angered him, and he’d brought that anger home. His wife had told him, “Why don’t you tell him what this fuss is all about?”

What followed was a raw, honest confession. “Listen,” the veteran began, “I started at this company when I was 16. I’m retiring in five years. I was what you young folks now call the ‘rockstar developer.’ I created all of this. This is my baby. Now everyone is running around claiming this system is a pile of crap. I’m struggling with that. Are you aware how much money this system earned the company?”

Michael realized he finally had the context. He responded, “Thank you. Now we are talking. I understand.” He reminded himself of a principle he often shares: “Legacy systems must have been very successful, otherwise they couldn’t pay your daily rates.” He added, “No one 20 years ago got up saying, ‘Let’s build a really bad system.’”

Reframing the Future

Michael explained that the veteran had made excellent decisions for his context – economies of scale, reusability, centralisation. But the environment had changed, shifting towards “economies of speed.” The veteran admitted he’d “never looked at it from this perspective.”

Michael didn’t push. He let it sit. A week later, he approached the veteran with an idea. “You have a really cool chance in your career right now,” Michael said. “You were the architect and lead developer for the first, very successful system that earned this company millions. Now, you can open the gate for a context switch. You can get that system ready for a changing context. You can bring all your knowledge about the company and the system to be the path-maker for the second, very successful architecture here.”

The veteran’s initial reaction was typical: “Michael, I want to kick you out of the room right now because I hate your positive attitude all the time.” But he let it sink in. A few days later, Michael received a simple email: “I’m in.”

Unpacking the Dynamics

• Empathy isn’t a soft skill; it’s a critical architectural tool. Understanding a stakeholder’s history and motivations unlocks progress.

• Resistance often stems from a valid, deeply personal perspective, not malice. Asking “why” uncovers these hidden contexts.

• Framing change as an evolution, not a destruction, allows people to transition their ownership and expertise. It turns a perceived threat into a new opportunity.

• Software Design is a lot more than creating diagrams. It includes active stakeholder management, communication, and emotional intelligence.

• Taking an “emotional risk” by genuinely engaging with resistant individuals can yield significant returns, even if it feels uncomfortable. Michael was prepared for rejection, which helped him maintain his boundaries.

This story is a blunt reminder: architecture isn’t just about systems; it’s about people. You can have the best technical blueprint, but if you don’t bring your key people along, that blueprint stays on paper. Sometimes, the most effective facilitation tool isn’t a workshop technique or a diagram, but a direct, honest conversation and a willingness to listen.