APIs are the backbone of enterprise platforms, yet many continue to operate on unsupported frameworks alongside modern services. This mismatch introduces inconsistent standards, security risks and growing technical debt, slowing delivery and increasing operational friction.
In large enterprises, APIs evolve over a decade or more, accumulating undocumented behavior, implicit contracts, and hidden dependencies. As a result, modernization becomes less about rewriting code and more about rediscovering intent.
Most modernization effort is spent understanding existing behavior rather than implementing the new solution. However, AI-driven migration offers a new path forward by accelerating API uplift activities such as dependency discovery, instruction-guided controller migration, and the transformation of legacy unit tests into modern test suites.
The challenge
Recently, a Thoughtworks team helped a client modernize an enterprise platform. Aware of the challenges of understanding the existing system, we developed a migration framework that uses AI to orchestrate & accelerate legacy API modernization
The client’s platform, which powers a B2B retail app, is supported by 25+ backend APIs across multiple domains, such as invoices, operations and payments. Each contains anything from 100 to more than 1,200 controllers and handles critical operational processes. Built more than a decade ago on .NET Framework 4, the system has evolved to meet business demands; this has resulted in increased architectural complexity and technical debt.
While the platform remains essential for day-to-day operations, its legacy foundations now create challenges for maintainability, security and modernization. Addressing these challenges requires a thoughtful approach that reduces risk while maintaining the stability of critical business workflows. The challenges include:
High system complexity: 25+ APIs across domains with large controller footprints (100–1200+) create tightly coupled services and difficult-to-manage codebases.
Aging technology stack: The system is built on .NET Framework 4, which is now outdated and increasingly difficult to maintain or extend.
Accumulated technical debt: Over 11 years of incremental development has introduced inconsistent patterns and complex dependencies.
Security and compliance risks: Legacy framework vulnerabilities in .NET4 have introduced security risks and compliance issues.
Operational risk: APIs support critical workflows. That means any changes could be a commercial risk without careful planning.
Engineering productivity constraints: Large controllers and fragmented logic increase development effort, regression risk and time required for system analysis.
Why traditional API uplifts struggle to scale
Traditional uplift is constrained not by coding effort, but by uncertainty about the existing system: lack of documentation and knowledge stuck only in the minds of those who worked on it (who may no longer be working at the organization) are real and familiar challenges to people who do this kind of work.
Indeed, when working with large, business-critical API ecosystems, the majority of the effort shifts from coding to understanding, validating and coordinating changes safely. In practice, this creates several systemic bottlenecks.
The discovery tax
Before any migration work can begin, engineers must first understand the existing API landscape — its endpoints, consumers, downstream systems and contracts. This discovery phase can be manual and time-intensive, especially in legacy systems where documentation is incomplete or outdated.
Fear-driven development
Each change introduces risk, especially when APIs support existing core business, financial or operational workflows. Engineers will often proceed cautiously, often replicating legacy patterns to avoid breaking anything.
The test coverage gap
Legacy systems often lack reliable automated validation, forcing long manual regression cycles. This can significantly extend release timelines and introduce operational friction.
The practical limits of traditional migration approaches
In practice, traditional API uplift approaches struggle to deliver modernization at the speed required by the business. Taking the environment we were working with, timelines looked something like this:
The average migration velocity would be approximately two controllers per sprint per developer.
Validating regressions would be around four weeks per release cycle.
The estimated timeline for full migration of the 25+ APIs, around 10 years.
Clearly, modernization is slow and time-consuming. Such timelines understandably make large-scale transformation difficult to sustain. This is because prolonged modernization cycles tie up engineering capacity, extend exposure to legacy security risks, increase operational costs, and delay the adoption of modern architectures—ultimately limiting the organization’s ability to innovate and respond quickly to evolving business needs.
From AI as a generator to a guided agent
To streamline API modernization, we introduced a semi-automated, instruction-driven migration framework powered by Copilot. The approach focuses on accelerating understanding of existing behavior and enabling confident transformation through structured guidance.
Instead of treating AI as a free-form generator, Copilot operates as a guided migration agent governed by defined rulebooks. This turns modernization into a consistent and repeatable engineering workflow. The breakthrough was not simply using Copilot, it was constraining it which ultimately led to transforming our approach.
Step |
Traditional approach |
AI-assisted approach |
1 |
Investigate: Gather data manually and analyze incrementally. |
Analyze: process vast data with intelligent pattern detection. |
2 |
Interpret: Apply judgment through careful deliberation. |
Verify: Cross-validate insights with real-time accuracy. |
3 |
Cautiously change: Implement conservatively, minimize risk. |
Confidently evolve: Move fast with data-backed confidence. |
Traditional modernization relies on manual investigation and cautious changes due to limited system visibility. AI-assisted engineering gives clarity and confidence in how the legacy system is constructed, enabling teams to evolve APIs confidently and at scale.Instead of treating AI as a free-form code generator, we introduced a deterministic, instruction-driven migration framework.
The deterministic AI-driven modernization framework
Instruction files: Defining migration rules
To form the foundations of the modernization initiative, we created version-controlled instruction files (YAML/JSON). These captured the rules and patterns required to migrate the legacy APIs consistently.
The instruction set defined modernization rules such as:
Deprecated-to-modern API mappings
Namespace and dependency replacements
Build and project configuration conventions
Test validation rules
Reusable remediation and fix patterns
The evolution of the instruction set
Initially, controller migrations required substantial manual interpretation and experimentation. As engineers migrated controllers, recurring migration patterns began to emerge. These patterns were progressively encoded into the instruction files, allowing Copilot to apply them deterministically during future migrations.
Independent controllers. These are controllers with minimal dependencies that could be migrated directly.
Dependent controllers (low complexity). Controllers with limited dependencies that require targeted adjustments.
Dependent controllers (high complexity). Controllers with multiple downstream dependencies requiring more structured transformation logic.
Supporting library migration. Any controllers that depended on shared internal libraries and utilities.
Controller-level parallelization
To scale the modernization effort, the migration process was structured at the controller level. This meant multiple controllers could be processed independently and in parallel.
Each controller followed a standardized transformation workflow:
By isolating modernization work at the controller level, teams could progress incrementally without requiring large-scale API rewrites.
Multi-layer quality validation
While AI significantly reduced the mechanical effort of migration, maintaining deterministic system behavior remained a critical requirement.
To ensure modernization did not introduce regressions, a multi-layer validation strategy was implemented.
Just-enough unit tests. Instead of attempting to maximize test coverage, the framework focused on targeted correctness validation.
API comparison tests. Automated comparison tests validated behavioral parity between legacy endpoints and migrated APIs.
Consumer regression tests. Full web application regression tests were executed against the migrated backend to verify contract compatibility and ensure downstream consumers continued to function correctly.
The impact of AI-assisted migration
The effectiveness of the AI-assisted modernization framework was evident in the accelerated migration outcomes:
370 controllers successfully migrated within just 3 months of development effort.
Migration velocity increased by 300+% compared to the traditional baseline approach.
Developer productivity improved significantly, increasing from 6.7 to 27.5 controllers migrated per developer per month.
These results demonstrate how AI-assisted modernization can dramatically accelerate large-scale code migrations while improving developer productivity and delivery predictability.
Impact and business value
The structured AI-assisted modernization approach transformed API migration from a slow, manual effort into a scalable and predictable engineering process. By combining deterministic transformation patterns, evolving instruction sets, and AI-assisted analysis, the framework enabled teams to modernize complex APIs with greater speed and confidence.
As a result, the initiative delivered several measurable benefits:
Teams maintained consistent throughput during controller modernization without sacrificing quality.
Instruction-driven patterns standardized migration approaches, ensuring consistent outcomes regardless of individual experience levels.
AI-assisted analysis and fix-loop acceleration significantly reduced repetitive debugging and manual fixes.
Structured controller-level workflows enabled reliable planning and execution of migration milestones.
Increased productivity and reduced regression effort shortened overall modernization timelines.
Modernized APIs with consistent contracts enabled faster integration and more predictable evolution of the platform.
Together, these outcomes demonstrate how AI-assisted engineering can turn modernization from a long-running technical burden into a structured and repeatable transformation capability.
What we learned about AI in legacy modernization
This work taught us a number of important things about using AI in legacy modernization:
AI works best when constrained by deterministic rulebooks.
Institutional knowledge must be codified and made explicit.
The more we migrate, the more patterns we uncover — these patterns are then incorporated as instructions.
Testing maturity is a prerequisite for AI-assisted transformation.
AI reduces mechanical effort; human oversight ensures architectural integrity.
This shifts modernization from a risky rewrite exercise to a scalable engineering discipline. There are, moreover, some important implications for engineering leaders:
For CTOs, modernization needs to be understood as a systems problem. That means it’s vital to Invest in visibility and validation before scaling AI.
For engineering leaders, it’s essential to create version-controlled instruction libraries before expanding AI adoption.
For delivery leaders, remember to measure baseline cycle time before introducing AI to quantify impact.
Building the modernization muscle in the AI era
AI doesn’t eliminate modernization complexity, but when structured properly, it transforms modernization from fear-driven refactoring into confident evolution.
The real innovation isn’t Copilot itself — it’s the deterministic modernization framework that governs the tool.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.