Agentic Migration Teardown: How AI Agents Replatform a Monolith

Sprint 14. The user service extraction. Three weeks into a worked example that was supposed to make us look smart.

It didn't.

The Developer agent had just opened PR #247: "Extract UserAuthService from monolith core." Fourteen files changed. Tests green. CI passing. We almost merged it.

Line 312: a SQL query that would have silently dropped the password reset token table on first migration run.

The QA agent didn't catch it. The Developer agent didn't flag it. Automated tests passed because the test database didn't have real tokens in it. A human reviewer caught it during the mandatory PR review — forty minutes of reading a diff line by line.

That's the story of agent-driven migrations in 2026. Agents can execute. They execute fast. They execute confidently. But the confidence is the problem. Every extraction needs a human reviewing every cut, or you ship something that looks right and corrupts production data.

This post walks through what agentic migration looks like when you staff it with AI agents — as an illustrative teardown, not a customer case study. DevOS is pre-launch; we don't have production migrations to show yet. What we have is a worked example of how the agents-as-employees pattern applies to one of the highest-stakes engineering projects a team can take on.

The Setup: A Realistic Legacy Monolith

For this teardown, we modeled a mid-sized B2B SaaS monolith. Not a toy — something resembling what a 30-person engineering team might inherit:

• 450K lines of Python (Django, some FastAPI bolted on later)
• Single PostgreSQL database, 180 tables, foreign keys everywhere
• 12 "domains" tangled together: users, auth, billing, notifications, inventory, orders, shipping, reporting, admin, integrations, search, analytics
• Test coverage at 34%, mostly happy-path
• Deployment: single container on Railway, takes 8 minutes to build and deploy

Classic strangler fig candidate. The kind of codebase where every change touches five files you didn't expect, and the on-call rotation has a wiki page titled "Things That Will Page You At 3am."

Honestly? I hate these codebases. Everyone does. But they're everywhere, and pretending otherwise doesn't help anyone.

We wanted to answer: what happens if you assign agents to the extraction tickets instead of humans?

The Strategy Layer (Humans Only)

First thing we learned: agents can't own migration strategy. They're good at "extract this module." They're terrible at "which module should we extract first."

The sequencing decision requires understanding the business. Which domains have the most active development? Which are most entangled? Where does the team have the most fear and the least test coverage? An agent looking at the codebase sees dependencies. A human looking at the codebase sees the billing module that hasn't been touched in 18 months and the orders module where every sprint has a hotfix.

So the architecture stays human-owned. For our worked example, a human tech lead mapped the extraction order:

1. Notifications — low risk, well-bounded, easy to verify
2. Search — high read volume but mostly stateless, natural service boundary
3. Auth/Users — scary but necessary before anything else can move
4. Billing — scariest of all, saved for last

This is where Michael Feathers' "Working Effectively with Legacy Code" still applies. Identify seams. Write characterization tests. Extract along natural boundaries. The strategy is the same whether humans or agents do the extraction work.

Agents just execute it faster — when they don't drop your password reset table. Which, in our case, was almost.

Sprint Structure: Agent Execution, Human Gates

Each extraction ran as a 2-week sprint. Here's how we structured the agent assignments:

Sprint Planning (1 day, human-led):

• Tech lead breaks the extraction into tickets
• Story points assigned based on agent velocity data (we tracked this from earlier sprints)
• Agents assigned to tickets in Linear
• Human reviewer assigned to every PR

Execution (9 days):

• Developer agent (Python specialist) handles code extraction tickets
• QA agent writes tests for the extracted service — unit, integration, contract
• DevOps agent provisions the new service: Railway config, Postgres schema, env vars
• Second Developer agent handles data migration scripts when needed

Review Gates (continuous):

• Every PR gets human review before merge. No exceptions.
• Architecture review at the start of each extraction
• Canary review before traffic shift

Deployment + Monitoring (2 days):

• Canary deployment to 5% traffic
• Human watches dashboards, decides go/no-go
• Gradual rollout to 100%

The agents proposed at every step. Humans approved at every gate.

The gates weren't optional. We learned that the hard way — tried skipping PR review for "low-risk" tickets in an earlier simulation. The QA agent shipped a test file that imported a production credential from the monolith's env.

We stopped that experiment fast. Felt pretty dumb about trying it in the first place.

What Agents Did Well

Credit where it's due: for the bounded extraction work, agents moved faster than humans would.

Test coverage expansion. The QA agent took tickets like "write characterization tests for NotificationService.send_batch()" and produced 80% coverage in hours. A human would spend a day just reading the code paths. The agent read, generated, iterated on failures, and had a green test suite by end of day.

Infrastructure provisioning. The DevOps agent handled Railway service creation, Postgres provisioning, and GitHub Actions CI setup. For our notifications service extraction, the infra work was done in one afternoon — PR opened, reviewed, merged, deployed.

Boilerplate migrations. Data migration scripts for well-structured tables were straightforward. The Developer agent wrote the migration, QA agent wrote tests for data integrity, DevOps agent ran it in staging. Worked cleanly on 4 out of 5 tables. (The fifth one had a legacy JSON blob column. That one needed a human.)

Dependency untangling. The Developer agent was surprisingly good at tracing imports, identifying coupling, and proposing interface boundaries. It generated a dependency graph for the auth module that matched what a senior engineer would have drawn — and it did it in 3 hours instead of 2 days.

I'll be honest: that one impressed me. I didn't think it would get the graph right.

What Agents Got Wrong

And here's where the worked example got interesting. Agents failed in ways that looked like success.

Silent business logic drift. In the orders extraction, the Developer agent extracted an order validation function that was called from two places in the monolith. It extracted the function correctly. It did not extract the second call site's context — a special case for enterprise customers that lived in an unrelated file. Tests passed. The extracted service worked. Enterprise orders would have failed validation silently in production.

Caught in review? Yes. Would a human have caught it faster? Maybe not — but a human would have known to ask "where else is this called?" before opening the PR. The agent didn't ask.

Over-confident data migrations. The password reset token table incident from the opening. The migration script was syntactically correct. It ran fine on test data. It would have truncated production data because the agent interpreted "clean migration" as "remove old table after copy" rather than "leave old table as backup."

Human caught it. Took 40 minutes of line-by-line review.

Misunderstood boundaries. In the search extraction, the Developer agent proposed an interface that made sense for the current search features. It didn't account for the planned multi-tenant search rollout that wasn't in any ticket — just in a Slack thread the architect had with the CEO. The interface would have required a breaking change three months later.

Architecture review caught it. But it wouldn't have shown up in any automated test.

An agent reading the codebase can't read the Slack thread. And that's the problem with agent-driven anything right now — the context that matters most lives in people's heads and informal channels, not in code. We explored this context problem in depth in our post on designing memory systems for coding agents.

What We'd Change

If we ran this worked example again:

Smaller extraction units. We scoped at the module level (NotificationService, UserAuthService). Too big. The sweet spot for agent-executed extractions is probably the function or small class level, with a human rolling them up into coherent services.

More explicit pre-extraction checklists. The QA agent didn't know to check for business-logic special cases because we didn't give it a prompt that said "identify every conditional that mentions 'enterprise' or 'legacy' or 'special case.'" We'd bake that into the extraction ticket template.

Dedicated review sprints. We underestimated review bandwidth. When agents execute in parallel, they generate PRs faster than humans can review them. Our 2-person human team hit a wall around day 5 of each sprint. Next time, we'd budget 30% of human capacity just for review.

Automated rollback testing. The DevOps agent set up deployments but not rollback procedures. We added that after the notifications extraction, when we realized we didn't have a tested path to revert if the canary failed.

Embarrassing oversight on our part. Should have been in the checklist from day one.

The Math on Agent-Driven Migrations

Here's the honest picture from our worked example:

Agent execution time for the notifications extraction: ~6 days of agent work (Developer + QA + DevOps agents working on their assigned tickets)

Human time: ~4 days (architecture planning, PR review, canary monitoring, stakeholder communication)

Estimated pure-human timeline for the same extraction: 3-4 weeks with a 2-person team

Agents cut execution time significantly. But human time didn't go away — it shifted from writing code to reviewing code and making judgment calls. The ratio changes. The total hours don't drop as much as you'd expect.

That's the honest truth, and I wish more agent-tool vendors would say it out loud. It's why we wrote about why single-agent coding tools plateau past prototype — the coordination overhead doesn't vanish, it shifts.

The review gates are non-negotiable. Every migration that skipped human review in our simulations produced at least one bug that would have corrupted production data. Every single one. We tried. We failed. Don't skip the gates.

How This Maps to DevOS

DevOS is built for exactly this pattern. The four built-in agents — Planner, Developer, QA, DevOps — map to migration work:

• Planner agent helps break epics into extraction tickets (though architecture decisions stay human)
• Developer agent handles code extraction, interface design, refactoring
• QA agent writes characterization tests, integration tests, contract tests
• DevOps agent provisions services, configures CI/CD, manages deployments

The marketplace adds specialized agents as needed — database migration specialists, observability setup, security review.

What DevOS adds to this: the coordination layer. Agents as assignees in Linear-style boards. Velocity tracking across sprints. Mandatory review gates before merge. The management infrastructure that makes "assign a ticket to an agent" as natural as assigning it to a human.

Who Should Consider This Pattern

If you're evaluating agent-driven migrations:

Good fit:

• Mid-sized monoliths (200K-1M lines) with identifiable domain boundaries
• Teams that already use strangler fig or similar incremental approaches
• Organizations with strong code review culture and available reviewer bandwidth
• Codebases with at least some test coverage to validate extractions against

Not a good fit (yet):

• Massive legacy systems with no tests and unclear boundaries
• Regulated industries where every code change needs documented human authorship
• Teams without senior engineers available for review bandwidth
• Monoliths with heavy cross-cutting concerns that resist clean extraction

The agents are good enough to execute well-scoped extraction tickets. They're not good enough to run a migration unsupervised.

That's my strong opinion after running this: if anyone tells you agents can do migrations autonomously in 2026, they're either lying or haven't actually tried it with a real codebase. The gap is review and judgment — and that gap is why the human-in-the-loop gates matter more, not less, when agents are executing. For a look at how QA agents specifically fit into this pattern, see our piece on AI agents for QA teams.

Frequently Asked Questions

Can AI agents actually handle a monolith-to-services migration?

Agents in 2026 can handle well-scoped extraction tickets — extract this module, write tests for that boundary, deploy this service. They struggle with the architectural judgment calls: which domain to extract first, how to handle cross-cutting concerns, when to stop. The pattern that works is human architects setting the strategy and agents executing the tickets with mandatory review gates before every production cut.

How many agents would you assign to a migration like this?

Based on our internal modeling, a typical extraction sprint would use 3-4 specialized agents: a Developer agent for the code extraction, a QA agent for test coverage, a DevOps agent for infrastructure provisioning, and sometimes a second Developer agent for the data migration scripts. Human tech leads still own the architecture decisions and review every PR before merge.

What review gates should exist for agent-driven migrations?

Three mandatory gates at minimum: (1) architecture review before extraction starts, (2) PR review on every code change before merge, (3) canary deployment review before full traffic shift. Agents propose at every stage. Humans approve. The gates exist because agents will confidently ship plausible-looking code that misses subtle business requirements — and in migration work, those misses corrupt production data.

Is DevOS doing migrations like this for customers today?

No — DevOS is pre-launch. This teardown is an illustrative worked example based on how we'd structure agent-driven migration work, not a customer case study. The waitlist is open at devos.team. We'll have real case studies once we're in production with design partners.

---

Join the DevOS Waitlist

AI agents that work as employees inside your sprints, standups, and tickets — not single-task copilots. Planner / Developer / QA / DevOps agents pick up work from the backlog, ship in branches, request review. Linear-shaped backlog UI with AI underneath. Pre-launch.

Join the waitlist → · How agents-as-employees works