Migration

The Migration Engine

AI is quietly excellent at migration—not the flashy, zero-to-one generation that dominates the discourse, but the boring, painstaking, extremely valuable work of taking something that already exists in one world and moving it to another, intact.

This shouldn’t be surprising, but it is. Most conversations about AI capability center on creation. Can it write? Can it design? Can it think? But migration isn’t creation. It’s translation with structural awareness—holding the meaning of something separate from its expression and re-expressing it in a new idiom without losing what made it work. It turns out this is one of the things AI does best, and it’s worth documenting where.

Language and framework migration

The most obvious case. You have a working codebase in Python and you need it in TypeScript. Or you’re moving a frontend from React to Vue, or a backend from Express to FastAPI. A human doing this work faces a particular kind of exhaustion: every line requires a micro-decision. Not just syntax—def becomes function, fine—but semantic mapping. Python’s list comprehensions become JavaScript’s .map() and .filter(). React’s useState becomes Vue’s ref(). FastAPI’s dependency injection replaces Express’s middleware chain. Each substitution requires understanding what the original code meant, not just what it said.

AI handles this naturally because it has seen the same concepts expressed across languages millions of times. It has developed what amounts to a universal schema of programming ideas—a paginated API endpoint, a form with validation, an authentication flow—that exists independent of any particular language. When you ask it to migrate a Python REST API to Go, it doesn’t translate line by line. It recognizes the concept (a CRUD endpoint with input validation and error handling), then re-expresses it using Go’s idioms: structs instead of dictionaries, explicit error returns instead of exceptions, net/http patterns instead of decorator-based routing. It makes the thousand small decisions—naming conventions, file structure, error handling patterns—that would take a human days of documentation-reading to get right.

The result isn’t just code that compiles. It’s code that looks like it was written by someone fluent in the target language. That distinction matters. A naive translation produces code that works but that no one wants to maintain. AI migration produces code that belongs.

Database and infrastructure migration

Harder than language migration, because the constraints change in less visible ways. Moving from PostgreSQL to MongoDB isn’t just a syntax change—it’s a paradigm change. Relational schemas with foreign keys and joins become nested documents and denormalized data. The shape of the data has to change, and with it, every query, every index strategy, every assumption about consistency.

AI is good at this because it understands the tradeoffs at each level. It knows that a SQL JOIN across three tables might become an embedded subdocument in MongoDB—but it also knows when embedding is wrong, when you should reference instead, when the access pattern demands a different structure entirely. It can take a schema with fifteen related tables and produce a document model that preserves the relationships while respecting MongoDB’s strengths: read-heavy denormalization, atomic document updates, flexible schemas for evolving data.

The same applies to infrastructure migration more broadly. Moving from REST to GraphQL. From monolith to microservices. From on-premise to cloud. Each of these involves not just translating what exists but understanding why it was structured that way and how those reasons map onto the new environment. A monolith’s shared database becomes a set of service-owned data stores. A REST API’s twenty endpoints become a single graph with types and resolvers. AI can hold both architectures in view simultaneously—the source and the target—and map between them with an awareness of what changes and what stays.

Platform and ecosystem migration

The most complex category, because it involves migrating not just code but context. Moving an iOS app to Android. Porting a desktop application to the web. Taking a WordPress site and rebuilding it in a modern stack.

Consider the iOS-to-Android case. The languages are different (Swift to Kotlin), but that’s the easy part. The harder migration is conceptual. iOS uses UINavigationController for navigation stacks; Android uses Fragments and the Navigation component. iOS manages state with Combine and @Published properties; Android uses LiveData or StateFlow with ViewModels. The design language shifts from Human Interface Guidelines to Material Design. Permissions, lifecycle management, background processing—every system-level assumption changes.

What AI does well here is maintain the intent of the application across these shifts. It understands that a pull-to-refresh gesture in iOS maps to SwipeRefreshLayout in Android. It knows that an iOS TabBarController becomes a BottomNavigationView. It preserves the user experience—the flow, the information hierarchy, the interaction patterns—while completely replacing the implementation underneath. The app should feel native on both platforms, which means it can’t be a literal translation. It has to be a re-expression.

This is where AI migration is most impressive and least discussed. Platform migration requires understanding two complete ecosystems deeply enough to map between them at every level: language, framework, design system, platform conventions, and user expectations. A human doing this needs expertise in both worlds. AI has it by default.

What migration reveals

The pattern across all three categories is the same. AI is good at migration because migration is fundamentally about structural understanding—seeing through the surface of an implementation to the concept underneath, then rebuilding the surface in a new context. It requires holding two worlds in mind simultaneously, understanding the constraints and conventions of each, and making hundreds of small judgment calls about what’s essential and what’s incidental.

This matters more than it might seem. Most software work isn’t greenfield. It’s maintenance, modernization, and migration—moving things that already work into environments where they can keep working. The tools that are best at this unsexy, essential work might end up being more valuable than the ones that generate the most impressive demos. Migration isn’t glamorous. But it’s where AI is quietly, consistently, remarkably good.