Skip to main content
project@netbasejsc.com
Mon–Sat: 9:00–18:15, Sun: closed
91 Nguyen Chi Thanh, Hanoi
Facebook X (Twitter) LinkedIn YouTube

What are you looking for?

Explore our services and discover how we can help you achieve your goals

Client Workspace Submit a project

Legacy modernization with AI coding agents: what speeds up and what stays human

AI coding agents speed up the parts of a legacy modernization that can be checked by running tests: reading old code, drafting characterization tests and converting one module at a time. They do not choose the route, decide what an old business rule means or declare a slice ready for production. Named engineers and the business owner keep those calls.

Submit a project See the modernization service

Reviewed by Huy Nguyen (David), CEO · Updated 13 Nov 2026 · 10 min read

star

This guide is for CTOs and founders who want a legacy system modernized faster and want to know where the time saving is real. OutsourcingVN is operated by Netbase JSC, which sells modernization work and uses AI-assisted engineering in it, so read it as a supplier's view. It sits under the legacy system modernization guide, which sets out the whole decision, and the commercial route is legacy application modernization.

Contents

What does an AI coding agent actually do in a modernization?

A coding agent is a model that reads a codebase, proposes changes, runs commands and tests, and revises its own output in a loop. Anthropic's engineering guide on building agents explains why code suits this: code solutions are verifiable through automated tests, and agents can iterate on solutions using test results as feedback. The same guide adds the limit that matters most to a buyer: automated testing helps verify functionality, but human review remains crucial for ensuring solutions align with broader system requirements.

Legacy code is exactly where that loop is weakest at the start. An old system often has few tests, so an agent has nothing to iterate against. The first job is therefore not conversion but building the feedback loop: tests that pin what the system does today, right or wrong. Once those exist, the agent's speed becomes usable, because every change it proposes can be run against the recorded behaviour.

Large engineering organisations report the same pattern. Google's paper "How is Google using AI for internal code migrations?" is an experience report rather than a research study, in its authors' own words, and it reports evidence that LLMs can reduce the time needed for migrations significantly. It describes Google's internal tooling, so treat it as direction, not a forecast for your system.

Where do agents help, and where does human review stay?

The table splits a modernization into its recurring tasks. The middle column is the draft an agent can produce; the last column is the decision a person keeps.

Task What the agent drafts What a person decides
Reading undocumented code Module summaries, call graphs, candidate rules Whether the summary matches real behaviour
Characterization tests Tests that record current outputs Which recorded outputs are bugs, not rules
Mechanical conversion Framework, language or API changes per module Whether the module is accepted
Dependency upgrades Version bumps and the code they break Which upgrade risks are acceptable
Data mapping Draft mapping rules and migration scripts What each field means to the business
Documentation Runbooks and rule descriptions from code Who owns each rule afterwards
Route choice A comparison of options from the evidence Rebuild, refactor, wrap or leave alone
Cutover A checklist and rollback script Go or no-go, on parity evidence

The pattern is consistent: agents compress the reading and typing, and people keep every judgement about meaning, risk and timing. A supplier who reverses any row, for example letting an agent's test results stand as acceptance evidence on their own, is moving risk onto you.

How does a modernization slice run with an agent in the loop?

The method below assumes the incremental approach described in incremental modernization without a rewrite: a seam in front of the old system and one capability moved at a time. Martin Fowler's strangler fig description puts it as small additions built on top of, yet separate to, the legacy code base, while behaviour moves across in pieces.

  1. Pin current behaviour

    The agent drafts characterization tests from code and recorded traffic; an engineer reviews which outputs are intended rules and which are known defects.

  2. Set the sandbox and permissions

    The agent works on a copy of the code and masked data, with no production credentials. Anthropic recommends extensive testing in sandboxed environments, along with the appropriate guardrails.

  3. Convert one module

    The agent rewrites or upgrades a single module behind the seam and iterates until the pinned tests pass.

  4. Review every change

    An engineer reads the diff, not only the test result, and rejects changes that pass tests by accident or touch code outside the slice.

  5. Compare on real inputs

    Old and new paths run on the same inputs, and every difference is classified as intended or a defect by a named owner.

  6. Route, watch, retire

    Traffic moves to the new path with a rollback route, and the old code is removed only after the agreed watch period.

Steps 1, 3 and 6 are where agents save the most time. Steps 2, 4 and 5 are where they add the most risk if skipped, and the AI-assisted code migration risks guide sets out each failure and the control that contains it.

Diagram of a modernization slice with an agent in the loop: pin current behaviour, set the sandbox, convert one module and review every change, then compare real inputs before traffic moves with a rollback route
Diagram of a modernization slice with an agent in the loop

What changes for cost and delivery speed?

For a buyer comparing proposals, the useful question is which estimate lines an agent shortens. Reading and summarising an unfamiliar codebase, drafting tests and repeating the same conversion across many similar modules are the lines most affected. A legacy system risk assessment that once needed long code-reading sessions can reach its first findings sooner.

Other lines do not move much. Interviews with the people who still understand the system, data decisions, parity sign-off, user acceptance and the cutover window run on human and business time. A wide integration surface still needs every caller found and tested. So a proposal that shrinks every line by the same factor deserves a question: which work did the agent actually do, and who reviewed it?

Speed also changes shape. Because a converted module can be tested within days, a slice-by-slice plan gives earlier evidence, which makes stopping or re-scoping cheaper. That matters more to a founder than a headline date, because a failed slice is visible before the next one is funded.

Which questions should you ask a supplier before agents touch your codebase?

  • Which tasks in our project will an agent do, and which will an engineer do without one?
  • Where do the agents run, what can they access, and who holds the credentials?
  • How are characterization tests reviewed before they become the reference?
  • Who reads each agent-written change, and what evidence of that review do we receive?
  • How are invented or unknown dependencies caught before they enter the build?
  • If we restrict AI tool use on part of the code, how is that written into the project?

The AI-assisted software delivery guide covers the general controls on any AI-assisted project; this list adds the ones specific to old code. If you are still deciding whether to rebuild at all, start with replace or refactor legacy software, which now covers how agents change that decision.

Worked scenario: an unsupported PHP order system

This example is illustrative and describes no client. A distributor runs an order system on a PHP framework that no longer receives security updates. Two people understand it, and there are almost no tests.

The first two weeks go to reading and pinning. An agent summarises each module and drafts characterization tests from a month of recorded requests; the two internal experts review the summaries, and three outputs the tests recorded turn out to be long-standing bugs that the business wants kept for now. The first slice is the read-only order lookup, moved behind a routing layer. The agent converts it module by module against the pinned tests, an engineer reviews each diff, and the old and new paths run side by side on real requests until the differences are explained. The legacy PHP to Laravel migration guide describes that destination in detail, and data that changes shape on the way goes through legacy data migration planning.

How does Netbase run AI-assisted modernization?

Netbase delivers remote-first from Hanoi in Agile increments with weekly reviews, using AI-assisted engineering under human review. The task table above is the split a buyer can ask any supplier to write into the project plan.

Netbase's delivery lifecycle: discovery and strategic alignment; team assembly and architecture planning; agile execution with outcome-based milestones; modular components; training and rollout; ongoing support. A paid technical audit sprint can cover the discovery step on its own when the route is still open.

The published record closest to this work is a platform migration. For Netztech, Netbase delivered a Magento 1 to Magento 2 Commerce migration in 35 working days, including migrating 11 extensions with installation, configuration, customization and data transfer.

The Netztech migration record sets out that scope.

How this guide is sourced

The agent definition, the test-feedback loop, the human review point and the sandbox advice come from Anthropic's "Building effective agents". The migration time observation comes from Google's experience report on arXiv, and the incremental pattern from Martin Fowler's Strangler Fig article. 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

Submit a project See the modernization service

Common questions

No. It can draft much of the reading, testing and conversion, but deciding what old behaviour means, accepting a slice and choosing the cutover date need people who own the outcome.

Not by itself. Agents make writing code faster, but a rewrite still has to rediscover every undocumented rule, and that discovery runs on people and evidence.

They should not need to. A sound setup gives agents a code copy and masked or synthetic data, and keeps production credentials with named engineers.

Ask for the review record with each increment: the change, the test run, the reviewer's name and any change rejected. A review you cannot see is one you cannot rely on.

Code access, whatever tests exist, a list of the systems that call the old one and the names of the people who still understand it.

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.

Bring the system, the tests you have and the access you can grant

Describe the system, how often it changes, what tests exist and what the business can absorb during the work. OutsourcingVN is Netbase's own outsourcing-services platform. Submit a project with that, and a person will reply with the questions that decide where agents can safely shorten the plan.

Legacy application modernization, one bounded capability at a time 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
line

Sources

91 Nguyen Chi Thanh, Hanoi

+84 937 869 689

Tell us what you want to build or automate.

Submit a project