What do you do when your home is mid-renovation, has no lighting, and you have to give a video presentation without even a virtual background to hide the mess? You cobble together whatever you can and stage a small clean area to hide the chaos just outside the frame.
That’s the metaphor that Dov Katz, Managing Director and Distinguished Engineer at Morgan Stanley, used to describe his experience managing tech debt as an engineering leader at Morgan Stanley. It’s that feeling of trying to address large technical renovations while balancing it all with the need to keep the systems up and running.
At Morgan Stanley’s scale, with tens of thousands of repositories and more than 15,000 developers, that tension is amplified. It’s a constant battle for companies across the industry to keep everything secure, modern, and maintainable. Strategic upgrades are hard to implement when faced with incremental drift of functionality and the pace of change that open source frameworks bring.
The reasons for this are familiar to anyone at enterprise scale:
- An evolution of needs and code drift across teams
- Legacy design choices that may be hard to unwind
- A growing queue of security vulnerabilities and complex interdependencies in the open source ecosystem
- The constant challenge of balancing priorities among functional and nonfunctional changes
The bigger problem? Technical debt isn’t just slowing down progress, it’s consuming the majority of it.
Let’s dive into Dov Katz’s Code Remix Summit presentation to learn how Morgan Stanley is leveraging Moderne and the power of mass scale code refactoring and modernization to tackle their technical debt. You can watch the full session here:
Patterns that promise relief (but often don’t)
Enterprise teams have been dealing with this problem for years and have tried addressing it a few different ways:
- Opinionated platforms. Rely on an internal platform team to maintain a shared, up-to-date services stack. If developers build on that platform, they get upgrades for “free.” Developers gain alignment but lose autonomy.
- Upgrade factories. Centralize the refactoring work entirely with a dedicated team churning out bulk code change and acting as an upgrade factory. While this may seem efficient, it often results in a barrage of pull requests that developers neither trust nor want to merge.
- Governance groups. A committee is formed to track the riskiest applications and prioritize which ones need particular attention to decide what to upgrade first. This creates a culture of consequences and only addresses a smaller subset of code.
During the presentation, Katz offered several suggestions for solutions that organizations can explore to overcome some of the limits of these models.
You need more than a hammer: The nuanced dev toolkit
Many existing tools are simply now better at finding things for developers to deal with. The pace of change and the flood of issues—from tech debt to rising security vulnerabilities—has made this work a competitive threat to getting actual product work accomplished.
And there is no end to the influx of new tools and methods that go beyond surfacing issues to actually resolve them. With so many choices, it's important for teams to first make sense of the tooling landscape before focusing on some strategic bets.
“You can’t just go in and look at one tool and say, ‘Hey, this is the only tool you’re going to need,’ because there’s 12 other people talking to leadership about their tool, about their thing,” said Katz. “...you have to recognize that there’s a combination of ways to fight this and you need to find the most effective way to use your budget to do that.”
Some tools help with version bumping, making safe, incremental upgrades that don't require deep context. To tackle more complex, language-specific code changes, however, there are different tools. While some opt to modify code using only text-based manipulation, OpenRewrite takes a more sophisticated approach by using Lossless Semantic Trees (LSTs) to analyze and modify code with precision and repeatability. This enables deterministic, large-scale refactoring across repositories and tech stacks.
The advent of generative AI has brought a new way of trying to solve these problems. While powerful, that approach comes with tradeoffs: high compute cost, limited determinism, and questionable scalability across thousands of repos. As Katz stated, “When you have thousands of things that need to be fixed, you’re not going to use generative AI to do that.”
Ultimately, the team embraced a hybrid model built around flexibility and real-world needs. This isn’t a hammers-and-nails situation—the best approach encompasses both the precision and scale of OpenRewrite with the creative power of generative AI.
Change of this nature doesn’t just require tooling, it takes a shift in how modernization efforts are framed, executed, and owned.
Building trust with developers first for multi-repo change
Even the best tools won’t help if developers don’t use them, though, so leaders should prioritize buy-in from the start to achieve the right level of support. As Katz said, “come with a solution, not a problem.”
One way to do that is by starting a proof-of-concept and building coalition of engineers early on in the process to help test and champion the approach. But there needs to be a "zero-friction" experience to make things easy for them. Any infrastructure required should be wired up in advance to give developers that feeling of instant gratification. In case of the Moderne Platform, for example, repositories can be connected, LSTs prebuilt, and the environment made ready to go for when engineers arrive.
When developers see their own code being improved, it can become a lightbulb moment that builds trust and momentum to keep them engaged. This way, the focus is on developer ownership rather than top-down mandates.
Solving big-scale problems: Recognition and results matter
Before expanding any initiative company-wide, Katz suggests building a support structure: training, communications, and a recognition loop to validate contributions. That way, developers who deserve credit for solving problems not just for their teams, but for the entire company, have a way to be recognized for it.
Critically, success should not just be measured in time saved. Instead, frame it as capacity recovered. Katz explains: “You want to take the capacity you’re wasting, and move it back to do things for your business, or your product, or your customer, that you’re not doing.”
The goal isn’t to shrink teams, but to let engineers focus on value instead of maintenance.
Insights for modernizing your codebase
There is a neverending need for modernization and migration within enterprise codebases, and it's often a multi-year effort to roll out a solution. For large organizations facing this problem, there are some key takeaways from Katz that can help:
- Start small, but think big. A proof of concept built credibility and momentum.
- Use real code in demos. Sample projects are fine, but real repos build trust.
- Make developers the owners. Autonomy and accountability go hand in hand.
- Celebrate and measure outcomes. Recognition fuels adoption and culture change.
- Perfect is the enemy of good. Get tools in people’s hands early and improve as you go.
Tech debt at enterprise scale can feel overwhelming. But with the right mix of tools, trust, and thoughtful process, it’s possible not just to stay afloat, but to rebuild something better. Contact us to see a demo and learn more about how the Moderne Platform can help.
