Gergely Orosz — whose newsletter covers enterprise engineering at the level of practice, not press release — made this observation directly: when he talks with working developers, the single enterprise use case where AI coding tools reliably save meaningful time is migrations. Not general development work. Not greenfield builds. Migrations.
This matches what I see when enterprise teams describe where AI coding assistance is actually paying off versus where it produced more rework than it saved. The reason it’s true is specific enough to be useful.
timeline
title AI-Assisted Enterprise Migration
Discovery : Map source system behaviors
: Define target architecture
Translation : AI generates target-language code
: Engineers validate logic and patterns
Testing : Source vs. target output comparison
: Integration contract verification
Stabilization : Edge case resolution
: Performance validation
Cutover : Production deployment
: Source system decommissioned
The Characteristic That Makes Migration Tractable
Migration is a constrained problem. The expected output is defined: the new system should do what the old system does, in a different technology. There is a comparison point — the source system — that allows evaluation of whether the AI-generated code is correct. When something is wrong, you can identify it precisely: it produces a different result from the source under these conditions.
Greenfield development does not have this characteristic. A greenfield project produces output that reflects interpretation — how the developer, or the AI, read a requirements document or user story. There is no canonical correct answer. The AI’s interpretation might be wrong in ways that are difficult to detect, because the expected output was never precisely defined.
This is the structural reason AI coding tools perform better on migrations. The problem is constrained; the success criteria are clear; the output is verifiable against something that already exists. The verification discipline that’s difficult to impose on greenfield development is built into the nature of migration work.
The Retrofit Problem
At LERETA, the second-largest property-tax processor in the United States, we acquired a Texas-based company with capabilities in the same domain and attempted to retrofit its technology into a flagship product rebuild already underway. The data structures were similar but not identical. The processing logic had been built on different assumptions. Teams had to circle back and re-center the baseline after the incompatibility became clear.
In retrospect, a fresh requirements-gathering process and a clean build would have been faster and cheaper than the retrofit. What looked like an accelerant — existing code from a similar domain — became a source of rework that delayed the project and required teams to undo work they had already done.
The lesson translates directly to AI-assisted migration: the migration succeeds or fails based on how clearly the target state is defined before AI generates code toward it. When the target is well-specified — a known technology, a defined architecture, a clear behavioral contract — the AI can generate code efficiently toward a known destination. When the target is ambiguous, or the architecture is being designed during the migration, the AI’s defaults fill the gaps and create the same retrofit problem in a new form.
What AI Migration Teams Do Differently
Enterprise teams that get real productivity gains from AI on migration have typically made three adjustments before generating any code.
First, they define the behavioral contract. The behavioral contract specifies what the system must do — which inputs produce which outputs, which integrations must continue to function, which edge cases must be handled — in enough detail that the migrated code can be tested against it independently of the source. This specification does not have to be long; it has to be precise about what matters.
Second, they do the architecture work before generating code. The target architecture is a decision, not an output of the migration process. Once the architecture is settled, AI tools can generate code toward a known destination. If architecture is emergent — designed as the migration proceeds — the AI generates code toward a moving target, and the coherence of the result deteriorates.
Third, they structure review for migration-specific failure modes. AI-generated migration code fails in predictable ways: edge cases the source system handled implicitly and the AI didn’t recognize, integration points that behaved differently in context, performance characteristics that matched the source in unit tests but diverged under load. Code review calibrated to these specific failure modes catches what a generic review misses.
Why Migrations Are a Good Enterprise Starting Point
For enterprise teams that are still working through how to govern AI coding at scale, migration projects offer a more tractable starting point than greenfield work for a specific reason: the governance requirements are defined by the source system.
The security surface, integration points, and data handling requirements on a migration are already known. They are not being invented — they are being preserved and, where possible, improved. This makes the checklist for evaluating AI-generated migration code more concrete: what the system must do, what constraints apply, and what the source system’s behavior was. The audit items are defined by what already exists, not by what the AI might have chosen to do.
Enterprise teams that start with a well-scoped migration — a single service or a bounded module, not an entire platform — tend to develop the review and validation disciplines that apply more broadly to AI coding, while working on a problem where the success criteria are clear enough to know when those disciplines are working.
