Developer Diaries

Developer Diary: Migrating Xamarin to MAUI

Written by Craig Rowe | Jun 30, 2025 11:00:00 PM

The funny thing about migrations is they often look simple on the outside. All you are doing is just lifting something up and putting it back down somewhere else. But if you’ve ever actually done one, you know it’s anything but that. 

That was the shape of the challenge we stepped into earlier this year. The mobile app in question had been running on Xamarin which was a Microsoft cross-platform framework that was rapidly approaching obsolescence. The shift to MAUI was a technical necessity, not a nice-to-have. Once support ended, you’d struggle to even push updates to the app stores. So, deadlines weren’t negotiable.

📖 Developer Diaries: Craig Rowe on Migration in Motion

The client already had a strong internal team of architects, developers, designers, and testers, and had even brought in external contractors. But things weren’t moving fast enough. That’s where we came in. Our team slotted in to accelerate the transition. Extra developers, QA, project delivery support, and a bit of my time. Enough to make an impact without creating more process than progress.

We weren’t just rewriting screens. We were running two versions side by side, often on dual simulators. One version showing a fully functioning feature set. The other? Sometimes just a placeholder and a TODO. Each day we chipped away at the gaps.

Process can be a problem

What made it interesting was the balance. Technically, the stack was familiar. Xamarin, MAUI, C#, XAML. But the environment was tight: defined backlogs, detailed ticketing, and a process-heavy governance model that left little room for deviation. We couldn’t just carve off a slice of the app and own it end-to-end, not in the way we might normally prefer. 

Sometimes that meant suggesting softer process shifts and highlighting where velocity was being traded for perceived control. Sometimes it meant drawing from past experience. We’d done a very similar migration not long ago, so we knew the traps. We knew what not to re-architect, what to defer, and what to flag for later.

AI codebase exploration

We also made the most of AI tooling. It wasn't for writing code in this case, but for exploring and understanding the code that already existed. Personally, I found myself using tools like Cursor as a genuine assistant. Download a huge repo, something breaks, and instead of pinging the client dev team for help, I’d feed the error to the assistant and interrogate the system.  Interactively, tactically. I even used it to mock up a sample MAUI app with a fake GraphQL API, purely as a test harness. It let me experiment and deepen my understanding without draining the team’s time.

And that turned out to be valuable. Because this migration wasn’t the end. It was a step toward a bigger shift: a move to a microservices backend, exposed via a GraphQL supergraph. That’s where things get interesting. With async operations and subscriptions replacing the traditional request-response flows. It changes how the UI behaves, how caching works, even how you think about confirmation and failure. 

We didn’t get to overhaul everything. But we got the job done. The migration is shipping. And the foundation is in place for what’s next. It’s the kind of project where the tools mattered, but the mindset mattered more. A steady pace, deep context, and a clear eye on the real constraint: time.

👉 AI Native Software Development

This is an AI generated summary of a conversation with Dootrix Principle Architect - Craig Rowe