AI-assisted code migration risks, and the controls that contain them
The main risks of an AI-assisted code migration are silent behaviour changes that pass review, tests written by the same agent that share its blind spots, data that converts without errors but changes meaning, and security gaps such as invented dependencies. Each one has a control, and each control leaves evidence a buyer can ask to see.
Submit a project See the modernization serviceReviewed by Huy Nguyen (David), CEO · Updated 13 Nov 2026 · 9 min read
This guide is for CTOs and founders whose supplier, or own team, plans to use AI coding agents on a migration. OutsourcingVN is operated by Netbase JSC, which uses AI-assisted engineering in modernization work, so it is written by a supplier with that interest. It is a spoke of legacy modernization with AI coding agents, which explains where agents help, and of the legacy system modernization guide.
Contents
- Why does an AI-assisted migration fail differently?
- Which risks matter, and which control contains each?
- What is a silent behaviour change, and how is it caught?
- Why can agent-written tests miss the gap?
- How does data go wrong in a converted system?
- Which security risks does generated code add?
- How do you run the controls in each migration slice?
- Worked scenario: a billing module converted by an agent
- How does Netbase contain these risks in delivery?
- How this guide is sourced
- Common questions
- Ask for the controls before the first slice
Why does an AI-assisted migration fail differently?
A migration done by hand fails in familiar ways: a missed module, a typo, a deadline. An AI-assisted migration produces far more change per day, and that change reads well. Code that compiles, follows the project's style and passes its tests is easy to approve, which is exactly why a wrong change can travel a long way before anyone notices.
Three conditions make this worse on legacy systems. The old code rarely has a full test suite, so "the tests pass" covers less than it sounds. The people who understand the rules are few and busy, so review time is scarce. And the volume of agent output can turn careful review into skimming. The controls below are designed for those three conditions, not for agents in general.
Which risks matter, and which control contains each?
| Risk | Warning sign | Control | Evidence to ask for |
|---|---|---|---|
| Silent behaviour change | Rounding, dates or defaults differ on rare inputs | Characterization tests plus side-by-side runs | Difference log with a named classifier |
| Agent-written test gaps | Tests and code changed in the same commit | Tests reviewed and frozen before conversion | Test review record per slice |
| Data drift | Row counts match but meanings differ | Row-level validation and business reconciliation | Reconciliation report signed by the data owner |
| Invented or unsafe dependencies | Unfamiliar package names in the build | Allow-listed registries and dependency review | Dependency diff per release |
| Scope creep from agent proposals | Refactors outside the agreed slice | Change control on every out-of-slice edit | Change log entries with approvers |
Each row maps to one of the chapters below. The last row is shorter because the control already exists in any well-run project; the agent only makes it busier.
(opens the full-size diagram in a new tab)
What is a silent behaviour change, and how is it caught?
A silent behaviour change is a converted module that does something slightly different from the old one without raising an error. Typical cases are integer and decimal handling, time zones, null and empty-string defaults, sort order and character encoding. An agent converting code idiomatically for the new framework will often "fix" these, and the fix is a change the business never agreed.
The control is to record behaviour before changing anything. Characterization tests capture what the old code returns on real and edge inputs, including outputs that look wrong. Then old and new paths run on the same inputs, as incremental modernization without a rewrite describes, and every difference is classified by a named person as intended or a defect. The evidence is the difference log, not the green test run.
Why can agent-written tests miss the gap?
When the same agent writes the code and its tests, both can share one misunderstanding. A test that asserts the new behaviour proves only that the code does what the agent intended. Anthropic's engineering guide notes that automated testing helps verify functionality, while human review remains crucial for ensuring solutions align with broader system requirements.
The control is ordering. Tests are drafted, reviewed by someone who knows the old system, and frozen before conversion starts. A commit that changes a frozen test and the code it covers together is flagged for a second reviewer. Ask for the test review record per slice; a supplier who cannot show it is asking you to trust the agent's own grading.
How does data go wrong in a converted system?
Data errors in a migration rarely crash anything. A converted import treats an empty field as zero, a status code is mapped to the nearest new value, or a character set conversion quietly replaces accented names. Counts match, and the meaning has changed.
The control has two layers. Row-level validation compares source and target records directly: the AWS Database Migration Service documentation describes this kind of check as comparing each row in the source with its corresponding row at the target and reporting any mismatches. Business reconciliation then checks totals, balances and samples that a domain owner recognises. Legacy data migration planning covers profiling, mapping and the reconciliation report in full.
Which security risks does generated code add?
The OWASP GenAI Security Project's LLM09:2025 entry lists unsafe code generation, where a model suggests insecure or non-existent code libraries that can introduce vulnerabilities. It also describes attackers publishing malicious packages under names that coding assistants commonly invent. A migration that adds many dependencies at once is exposed to exactly this.
The controls are ordinary but must be enforced: dependencies come only from allow-listed registries, every new package in a release is reviewed by a person, and agents work in a sandbox without production credentials. OWASP's own mitigations include human oversight with reviewers trained to avoid overreliance on AI-generated content, and secure coding practices. If the migrated system itself contains AI features, testing those is a separate exercise covered by AI assurance and red teaming.
How do you run the controls in each migration slice?
-
Freeze the reference
Characterization tests are reviewed and frozen before any conversion in the slice.
-
Fence the agent
Code copy, masked data, allow-listed registries and no production credentials.
-
Limit the slice
Any edit outside the agreed slice goes through software change control with a named approver.
-
Review diffs and dependencies
An engineer reads each change and each new package, not only the test result.
-
Run side by side
Old and new paths process the same inputs; every difference is logged and classified.
-
Reconcile the data
Row-level validation plus business totals, signed by the data owner.
-
Release with a way back
The rollback route is tested before traffic moves.
Worked scenario: a billing module converted by an agent
This example is illustrative and describes no client. A subscription business converts its billing module from an old framework to a current one, with an agent doing most of the conversion. The pinned tests pass on the first day.
The side-by-side run shows a difference on about one invoice in a few hundred: the old code rounded each line, the new code rounds the total. The agent had followed the new framework's idiom. The difference log sends it to the finance owner, who confirms the old behaviour is the rule, and the change is reverted. In the same slice, the dependency review rejects a package whose name looked plausible but did not exist on the registry the team allows. Neither issue was visible in the test results alone.
How does Netbase contain these risks in delivery?
Netbase delivers remote-first from Hanoi in Agile increments with weekly reviews, using AI-assisted engineering under human review. The weekly review is where a buyer can see the difference logs and review records described above.
Agent sandboxes and credentials sit inside the same engineering controls as the people who run them. Security practices include secure code review and version control, role-based access control, MFA for admin dashboards, contributors under NDA, and NDAs and DPAs on request.
How this guide is sourced
The unsafe code generation risk, the invented package attack and the mitigations come from OWASP LLM09:2025. The row-level validation description comes from the AWS Database Migration Service documentation, and the testing and review point from Anthropic's "Building effective agents". Netbase statements are approved claim-register entries, reviewed as the methodology describes. The table and the scenario are editorial guidance.
Plan the next step for your project
Common questions
It carries different risks. It produces more change faster, so review and comparison controls matter more; with them in place, the risk is visible earlier.
Not on their own. Tests should be reviewed and frozen by someone who knows the old system before the agent converts the code they cover.
Treat every out-of-slice edit as a change request with an approver, and reject commits that mix it into the slice.
The difference log, the test review record, the dependency diff and the data reconciliation report, each with a named person.
Rarely, and only with explicit approval. Masked or synthetic data covers most conversion and testing work.
Talk to Huy Nguyen (David), Founder and CEO of Netbase JSC: message him on WhatsApp at +84 937 869 689 or email project@netbasejsc.com. You can also send your brief through the project request form. Say which workflow or system the project concerns and what has to stay unchanged; the first step is a discovery conversation, and scope and milestones are agreed after it.
Ask for the controls before the first slice
If you are weighing a rebuild against a refactor first, replace or refactor legacy software sets out the routes, and legacy application modernization is the service that runs the chosen one. OutsourcingVN is Netbase's own outsourcing-services platform. Submit a project with the system, the tests you have and the data it holds, and a person will reply with the controls that fit it.
Related services and solutions
Legacy application modernization, one bounded capability at a time
The code is assessed first, then one bounded capability moves at a time, with a way back.
Learn More