Here is an AI code migration story that should worry you more than any security breach headline.
The new system compiles. Every test passes. The demo goes beautifully. Three weeks after go-live, finance notices that refunds on part-cancelled bookings are being rounded differently than they were for the last fifteen years. Nobody changed that rule on purpose. Nobody even knew it existed. It lived inside a tangle of old code, and the migration quietly dropped it.
When CTOs talk to us about AI-led legacy modernisation, this is the fear they raise most. It is rarely “will the AI write bad syntax?” It is “will it silently break business logic that lives in undocumented code and hidden dependencies?” The security questions that follow, such as leaked source code, vulnerable output and an agent doing things nobody approved, are all real. But they sit on top of that first worry.
This post is about how we answer both. Our short version: AI can write most of a migration, but only inside a system of boundaries, checks and human accountability that someone designs and owns.
Manual vs AI code migration: an honest comparison
Before getting into controls, it helps to be fair about what each approach is good and bad at. AI-led migration is not simply a faster version of manual migration. It trades one set of risks for another.
| Aspect | Manual migration | AI-led migration (with guardrails) |
|---|---|---|
| Speed and scale | Pace is limited by team size. Repetitive changes are repeated by hand across hundreds of files. | Agents apply the same migration pattern across many files quickly, so engineers spend their time on judgement rather than repetition. |
| Consistency | Style and approach drift between engineers and over the length of the project. | The same standards are applied everywhere, provided they are enforced in tooling and permissions rather than left to prompts. |
| Hidden business logic | Engineers learn the rules gradually by reading code and asking colleagues. Knowledge can leave with the people who hold it. | The AI cannot infer undocumented rules reliably. It needs a written specification, context files and characterisation tests to work from. |
| Typical failure mode | Fatigue, copy-and-paste slips and missed edge cases. | Confident, plausible code that quietly changes behaviour or carries an old vulnerability into the new system. |
| Security exposure | Human error: secrets on laptops, over-permissioned accounts, unreviewed shortcuts. | A new surface: source code sent to models, prompt injection and agents with tool access. Sandboxing, vaulted secrets and private model hosting address it. |
| Verification | Depends on reviewer time and attention, which thins out on very large changes. | Automated gates (tests, static analysis) plus risk-tiered review of the actual diff. More code is produced, so the gates matter more. |
| Documentation and traceability | Often written afterwards, if at all. | Specifications and context files are produced along the way, and every AI action can be logged and audited. |
| Accountability | Engineers own the code they write. | The same. Engineers own every line that ships, whoever or whatever drafted it. |
| Best suited to | Small, highly sensitive or one-off changes that need deep human judgement. | Large, pattern-based migrations that have a clear specification and good test coverage. |
The honest takeaway is that neither approach wins alone. Manual work brings judgement and context. AI brings scale and consistency. The guardrails in the rest of this post are what let you combine the two without inheriting the worst of both.
Why agentic AI changes the threat model for code migration
A chatbot answers questions. An agent acts. It reads whole repositories, executes code, installs packages and calls tools. That is exactly what makes it useful for migrations, and exactly why it needs containment. The risks worth planning for are specific:
- Source code and secrets travelling to places they should not, because legacy repos are full of old credentials, test data and internal hostnames.
- Old vulnerabilities getting a fresh home, translated faithfully into modern syntax.
- Hidden instructions buried in comments, documents or dependencies that try to redirect the agent. This is called prompt injection, and an agent that reads an entire legacy codebase has a lot of surface to be exposed to.
- Unapproved actions, from installing a package nobody vetted to touching a system it was never meant to reach.
- Silent behaviour change, the refund-rounding problem above, which no scanner will catch because nothing looks wrong.
We build around four principles. None of them depends on the AI being perfect.
Principle 1: Specify before you generate
Agents do well inside clear boundaries and badly with ambiguity. So on a migration, the first deliverable is not code. It is an implementation-ready specification.
Take a legacy Perl system in the UK travel sector. Its business rules live in the code itself and are duplicated across the booking and accounting layers. An AI migrating that blind would either reproduce the inconsistencies or break them in new and creative ways. Our approach there is to start with a discovery phase whose output is a specification, and to send the client a short “current architecture: our understanding” document to correct before scope is fixed. If the client’s own engineers spot something we misread, we want to hear it before a single line is generated.
Then comes the most useful safety net in the whole process: characterisation tests. These are tests that capture how the current system actually behaves, warts included, before anyone touches it. After migration, they let the AI prove that the new code behaves like the old. They are the bridge between “hidden business logic” and “AI-safe migration”.
Principle 2: Contain the agent with sandboxing
The agent works in a box, and the box has no keys to anything that matters.
• A dedicated, isolated cloud VM hosts the autonomous coding agents. It is reachable only over a private network, with no public exposure, OAuth on every agent endpoint and automatic shutdown outside working hours.
• No live or production credentials on development machines. Secrets live in a managed vault (Azure Key Vault) and never in .env files in the repository.
• The coding agent’s own sandbox mode is switched on. That means OS-level isolation (Bubblewrap on Linux, Seatbelt on macOS) plus network egress controls that block arbitrary sites.
The point of all three is the same. If a hidden instruction in some forgotten comment tells the agent to send data somewhere, there is nowhere for it to go and nothing valuable to send.
This is not theory for us. Our whole engineering team uses Claude Code for all development, so these controls are daily habits rather than slideware.
Principle 3: Risk-tier your AI code review
Treating every file as equally dangerous wastes effort. Treating them all as harmless is worse. So we classify code paths by risk and match the model and the review to the stakes.
| Risk tier | Typical paths | How AI is used |
|---|---|---|
| Lower | UI, reporting, data ingestion, configuration | A faster model for implementation and review |
| Higher | Money calculations, identity and access, data contracts, infrastructure, CI/CD pipelines | The strongest model for both implementation and review |
Two details make this work. First, the reviewer is chosen from the actual diff, not the plan. A story labelled low-risk that ends up touching a sensitive file is escalated automatically. Second, before we trust the cheaper tier, a sample of its reviews is re-audited by the stronger model, to confirm nothing is slipping through.
Principle 4: Done means verified, with CI/CD security checks
Work is only accepted when automated tests pass and a reviewer, human or a stronger review model, has checked the actual diff. In practice that looks like this:
• A phased workflow (create, implement, gates, repair, review, integrate) based on the BMAD method, so every story passes the same checkpoints.
• Tests written alongside the code. A story counts as delivered only when its tests pass.
• Static analysis in CI, using tools like Semgrep, tuned for vulnerability patterns common in AI-generated code.
• A dedicated review agent for modules that handle sensitive data, such as the personal data of students on an education platform.
• Rules enforced in tooling, not in prompts. What the AI may touch and what needs approval are hard limits in permissions. A prompt is guidance. A permission is a control.
And one human rule sits above all the automation: never commit code you can’t explain. AI writes the first draft. Engineers own every line that ships.
Where the model runs: Microsoft Foundry, self-hosted or public AI
There is a spectrum, and the right point on it depends on how sensitive your data is and what regulation applies.
- A public AI service. Fastest to start, with the least control over where prompts and code go.
- Models hosted in your own Azure environment on Microsoft Foundry (formerly Azure AI Foundry). This is the option most enterprise clients choose. We do not build security from scratch around the AI. We place it inside the client’s existing Azure security boundary and inherit what Microsoft has invested in identity, networking, compliance and threat protection.
- Fully self-hosted and air-gapped. Open-weight models running on client-owned hardware, with no data leaving the premises. This is the strongest form of sandboxing. We have delivered offline, on-premises systems before, including one used at Olympic-level events, so we know what working without the internet involves.
Here is what the middle option typically gives a client:
| Control | What it gives you |
|---|---|
| Network isolation | Private networking, private endpoints and egress controls, so model and agent traffic does not cross the public internet. The AI lives inside the same fence as the code and data it works on. |
| Identity and least privilege | Role-based access through Microsoft Entra ID and managed identities instead of shared keys, so no API keys float around repositories or laptops. |
| Data protection | Prompts and outputs stay in your tenant and are not used to train the underlying models. Regional deployment helps with data residency. The source code being migrated never becomes someone else's training data. |
| Policy and governance | Azure Policy controls which model providers can be deployed and which tools agents may connect to, so guardrails are set centrally rather than left to each developer. |
| Runtime guardrails | Content filtering and prompt-injection protections on model inputs and outputs, as a second line of defence against instructions hidden in legacy code or documents. |
| Monitoring and threat protection | Tracing into central observability and Microsoft Defender for Cloud coverage, so AI activity is watched by the same security tooling as the rest of the estate. |
For security-sensitive clients we also design a hybrid approach: a self-hosted local model handles everyday queries, and only complex work escalates to a Foundry-hosted model inside an isolated Azure environment.
One honest caveat. Regulated targets such as Azure Government and GCC High do not always offer the same models and features as commercial Azure. We check current Microsoft documentation before designing around any specific capability, and you should insist that your partner does too. It matters more as the compliance bar rises: we are currently working on moving a US additive-manufacturing company’s manufacturing execution system to Azure Government and GCC High, with ITAR and SOC 2 readiness in scope, and there the AI workflow, the environments and the handover all have to meet the same standard as the destination.
AI guardrails for when agents get near production
Most migration work happens far from live systems, which is the point of the sandbox. But cutover, validation and day-two operations sometimes put AI assistants within reach of real data and real admin functions. When that happens, our approach is to treat the AI like a new, very fast, slightly over-eager colleague and give it exactly this much trust:
| Guardrail | What it does |
|---|---|
| Scoped, expiring tokens | Created behind two-factor authentication, with read and write permissions per area, re-checked live, with expiry and instant revocation. |
| A permanent block-list | Operations the AI can never perform, whatever its token allows. |
| Human confirmation | Changes need a person's approval, with protection against duplicate requests. |
| Sensitive-field stripping | The most sensitive fields never reach the AI at all. |
| Short-lived, logged links | Document downloads expire quickly and every access is recorded. |
| Rate limits and anomaly alerts | Stricter limits for AI connections, per-token limits, and alerts on unusual activity. |
| Audit attribution | An AI-activity filter in the audit log, so every AI action is traceable. |
| A curated tool surface | Through MCP, only about 30 safe operations are exposed. The connector holds no privileges of its own and acts only with the user's token. |
| Prompt-injection testing | Injection scenarios and permission-escalation tests run before go-live. |
None of this assumes the AI will behave. It assumes the AI will occasionally be confused or manipulated and makes sure that does not matter much.
Seven questions to ask before an AI code migration starts
Treat these as a pre-flight check. For each question, here is why it matters and what a good answer looks like.
- Have the business rules been written down and confirmed with the people who know the old system, before any code is generated? Agents work well inside clear boundaries and badly with ambiguity, and undocumented rules are the ones most likely to be dropped. A good answer is an implementation-ready specification that the client has read and corrected, plus a short “current architecture: our understanding” document confirming what the migration team believes the system does.
- Do characterisation tests capture today’s behaviour, so the new code can be proven equivalent? Passing tests written for the new system only prove the new system agrees with itself. A good answer is a set of tests recorded against the legacy system, including the awkward cases such as rounding, proration and tax, so that any difference shows up as a failing test and a conversation rather than a surprise in production.
- Does the agent run in an isolated environment with no production credentials and no open internet? If a hidden instruction in some old comment tells the agent to send data somewhere, the sandbox should leave it nowhere to go. A good answer is a dedicated cloud VM on a private network with no public exposure, OAuth on every agent endpoint, automatic shutdown outside working hours, and the agent’s own sandbox mode switched on with network egress controls.
- Do secrets live in a vault rather than in the repository? Legacy repositories often hide old credentials, and anything in the repository can be read by the agent and end up in a prompt. A good answer is secrets held in a managed vault such as Azure Key Vault, none in
.envfiles, and no live or production credentials on development machines. - Are the riskiest code paths reviewed more strictly than the rest, based on what actually changed? Not all code carries the same risk. Money calculations, identity and access, data contracts, infrastructure and CI/CD pipelines deserve the strongest model and the closest review. A good answer is a reviewer chosen from the actual diff rather than the plan, automatic escalation when a low-risk change touches a sensitive file, and a sample of the cheaper tier’s reviews re-audited by the stronger one.
- Do you know exactly where the model runs and whether your code can be used for training? A public AI service, a model hosted in your own Azure tenant on Microsoft Foundry and a fully self-hosted model give you very different levels of control. A good answer is a written statement of where prompts and outputs go, how long they are kept and whether they are used for training. If your target is a regulated cloud such as Azure Government, it also includes a check that the models and features you need are available there.
- Can a named engineer explain every line that ships? AI writes the first draft, but accountability cannot be delegated to it. A good answer is a team rule that nobody commits code they cannot explain, a reviewer, human or a stronger review model, who has checked the actual diff, and automated tests that pass before anything is accepted as done.
A “no” or “not sure” is not a failure. It is simply where to start.
One last thought
Security in an AI-led migration is a process, not a prompt. That is why we run our own AI workflow inside an ISO 27001-certified management system, and why we treat migration and modernisation as core work as a Microsoft Solutions Partner for App Modernization rather than a side experiment.
The interesting part is how unglamorous the answer turns out to be. Write the spec first. Build the box. Match the scrutiny to the risk. Verify everything. Keep a human accountable. If you are weighing a migration and want to talk through where to begin, a discovery conversation is a good place to start, and our application modernization page has more on how we work.
FAQ's
1. Is it safe to let AI write an enterprise code migration? It can be, when the AI works inside a system someone designs and owns: a written specification, an isolated environment, risk-based review, automated gates and engineers who are accountable for every line that ships. Safety comes from that system, not from trusting the model.
2. What is the biggest risk in an AI-led migration? In our experience it is not bad syntax. It is silently broken business logic that lives in undocumented code and hidden dependencies. That is why we start with a specification and characterisation tests rather than code.
3. What are characterisation tests? Tests that capture how the current system actually behaves, before anything is migrated. After the migration, they let the AI prove that the new code behaves like the old, including the quirks nobody remembered.
4. How do you stop an AI agent from leaking code or secrets? The agent runs on an isolated cloud VM reachable only over a private network, with no production credentials on development machines. Secrets live in a managed vault such as Azure Key Vault, and the agent’s own sandbox mode blocks arbitrary network access. Where the model itself runs matters too, which is covered above.
5. What is prompt injection, and why does it matter for migrations? It is when hidden instructions in content the AI reads, such as a code comment or a document, try to redirect its behaviour. A migration agent reads an entire legacy codebase, so it has plenty of exposure. Containment, hard permission limits, runtime protections and injection testing before go-live all reduce the risk.
6. Will our source code be used to train AI models? That depends on where the model runs. When models are hosted in your own Azure environment on Microsoft Foundry, prompts and outputs stay in your tenant and are not used to train the underlying models. With a fully self-hosted setup, nothing leaves your premises at all.
7. Does all code get the same level of review? No. Lower-risk paths such as UI, reporting and configuration use a faster model. Higher-risk paths such as money calculations, identity and access, data contracts, infrastructure and CI/CD pipelines use the strongest model for both implementation and review. The reviewer is chosen from the actual diff, so a change that turns out to be sensitive is escalated automatically.
8. Can AI-assisted migration work in a fully offline or air-gapped environment? Yes. Our approach for clients whose systems never touch the internet is a self-hosted stack of open-weight models running on client-owned hardware. We also design hybrid setups, where a local model handles everyday queries and only complex work escalates to an isolated Azure environment.
9. Does AI replace human code review? No. Work is accepted only when automated tests pass and a reviewer, human or a stronger review model, has checked the actual diff. Our team rule is that nobody commits code they cannot explain.
10. Does this approach apply to government or regulated clouds? The principles do, and the AI workflow, environments and handover need to meet the same compliance bar as the destination. Model and feature availability can differ in clouds such as Azure Government and GCC High, so we check current Microsoft documentation before designing around any specific capability.
