Tags
Share
Exadel is a Cursor Transformation Partner. This is what it looks like when we modernize a legacy codebase.
It’s a great irony that the systems with the most to gain from AI-assisted development are often the ones least ready for it. These are usually monolithic platforms that predate the teams now tasked with maintaining them. Test coverage is either patchy or largely absent. The available documentation often describes a system as it existed two rewrites ago. And important conventions may exist only in the minds of a few veteran engineers.
Yet these are precisely the systems that dominate every modernization backlog.
When we committed to our partnership with Cursor, we pledged to take AI-native development beyond early adopters and into entire engineering organizations. Legacy modernization is perhaps the toughest proving ground for that ambition. Codebases can be so complex that modernization gets pushed from one planning cycle to the next, while technical debt continues to accumulate.
So what does an AI-assisted legacy systems modernization engagement actually look like in such an environment? This article follows the process from the first assessment through to release, with Cursor integrated into the engineering workflow throughout.
When an AI Agent Meets a Legacy Codebase
Much of legacy systems modernization involves large volumes of repetitive work: adding characterization tests to untested code, upgrading frameworks and dependencies, removing dead code, and regenerating documentation. Each change may be small, but there can be thousands of them—far more than most teams can tackle manually. This is where AI agents come into their own.
But there’s a catch, and it helps explain why so many enterprises have Cursor yet still modernize by hand. An AI agent is only as good as the context it’s given, and a legacy codebase will punish an agent the same way it does a new hire. What if there’s no test to check the work against? Or the module that appears so authoritative was replaced two years ago but never deleted? Or what if part of the codebase follows entirely different conventions because it came from an acquisition that was never documented?
That’s why preparing the codebase for agents is a fundamental part of legacy code modernization with AI agents. Most of it is the type of modernization work that gets deferred every year: generating tests for code that's never been properly tested, removing dead code, matching documentation to the system, and capturing conventions in writing. The genuinely agent-specific work of setting up rules and ‘ignore files’ is largely configuration and relatively inexpensive. The expensive part is the modernization work you were going to pay for eventually. Once the codebase is ready for an AI agent to work with, it can take on much of the repetitive work, including generating the next round of tests.
What Enterprise Modernization With Cursor Looks Like
Setting the Modernization Baseline
We start by assessing the current state of the system and its readiness for AI agents. That means looking at repository structure, test coverage, documentation quality, and how consistently the code follows established conventions. At the same time, we establish a delivery baseline before anyone starts using Cursor. This covers cycle time, review load, and defect rates. Without that baseline, how do you know a few months down the line what actually changed? And in our experience, that’s a question that always comes up.
The assessment is time-boxed and the results are captured in a single document. It sets out the business case for modernization, how far the codebase is from being agent-ready, the delivery baseline, and the scope of the AI engineering work for the first modernization stream. Even if the engagement goes no further, you come away with a clear business case—something you would have needed anyway.
Establishing Governance From the Start
We establish the governance model before the pilot begins. One of the first questions is where the code goes: private cloud, on premises, or bring your own key. Identity is the easy part since most enterprises already know how to run SSO and SCIM.
Whether an audit goes well really depends on what happens inside the agent loop. Cursor provides team-level controls for model allowlists, MCP servers and repositories. It also keeps audit logs of administrative and configuration changes and allows hooks to be distributed to every seat from the team dashboard. We pay particular attention to hooks because they can turn written policies into controls that are enforced and recorded. That could mean a scan that blocks prompts containing key material, a gate on commands that access production data, or a log of which files an agent reads on a regulated path.
Review standards get the same treatment. AI-assisted pull requests go through automated review using the project-specific context in .cursor/BUGBOT.md before reaching a human reviewer. Because the review leaves a record an auditor might read later, human approval before merge remains a standing rule—not a training wheel we remove later.
Since some of these controls require Cursor’s Enterprise plan, we work out which plan is needed during the assessment—rather than finding out during the rollout. Cursor provides the controls. Our engagement turns them into a policy an auditor can read.
Getting the Codebase Agent-Ready
This is engineering work, and the tests come first. Until an agent's output can be graded, there’s no safe way to accept it. Building this initial suite of characterization tests becomes the first supervised agent work the team does. We build characterization tests around the modules the first stream will change. These tests capture how the code behaves today, bugs included. Because that includes existing bugs, we have to distinguish between assertions that represent the specification and behavior we intend to change later.
A suite that passes the test is not yet a safety net. Before a module is handed to an agent, we check the safety net by breaking the code on purpose. We mutate the behavior the tests are supposed to protect and confirm that the suite goes red. Modules that remain green aren’t ready yet, whatever the coverage number says. Next comes the context work. Conventions are written down as rules under .cursor/rules and scoped by file pattern. That means the rules applied in the payments module, for example, reflect the payments team’s conventions. But rules are not a compiler: only the always-apply set is guaranteed in front of the agent on every request. We deliberately keep that set small, promoting as team rules the standards that must hold everywhere, and turning any convention that’s really a procedure into a skill.
The two ignore files do different jobs. .cursorindexingignore keeps vendored libraries, generated clients and checked-in build output out of the index, so that a codebase search returns code that’s still actively maintained. .cursorignore is reserved for what an agent must never read at all: secrets, key material, and files carrying real customer data. Where the repository structure gets in the way of useful context, we reshape it. We also bring documentation back to something an agent can consume. Readiness is scoped to the modules the first stream will touch; the rest of the codebase gets its turn when a stream reaches it.
Every item on that list is a modernization deliverable. If the AI initiative were cancelled the day this phase ended, the codebase would still be better than it was before.
Proving the Approach With Cursor
The eight-week pilot focuses on a single modernization stream. Forward-deployed Exadel engineers work directly within the client team, helping its engineers build their own Cursor capabilities as they work together. Cursor takes on much of the repetitive work, but it’s worth being precise about where that works best. AI-assisted code refactoring, dependency and framework upgrades, test generation, dead code removal and documentation can all scale well when each change is small, local and easy to verify. Decomposing a monolith is a different proposition. Once an engineer has identified where to separate one part of the system from another, an agent can execute that seam well. It can also surface callers that show why a proposed seam won't work. But it can't decide where a boundary belongs in a system whose real boundaries were never documented. Ultimately, design decisions and the call on what merges stay with the engineers.
At that volume, running every change manually doesn’t scale. Well-specified changes run through Cursor CLI from scripts and CI, allowing the same migration to run consistently across a hundred packages rather than being executed manually a hundred times. If some changes need a full environment, they run in parallel as cloud agents in isolated VMs—each opening its own pull request. Sometimes the work depends on facts that aren’t in the repository. The agent reaches them through MCP: the ticket system for acceptance criteria and the schema for the tables a module actually touches. The engineers write the prompt and acceptance check once, then focus their attention on review. This is Cursor as a platform for software delivery rather than an editor. The same agent works in the IDE, from the command line in CI, and in the cloud, all under the same team-level controls.
Be prepared for the bottleneck to move. Once generation is cheap, review becomes the next constraint. Then two common problems no one budgets for on old systems cap everything downstream: a pipeline too slow for a tight agent loop, and a test suite flaky enough that a red build tells you nothing. Either both get fixed early, or they set the ceiling for the rest of the engagement.
Knowing Where Not to Use an Agent
Some work isn’t ready for an agent yet. That includes modules where behavior is undocumented and untested, and the person who wrote it is no longer around. It also includes changes where the hard part is making a decision rather than executing a transformation, as well as code paths affected by an open incident. During the pilot’s first week, we draw that line together with the client’s engineers. As new tests are added and more of the codebase becomes agent-ready, the line can move.
Scaling from Pilot to Enterprise
Once the pilot has proved the loop on one modernization stream, we roll it out in waves of about five teams. We use a train-the-trainer model, with three to five senior developers from each unit learning the practices established during the pilot. They then onboard 30 or more engineers each, covering rules authoring, prompt and review habits, and the module readiness checklist.
We track progress against a five-level maturity model, from licenses purchased and individual adoption to team standards, enterprise governance, and AI-native engineering. This gives leadership a clear view of where each team stands and what it needs to do to reach the next level.
Measuring Impact Every Step of the Way
We combine the client’s delivery data with Cursor’s analytics through a telemetry pipeline. The key measure is the AI share of committed code, which we track against the delivery baseline established during the assessment. We build separate dashboards for engineering, finance, and leadership because each audience asks different questions of the same rollout. At release, we can compare delivery performance against the original baseline, allocate costs by team and repository, and see the modernized system running in production.
What You Take with You, and Where to Start
The modernized system is just the visible outcome. The more lasting one is the capability built around it: rules files versioned in the repository, tests where there were none, documentation that matches reality, review standards for AI-assisted work, and trainers inside the organization who carry the practice forward. The first stream modernizes the system, but it also puts the organization in a much stronger position to tackle the next one. The second modernization stream starts with an agent-ready codebase and a trained team. This is a very different starting point from the first.
You already know which system it is. We start with one system and an assessment: how far the codebase is from being agent-ready, where delivery performance stands today, and which modernization stream should become the pilot. On a first call we can also walk through client references under NDA and share anonymized outcomes in writing.
Your AI Partner
Let’s scope the first modernization stream
About Exadel
Exadel is a global, AI-first software engineering and consulting company that helps enterprises modernize their applications, data, and digital platforms. More than 2,000 engineers, architects and consultants across 30+ delivery centers, over 20 years of enterprise delivery, and a 9 out of 10 client satisfaction score. Exadel pairs forward-deployed engineering teams with deep AI expertise to help clients build and ship AI-native software.
About Cursor
Cursor is an AI coding platform helping developers and engineering teams build software with AI. Cursor's product is designed for complex codebases, supports frontier models from leading providers, and gives teams tools to configure model access, MCP controls, and system-level agent rules. Learn more at cursor.com.
.png)
.png)
