How Coding Agents Changed the Migration Math

I came across Shopify’s engineering write up on migrating the Shop app from React Native to native (Swift and Kotlin), and it immediately caught my attention.

Shopify moved Shop toward React Native around 2020. Now they rebuilt it as native, assisted by coding agents, and went from a proof of concept to store release in about 12 weeks.

That alone is interesting. What stuck with me is what it means for the rest of us, especially in enterprise software where most of the code is brownfield.

First, some background on why cross platform won for a decade, and why this reverse move is different.

Why cross platform won for a decade

For about a decade, frameworks like React Native, Flutter, and .NET MAUI / Xamarin gained a lot of traction. Feature parity across iOS and Android was easier. You did not need parallel teams deep in Kotlin and Swift. Mobile teams could iterate fast and ship more features with one focused skillset.

There was always a performance compromise. Compared to faster feature shipping, that tradeoff still made sense for a lot of companies. For greenfield apps it was often a no brainer. Even brownfield native apps moved that direction when the org cost of dual platforms got too high.

And it was not just startups.

Coinbase replatformed to React Native around 2020 to 2021. Discord rebuilt Android on React Native in 2022. Walmart layered React Native into existing native apps. Google Pay and Nubank made big Flutter bets so they were not building everything twice. Bloomberg was an early React Native adopter on the consumer side.

The story was consistent: shared code, shared talent, faster shipping.

Airbnb sunsetting React Native in 2018 was an early reminder that the pendulum can swing the other way. Usually for organizational and platform cost reasons, not because someone suddenly fell in love with Swift again.

Shopify’s reverse move is different. Their point is not nostalgia for native. Coding agents changed the cost of building twice. See also their earlier bet that React Native was the future of mobile at Shopify, and the later back to native argument.

What Shopify actually did

One engineer spent a week with coding agents trying to migrate as much of the existing React Native app as possible into a native iOS app. Not production ready. Close enough on screens, flows, and behavior that leadership got confidence.

Then a core group of about six engineers built the native foundations and main user journeys. Feature teams joined later for edge cases. Priority was preserving behavior and analytics so downstream systems did not break. Users stayed signed in. Push kept working. It needed to feel like a normal app update.

They also used the rewrite to simplify. Some screens got retired. Some got streamlined.

Results they published: faster cold start, higher session stability, much smaller Android binary, better Android scroll performance.

Under the hood they invested in agent workflow, not just “prompt and pray”:

1. Clear tasks. Agents got scoped work, not vague “migrate the app” prompts.
2. Fast build and test loops. Feedback had to be cheap enough for agent iteration.
3. Plan review before code. Engineers accepted plans before implementation. Changing a plan invalidated prior acceptance.
4. Runtime feedback. A debugging tool they call Tardis let agents inspect live app events, logs, and state, and compare parity checkpoints between the old app and the new one.

Native expertise still mattered. Generated code can look fine and still create duplication, architectural drift, or performance problems.

LLMs changed the risk math. They did not make brownfield easy

Given how much LLMs matured over the last year, especially since Claude Sonnet 4.5 and now Sonnet 5 class systems, enterprises started playing with migrating critical pieces of codebases to the language or stack of their choice.

Migrating brownfield legacy code was never fun. It gets worse when the system cannot afford downtime. Think healthcare apps that cannot complete a clinical session. Financial apps that cannot fulfill trades. The blast radius is real people and real money, not a demoware failure.

Team skills also play a major factor. Enterprises have to decide if existing teams can own, manage, and optimize what gets shipped. Teams have to own every line of code and every piece of functionality in production. When things break, teams need to know how to fix it. They cannot leave it to the mercy of LLMs. That path slowly kills confidence in application quality, and it does not reassure anyone about the impact of a fix elsewhere in the system.

If you migrate to a stack your people cannot operate, you have not modernized. You created a dependency.

Building a mature agentic system is the real unlock

Agents perform extremely well on greenfield projects. Brownfield apps need surgical changes pretty often. Poor documentation. Legacy or outdated libraries. Inconsistent design principles. That is a different problem.

Getting high accuracy here takes real agentic engineering:

1. An enterprise-aware harness. The system has to know your org, repos, and constraints.
2. Tools that reach your knowledge base. Agents need real docs, tickets, and runtime signals, not only source files.
3. The right rules and skills. Guardrails beat heroic prompting.
4. Compact, optimized context. Context window waste is accuracy waste.
5. Precise tool calling. The right tool for the task and situation.
6. Specialized micro agents. Split by domain and software layer instead of one mega agent.
7. Agents that can improve over time. Static prompts rot. Migration systems should not.

I will cover more on just this in a series of upcoming articles.

Without that foundation, venturing into bold migrations solely on model proficiency is a gutsy and risky move. Shopify did not “ask ChatGPT to rewrite the app.” They built migration workflow around agents, with humans still owning plans and reviews.

The part most victory laps skip: tokens and money

Another missing thing from the Shopify article is tokens and money spent.

If the majority of implementation volume is handled by a workhorse model, the economics get very interesting. Models like DeepSeek V4.1 Flash are around $0.15 to $0.30 per million input tokens and $0.60 to $1.20 for output, depending on peak versus off peak. That is on the order of 100x cheaper than frontier models like GPT-6 Astra or Claude Fable 5.1, which sit around $10 input and $50 output per million tokens.

Cheaper tokens are not enough by themselves. What matters is low cost to finish a task. That only happens when the agent harness is optimized, not when you throw the most expensive model at every step. Mid-tier models like Claude Sonnet 5, Gemini Flash class models, or coding-oriented IDs often win on dollars per outcome when the system around them is solid.

For enterprise business cases, that line item belongs next to headcount and calendar risk.

Engineering migration checklist

Shopify’s write-up is a strong blueprint for one class of migration: clear product behavior, a reference implementation, parity tooling, and native experts still in the loop.

For brownfield enterprise, the keys look more like this:

1. Agentic infra first. Build the agentic system as the migration backbone, not a side project.
2. Skill up from and to. People have to own the new code when agents are offline.
3. Teams for both codebases. Clean handoffs are a fantasy during the overlap.
4. Strangler / dual-run. Switch users back to the old path when the new one fails. Treat rollback as a product feature.
5. Cost to finish a task. Measure dollars and calendar as first-class outcomes, not AI productivity vibes.
6. Bundle UX improvements. If you are paying for a migration, do not only translate debt.

All in all, great signal from Shopify. The hard part for most of us is not choosing Swift over React Native. It is building the agentic operating model, keeping human ownership, and migrating critical systems without betting the company on a lucky context window.