Letting AI agents do the boring parts of a service migration

Most of a service migration isn’t hard. It’s long. You inventory what the old service does, map each piece to the new platform, rewrite the call sites, update configuration and tests, and repeat that across dozens of endpoints. The hard parts, the undocumented behaviour and the trade-offs, are a small fraction of the work, buried under a lot of repetition.

At Siemens I’ve been architecting migrations around agentic workflows, where AI agents analyse services, plan the migration steps and carry out the repetitive refactoring. This post is about how I split that work between agents and people, and the guardrails that make it safe.

Three jobs, three agents

Asking one agent to “migrate this service” gives you a large, unreviewable change. Splitting the work into separate jobs, each with its own output, works much better.

The analyst reads the service and produces an inventory: endpoints, their inputs and outputs, dependencies on other services, data stores, configuration, background jobs. It doesn’t change anything. Its output is a structured document that a person can check against what they know.

The planner turns the inventory into an ordered list of small steps. Each step says what changes, which files it touches, and how to verify it: which tests must pass, which behaviour must stay the same.

The executor takes one step at a time. It makes the change on a branch, runs the checks, and opens a pull request. Then it stops.

People review the inventory, approve the plan, and review every pull request. The agents do the reading and typing; people do the deciding.

Structured output between stages

The inventory and the plan should be data, not prose. A JSON document with a fixed schema can be validated, diffed when the agent reruns, and fed to the next stage without anything getting lost in paraphrase. When the planner refers to an endpoint, it refers to an entry in the inventory, not to its own description of one.

This also makes review faster. Checking forty inventory entries in a table is easier than reading four pages of an agent’s summary.

Guardrails

Tests are the contract. An agent can’t preserve behaviour nobody has written down. If the old service lacks tests, the first steps of the plan are characterisation tests that capture what it does today, including the odd parts. Every later step has to keep them green.

Small diffs. If a pull request takes longer to review than it would have taken to write by hand, the step was too big. Small steps also make failures cheap: you throw away one branch, not a week of work.

Use deterministic tools for deterministic work. Renaming a package or updating an import path across a codebase is a job for a codemod, a compiler or a formatter, not for a model retyping files. The agent’s job is to decide which tool to run and check the result. That keeps changes reproducible and avoids the subtle typos that come from regenerating code.

Limited permissions. Agents work in a sandbox with access to the repository and the test runner. They can open pull requests. They can’t merge, deploy or touch production.

Log everything. Every tool call and every decision goes into a log you can read afterwards. When a step goes wrong, the log tells you whether the plan was wrong or the execution was.

What stays with people

Agents are good at reading a lot of code quickly and at making the same kind of change many times. They are not good at knowing what isn’t in the code:

• behaviour that clients depend on but nobody documented,
• operational context, like which endpoint gets hammered at the end of every month,
• trade-offs between doing it properly and doing it now,
• who owns what, and who needs to be told.

Those questions come up during inventory review and planning, which is exactly why people sign off on both before any code changes.

Is it working?

Two measures tell you a lot. The first is how many agent pull requests merge without changes; if reviewers keep rewriting them, the steps are too vague or the checks too weak. The second is review time per pull request; if it creeps up, the steps are getting too big.

The tooling matters less than the boundaries. Frameworks like Google’s Agent Development Kit make it easy to wire agents and tools together, and protocols like MCP give agents typed access to the systems around them. But what makes the workflow trustworthy is the shape of the work: structured hand-offs, small verified steps, and a person approving every change that ships.

Used that way, agents don’t replace the engineers on a migration. They take away the part of the job that nobody wanted, and leave the part that needed an engineer in the first place.