6 Software Migration Lessons from Shopify's 12-Week AI-Assisted Rewrite

A team of six at Shopify moved a major production app to a new stack in 12 weeks, with AI agents doing most of the porting. The lessons apply to any legacy modernization: the old system is the spec, parity is done, and humans approve.

Every engineering team has a migration it keeps postponing. Maybe it's a monolith that should have been split years ago, a framework two major versions behind, a database the business has outgrown, or a language nobody wants to hire for. Everyone agrees it should happen, and nobody wants to pay for it.

Shopify recently showed how quickly that calculation is changing. A team of six moved a major production app to a new stack in 12 weeks, with AI coding agents doing most of the porting (read Shopify's post). Their case was a mobile app, but the lessons have nothing to do with mobile. They apply to any legacy modernization project, whether that's a backend, a data platform or an internal tool.

Here's what we took from it.

1. Revisit the migration you shelved, because the cost has changed

Shopify didn't migrate because the old system broke. They migrated because AI agents changed what it would cost to move. A rewrite that couldn't be justified a year ago became a 12-week project.

Most migration strategy discussions take the cost of moving as a given. It isn't anymore. If your team ruled out a migration as "too expensive" more than a year ago, it's worth asking again.

2. Your legacy system is the spec

Shopify found that agents work best when there's an existing implementation to use as a reference. That's the hidden advantage of migrations over new builds. You aren't asking AI to guess what to build. You're asking it to reproduce behavior that already exists, runs in production and has years of edge cases baked in.

Shopify's process started with documenting how the old system behaved (its UI, state, data flows, analytics and accessibility) before writing any new code. Every software migration should start the same way: build an inventory of what the legacy system actually does, not what the documentation says it does. That inventory is what you test the new system against.

“To me, legacy code is simply code without tests.” — Michael Feathers, Working Effectively with Legacy Code

3. Parity is the definition of done

This is the most important lesson, and the one most teams skip. Shopify built an internal tool that captured outputs from both the old and new systems at named checkpoints. Agents then compared them automatically, ignoring expected noise like timestamps and IDs.

Generated code that looks right isn't the goal. The goal is a new system that behaves like the old one, including the parts nobody remembers to test:

• Events and data feeds that downstream systems depend on
• Users and sessions that carry across without interruption
• Integrations, notifications and background jobs

Shopify treated their analytics events as a contract, because other systems relied on them. Every legacy system migration has contracts like that, and most aren't written down. Parity checks are the best risk mitigation you have: without them, an AI migration just moves the risk somewhere else.

Code that looks right isn't done. A new system that behaves like the old one, checked with evidence, is.

“With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.” — Hyrum Wright, Hyrum's Law

4. Humans approve, agents execute

Shopify didn't let agents run unchecked. Engineers reviewed requirements and plans before any code was written, and each approval was tied to a content hash. If the plan changed, the approval was voided automatically.

They also kept experienced engineers reviewing the output, because generated code could meet every requirement and still add duplication, architectural drift or performance problems.

That's the right split for any serious application migration. Agents bring speed and scale. People own the decisions, the quality bar and the sign-off, and every change can be traced back to an approved plan.

5. Parallelize the work, but keep the feedback loop fast

Shopify ran many agent sessions at once, each in its own git worktree, instead of making one change at a time. They also gave agents direct access to the running system's logs, events and state, so agents could check their own work.

The pattern carries over to any migration:

1. Split the work into independent lanes (modules, services or features).
2. Give each lane a clear, approved task definition.
3. Give agents a fast way to build, test and observe the result.
4. Review often.

The bottleneck moves from typing code to defining tasks well and reviewing results quickly. Plan your team's time around that.

6. Migrate and simplify at the same time

Shopify didn't port everything one to one. They retired some screens and simplified others. A migration is the cheapest chance you'll ever get to drop dead code, unused features and accidental complexity, since you're touching everything anyway. Decide what not to migrate before you start.

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” — Antoine de Saint-Exupéry, Wind, Sand and Stars

What's still missing: the last mile of a software migration

Shopify's post focuses on building and verifying the new system. It says little about feature flags, gradual rollout or rollback, which is where many migrations actually fail.

At MigrateX, we see a migration as everything from understanding the old system to safely retiring it:

1. Discover what the legacy system really does
2. Plan the migration, with human approval
3. Migrate in parallel lanes with AI agents
4. Verify parity against the original
5. Roll out gradually, with rollback ready

The takeaway

AI can turn a multi-quarter migration into a matter of weeks. But Shopify's speed came from discipline, not just code generation: they treated the old system as the spec, proved parity, gated plans and kept humans on review.

That discipline is what we're building into MigrateX. Have a migration you've been putting off? Talk to us about a migration feasibility sprint.

Key takeaways

• AI agents have changed the cost of migrating, so re-check the migrations you shelved.
• Inventory what the old system actually does; that inventory is the spec.
• Done means behavioral parity, proven with side-by-side checks, not code that looks right.
• Engineers approve plans and review output; agents do the volume in parallel lanes.
• Plan the rollout and rollback, not just the rewrite.

Source: Shopify Engineering, Shop app migration. Figures are from Shopify's post.

Related reading: how multi-agent AI speeds up application migration, a migration testing strategy with AI agents and 10 legacy modernization mistakes to avoid.

Originally published on the CobuildX blog.