Technical debt at scale: inside SAP’s refactoring program
Contents
Harald Aamot, Development Lead for Large Scale Refactoring at SAP, put the Apollo 11 crew portrait on screen at Code Remix Summit and asked the room which of the three astronauts maps to large-scale refactoring.
His answer, the man in the middle. Michael Collins flew a quarter of a million miles to the moon and never set foot on it. While Armstrong and Aldrin took those first steps, Collins stayed with the command module Columbia, alone in lunar orbit. Then he flew all three of them home.
“Everybody’s heading for the moon. Everybody’s going on the AI journey. Sooner or later we will need somebody that can bring us back safe to Earth.… looking at refactoring code bases at scale on a rule-based level combined with AI, I see large-scale refactoring as this critical path to get safely back on the ground.”
— Harald Aamot, SAP
SAP’s Hyperspace LLM proxy became generally available to SAP’s entire development community, tens of thousands of developers, in early 2026. Code change on the corporate GitHub has been, in Aamot’s words, “simply exploding.”
SAP corporate GitHub
Repositories updated per month, 24 months to April 2026
The pace of change has been accelerating since SAP’s cloud transformation, with code that now evolves every 6 to 12 months. With AI, it’s simpler to change code all the time. SAP’s challenge is to make sure it never feels that way to customers, who still expect decades-long stability.
“We cannot change that the world is changing,” Aamot said. “The world keeps spinning.” What SAP can control is how the change lands: migrate more often so each step stays small, automate the upgrades and migrations, keep up with technology changes instead of saving them up for a decade-sized jump. Hiding that much motion from customers, across thousands of repositories, is command-module work.
Watch Aamot’s full session that tracks how refactoring at scale with Moderne and OpenRewrite became a sanctioned business capability at a 100,000-person company.
Tech debt remediation is a rate, not a project
As the pace of change speeds up, compounding technical debt makes it harder to keep up, let alone get ahead. SAP’s developers perceive exactly this. Aamot shared the SAP internal DX Survey 2025, which asked 3,754 developers to name their top three blockers to engineering productivity. Poor or missing documentation led with 1,303 votes, technical debt came second with 1,171, and technical dependencies third with 1,114. Developers described the debt and the dependencies as:
Massive, over-engineered legacy code with little test coverage
Culture of shortcuts and throwaway solutions, coping with feature pressure
Over-engineered and over-complicated app stacks
Misaligned priorities and ownership of dependencies across teams
Migrations forced by deprecations, incompatible upgrades
SAP internal developer survey, 2025
Top blockers of development productivity
Developers live between product owners and customers shouting for new features on one side, and technical debt growing on the other. Aamot contends that “Technical debt is there. It will never disappear. It starts to pile up, and you need strategies to make sure it doesn’t get too steep.”
Debt remediation needs to be managed as a rate. Plan capacity at a steady rate, 20 percent, or one day per week, whatever fits the product, and the mountain never gets steep enough to stall feature delivery. Aamot described it as the Kaizen argument applied to large-scale refactoring: small, frequent, controllable changes, because big jumps end in a mess. Held at a constant rate, remediation buys tech stack liquidity, which is the ability to migrate when you want to rather than because you’re cornered.
Getting every constituency excited and engaged
Knowing the answer and getting a 100,000-person company to fund it are different problems. “This is where the politics starts,” Aamot said. Establishing the capability meant getting every community at SAP excited about it, one at a time, with an argument built for each.
Establishing the capability
Who had to say yes, and what won each of them over
Developers came first and took a while. Engineers who had run stable stacks for 10 or 15 years needed a real shift in how they thought about change, and that took nine to twelve months of talks, workshops, and grassroots projects through SAP’s Developer Experience Program and engineering ecosystem, seeded with the opinion leaders who carry weight in the community. “You can dictate a lot of things on engineers,” Aamot said, “but you cannot dictate a mindset. It’s something that grows via communication and workshops.” His operating principle: go where the energy flows. Work with the people who care, and the rest get left out of the activities.
Product owners were won with the capacity-planning reframe. Remediation at a constant rate protects feature velocity instead of competing with it. The best product managers he sees set a specific number for their teams and hold it.
IT operators know the value of platforms. SAP’s tools team already runs Jira and the corporate GitHubs at company scale. They know about simplifying complexity and operating services the whole company depends on. And the pitch nearly wrote itself: host a large-scale refactoring platform, and a lot of developers will be happy with you.
Controllers were, in Aamot’s words, the toughest nut to crack, but also the simplest, because only one thing works: money. Specific migration projects, business cases, return-on-investment calculations and a balanced scorecard, built with the controller’s own help so the numbers spoke their language. One case put the work at 60 employee months without OpenRewrite against 17 with it.
“You cannot advertise the platform. You’ve got to advertise concrete cases where you can save money.”
— Harald Aamot, SAP
Compounding ROI, grounding AI
No single migration justifies a company-wide capability. What worked was what Aamot calls a colorful set of use cases that added up to an overwhelming mass of potential savings.
The scale of repositories does a lot of the convincing. SAP’s cloud ERP alone has 4,000 UI repositories, so one central UI change is instantly a large-scale refactoring problem. And there are security use cases, both knowing whether a CVE actually affects you, and fixing it when it does. Aamot said he ran an impact analysis and saw the panic from the alerts was bigger than the exposure, because the advisory only applied to one specific use case. With proof you don’t use the affected code pattern, you can skip the emergency patch with confidence. And the list goes on:
Recipes that detect PII handling and verify audit-logging calls for the regulated industries SAP serves
Tech-stack transparency and SBOM generation across repositories
A post-quantum cryptography team evaluating OpenRewrite alongside other vendors to find vulnerable algorithms at scale.
Working with the controller on ROI calculations across these use cases made the savings potential of automating large-scale refactoring evident.
Employee months
Then came the executives. The first question Aamot got from the board: “Can’t we do this with AI?”
His answer reached back to an earlier career. Before SAP, Aamot spent ten years at the German Cancer Research Center, where he met Emmanuelle Charpentier, co-inventor of CRISPR-Cas9. Gene editing works because it changes specific parts of the DNA, precisely and repeatably. What if you could do that to code? That’s what a Lossless Semantic Tree makes possible: transformation targeted at the exact code that needs to change, deterministic enough to run across thousands of repositories.
“This OpenRewrite technology and this Lossless Semantic Tree is exactly something where we can see a lot of innovation in the future.”
— Harald Aamot, SAP
Large-scale refactoring was not positioned against AI. It runs, in his words, on a rule-based level combined with AI. The precision is what makes the speed of AI safer.
Implementation: engineered and enabled for scale
Large Scale Refactoring was approved by the SAP executive board as a business capability, delivered collaboratively by Hyperspace (SAP’s internal developer platform organization), the Large Scale Refactoring Center of Expertise (CoE), and Moderne. The plan moves from exploration through rollout to company-wide expansion, and SAP is in the rollout phase today.
Most of what Aamot shared from this phase is operational. Nothing at SAP installs off the shelf. “It’s always super size me,” whether the tool is a security scanner or a refactoring platform. That’s why hosting it with the platform organization mattered so much. The teams that run Jira and the corporate GitHubs at company scale, and that have weathered the AI-driven explosion in GitHub Actions, know how to scale one more platform. Joining them also brought pipelines, automation, and documentation infrastructure that a standalone project would have spent years rebuilding.
The architecture was designed for scale. The Moderne Platform runs on SAP-hosted cloud infrastructure, with connectors bridging into the corporate network, a mass-ingest pipeline building Lossless Semantic Trees, and an Artifactory content-delivery network storing them. It manages three and a half to four thousand LSTs today, with scaling exercises underway toward “the 100,000 barrier maybe next year.” The lesson he repeats is that scale needs to be in the architecture in advance.
Deployment
How the Moderne Platform is wired into SAP
Onboarding developers to large-scale refactoring during the frontrunner phase requires a registration. This was automated with a GitHub issue template: a team files a frontrunner registration, and GitHub Actions and AI take it from there, scanning the orgs the team signed up and ingesting the codebases into the platform automatically. This made a developer’s first contact with large-scale refactoring as easy as opening an issue.
The Large Scale Refactoring CoE operates the platform compliantly, helps teams select and implement the right recipes from a catalog of thousands, fields refactoring questions from across SAP, and runs a growing enablement team to get development teams up to speed. As Aamot put it, in the end it’s always humans standing behind it.
InnerSource: the recipe community
Everything the platform does runs on recipes: deterministic programs that encode a change once (like upgrade this framework, swap that API, fix this vulnerability pattern) and apply it identically across any number of repositories. Thousands of recipes exist off the shelf, but enterprise code is so much more, with internal frameworks, reuse libraries, and house conventions. SAP’s is no different, needing custom recipes written once and shared across teams. With SAP’s InnerSource model, the recipe catalog grows the way the code does: from the teams closest to it. The platform becomes a way to render any repetitive change at scale.
Building the community involved lunches, talks, and consulting from SAP’s InnerSource program team. The process lesson Aamot drew from it is blunt: you can design elaborate structures and contribution processes to encourage InnerSource, but “It’s got to be as easy as possible and as simple as possible. Start small. Make it possible for developers to just contribute something and see their code popping up in the platform.” The commitments are concrete, with every contribution reviewed within three days and experienced contributors becoming reviewers. The OpenRewrite community at SAP now spans 21 repositories, six teams, and 79 contributors.
A key principle of how they operate: “it’s like we are eating our own dog food,” said Aamot. “All the problems that development teams have to upgrade their dependencies, we apply the same techniques to that ecosystem.” Autonomous bots handle dependency updates across the recipe repositories, so the team can point any product team at a working example. One migration is underway now. Ahead of the Spring Boot 4 migration, central technology teams and the CoE are co-authoring recipes so a huge tree of downstream dependencies and reuse libraries can migrate automatically.
All systems go for large-scale refactoring
Aamot’s assessment two years in: “It works so far really stable and really good… Currently, we feel very confident to go up.” Whether large-scale refactoring proves to be the critical path — “we’ll see in two or three years how the journey went.”
Every company is running its own AI moonshot right now. But there’s still a lot of down-to-earth work that must get done across the whole estate: upgrades, migrations, CVEs, impact analyses, and everything coding agents add to the maintenance load. This is work someone has to sell as a company-wide capability, at every level, from the developer to the board, and that’s the hard part. SAP got it done, with a platform to run it, a center of expertise to support developers, and a community writing deterministic recipes that drive large-scale refactoring.
See how Morgan Stanley approached the same conference’s other big question: what happens to code review when AI writes the code.
Related posts
