Migrating a small Xamarin.Forms application to .NET MAUI can be relatively straightforward.

Migrating a large enterprise mobile application is a completely different problem.

Enterprise applications often contain years of accumulated business logic, hundreds of screens, custom renderers, native Android and iOS integrations, third-party SDKs, background services, push notifications, offline synchronization, authentication systems, CI/CD pipelines, and production dependencies.

Simply converting the .csproj file and fixing compilation errors is not an enterprise migration strategy.

A successful migration should be treated as a controlled transformation program.

The objective isn't to convert Xamarin code to MAUI. The objective is to move a production application to a modern platform without disrupting the business.

This guide presents a practical approach for migrating large Xamarin/Xamarin.Forms enterprise applications to .NET MAUI.

1. Why Enterprise Migration Is Different

A typical Xamarin application may look like:

Mobile Application
 ├── Pages
 ├── ViewModels
 ├── Services
 ├── API
 └── Local Storage

A large enterprise application can look more like:

Enterprise Mobile Platform
│
├── Presentation
│   ├── 100+ Pages
│   ├── Custom Controls
│   ├── Renderers
│   └── Behaviors
│
├── Business Layer
│   ├── Domain Logic
│   ├── Workflows
│   └── Validation
│
├── Infrastructure
│   ├── REST APIs
│   ├── Database
│   ├── Caching
│   └── Synchronization
│
├── Platform Services
│   ├── Push Notifications
│   ├── Location
│   ├── Bluetooth
│   ├── Background Services
│   └── File System
│
├── Native Integrations
│   ├── Android SDKs
│   ├── iOS SDKs
│   └── Third-party SDKs
│
└── DevOps
    ├── CI/CD
    ├── Signing
    ├── Distribution
    └── Monitoring

Every one of these areas can introduce migration risk.

Therefore, the migration needs to be planned before the first code change.

2. The Migration Mindset

The traditional approach is:

Xamarin
   ↓
Upgrade Project
   ↓
Fix Compilation Errors
   ↓
Fix Runtime Errors
   ↓
Release

For an enterprise application, a better approach is:

ASSESS
   ↓
BASELINE
   ↓
DECOUPLE
   ↓
BUILD MAUI FOUNDATION
   ↓
PILOT
   ↓
MIGRATE IN WAVES
   ↓
VALIDATE
   ↓
CANARY RELEASE
   ↓
FULL ROLLOUT
   ↓
RETIRE XAMARIN

This creates checkpoints throughout the migration rather than discovering major problems near the end.

3. Phase 1 — Assess the Existing Application

Before migrating anything, create a Migration Inventory.

Document:

• Xamarin.Forms version
• .NET/Xamarin versions
• Target Android/iOS versions
• NuGet dependencies
• Custom renderers
• Effects
• Behaviors
• Custom controls
• Native Android code
• Native iOS code
• Background services
• Push notification implementation
• Authentication
• Local database
• Offline synchronization
• File handling
• Deep links
• Analytics
• Crash reporting
• CI/CD
• Signing and provisioning
• Automated tests

The goal is to answer:

What parts of this application are actually dependent on Xamarin?

4. Build a Dependency Risk Matrix

Not every dependency deserves the same migration strategy.

Classify dependencies into three categories.

Green

Already compatible with the target .NET/MAUI environment.

.NET libraries
Modern NuGet packages
Pure business logic

Yellow

Requires configuration or code changes.

Older NuGet packages
Custom controls
Navigation libraries
Storage libraries

Red

Requires replacement or significant redesign.

Xamarin-only packages
Unsupported renderers
Old native bindings
Unmaintained SDKs

This gives the team a migration backlog before implementation begins.

5. Phase 2 — Establish a Production Baseline

One of the most overlooked parts of migration is establishing measurable baseline data.

Before migration, measure:

Also document critical business workflows.

For example:

Login
Search Customer
Open Customer
Create Order
Submit Order
Offline
Synchronize
Receive Notification
Logout

These become migration acceptance criteria.

Without a baseline, "migration completed" can mean nothing more than "the application builds."

6. Phase 3 — Stabilize Xamarin Before Migration

If the existing application is on an older Xamarin.Forms version, stabilize it before starting the MAUI migration.

A useful sequence is:

Legacy Xamarin.Forms
        ↓
Latest stable Xamarin.Forms version
        ↓
Update dependencies
        ↓
Fix existing issues
        ↓
Production baseline
        ↓
MAUI migration

Do not combine an unstable legacy application with a platform migration.

Otherwise, you won't know whether a problem was introduced by the migration or already existed.

7. Don't Automatically Convert Everything

A common mistake is assuming that every piece of existing code should survive.

Ask three questions:

Does this code contain business logic?

Keep and modernize it.

Does this code exist only because Xamarin required it?

Consider removing it.

Is this code solving a problem that MAUI already solves?

Delete it.

Migration is an opportunity to reduce technical debt, but not an excuse for a complete rewrite.

8. Decouple the Business Layer

Before migrating large amounts of UI, separate the business logic from the Xamarin-specific code.

A target architecture could look like:

Presentation
      ↓
ViewModels
      ↓
Application Services
      ↓
Domain
      ↓
Infrastructure
      ↓
Platform

For example:

MyCompany.Mobile
MyCompany.Mobile.Core
MyCompany.Mobile.Domain
MyCompany.Mobile.Application
MyCompany.Mobile.Infrastructure

The objective is simple:

The less Xamarin-dependent your business layer is, the easier the migration becomes.

9. PCL Migration: Don't Create Unnecessary Intermediate Work

Many older applications use Portable Class Libraries.

A common migration path is:

PCL
 ↓
.NET Standard
 ↓
.NET

This can be useful, but it should not automatically become a mandatory intermediate step.

Instead, inspect what is actually inside the PCL.

If it contains:

Models
Business Rules
Validation
API Clients
Utilities

move these into modern reusable libraries.

If it contains:

Xamarin.Forms
Xamarin.Essentials
Platform-specific APIs

separate those dependencies first.

The goal is not:

"Convert the PCL."

The goal is:

"Extract reusable application logic from the PCL."

10. Build the MAUI Foundation First

Before migrating hundreds of screens, establish the new MAUI foundation.

MyCompany.Mobile
│
├── Configuration
├── DependencyInjection
├── Navigation
├── Resources
│
├── Core
├── Domain
├── Application
├── Infrastructure
│
└── Platforms
    ├── Android
    ├── iOS
    ├── Windows
    └── MacCatalyst

Set up:

• Dependency Injection
• Configuration
• Logging
• Navigation
• API clients
• Authentication
• Storage
• Telemetry
• Error handling
• Environment management

This creates the platform on which the migrated features can run.

11. Migrate One Vertical Slice

This is one of the most important changes to the traditional migration approach.

Do not migrate:

Page 1
Page 2
Page 3
...
Page 200

Instead, migrate a complete business capability.

For example:

Login
   ↓
Dashboard
   ↓
Customer Search
   ↓
Customer Details
   ↓
Create Order
   ↓
Submit Order
   ↓
Offline Sync

This single workflow exercises:

• UI
• ViewModels
• Navigation
• Dependency Injection
• API
• Authentication
• Storage
• Offline support
• Platform services
• Telemetry
• Error handling

If the vertical slice works, your migration architecture has been validated.

12. Renderers → Handlers

One of the major Xamarin.Forms migration areas is the transition from renderers to MAUI handlers.

But don't blindly convert every renderer.

Classify each renderer:

Custom Renderer
      │
      ├── Styling
      │      ↓
      │    Styles
      │
      ├── Behavior
      │      ↓
      │    Behavior
      │
      ├── Property mapping
      │      ↓
      │    Handler Mapper
      │
      └── Native control
             ↓
         Custom Handler

You may discover that some old renderers are no longer necessary.

13. Create Platform Abstractions

Avoid spreading platform-specific code throughout ViewModels and business logic.

Instead of:

#if ANDROID
...
#endif

everywhere, create interfaces.

For example:

public interface IPushNotificationService
{
    Task InitializeAsync();
    Task<string?> GetTokenAsync();
}

Then implement:

IPushNotificationService
        │
        ├── Android
        └── iOS

The same pattern can be applied to:

IBiometricsService
ILocationService
IFileService
IAudioService
IDeviceService
IBackgroundService

This keeps platform-specific code isolated.

14. Treat Native Functionality as a Separate Migration Track

Native functionality deserves its own checklist.

Android

MainActivity
Services
Broadcast Receivers
Firebase Messaging
Permissions
Intents
Background Processing

iOS

AppDelegate
Push Notifications
Background Tasks
Extensions
Permissions
Native SDKs

Don't consider the migration complete until these areas have been individually validated.

15. Firebase and Push Notifications

Push notification migration can be more complicated than expected.

Validate:

App running
App backgrounded
App terminated
App restored
Token refresh
Notification tap
Deep link
Data payload
Notification payload

Test both:

Android
iOS

And test different OS versions and device manufacturers.

Push functionality should be considered a production-critical capability, not just another NuGet package migration.

16. Authentication Must Be Tested End-to-End

Enterprise applications frequently use:

• OAuth
• OpenID Connect
• Microsoft Entra ID
• SSO
• biometric authentication
• refresh tokens
• secure storage

Validate:

Login
 ↓
Token
 ↓
API
 ↓
Token Refresh
 ↓
Logout
 ↓
Re-login

Also test:

• expired tokens
• revoked sessions
• offline behavior
• device restart
• application restart

17. Keep Xamarin and MAUI Side-by-Side

For a very large application, a side-by-side migration can significantly reduce risk.

                 Shared Core
                     │
          ┌──────────┴──────────┐
          ↓                     ↓
       Xamarin                MAUI
          │                     │
      Legacy UI             New UI

Migrate functionality progressively.

Eventually:

Xamarin
   ↓
Remaining modules
   ↓
Zero modules
   ↓
Retire Xamarin

This approach allows the existing application to continue receiving releases while migration continues.

18. Use Feature Flags

Feature flags allow old and new implementations to coexist.

CustomerDetails.Maui
        │
        ├── false → Xamarin
        │
        └── true  → MAUI

A feature can then be enabled for:

Internal testers
      ↓
Pilot users
      ↓
Small production group
      ↓
Larger production group
      ↓
Everyone

If a problem occurs, disable the MAUI implementation without necessarily rolling back the entire application.

19. CI/CD Should Be Migrated Early

Do not wait until the application is fully converted.

Build the pipeline early:

Pull Request
      ↓
Build
      ↓
Unit Tests
      ↓
Static Analysis
      ↓
Android Build
      ↓
iOS Build
      ↓
Integration Tests
      ↓
Artifact

Then:

Development
     ↓
QA
     ↓
UAT
     ↓
Internal
     ↓
Canary
     ↓
Production

Validate early:

• Android signing
• iOS signing
• provisioning
• certificates
• app identifiers
• push configuration
• environment configuration
• crash reporting
• symbol upload

A migration that works only on a developer's machine is not complete.

20. Automated Testing Is a Migration Requirement

Create three levels of validation.

Unit tests

Business rules
Validation
Domain logic

Integration tests

API
Authentication
Database
Synchronization

Device tests

Android
iOS

Critical workflows should be automated before migration begins.

Otherwise, the team will spend enormous amounts of time manually comparing old and new applications.

21. Performance Testing

Don't assume that moving to MAUI automatically improves performance.

Compare the old and new applications.

Measure:

Startup
Memory
Navigation
Scrolling
API operations
Database operations
Synchronization
Battery usage
Application size

Test on:

• low-end Android devices
• popular Android manufacturers
• supported iPhones
• slow networks
• offline mode
• application restart
• background/foreground transitions

The goal is measurable equivalence or improvement, not simply successful compilation.

22. Observability During Migration

Add migration-specific telemetry.

For example:

MigrationFeature = CustomerDetails
MigrationVersion = 5.2
Platform = Android
Implementation = MAUI

Track:

Crash rate
API failures
Navigation failures
Startup time
Feature failures
User workflow completion

Now you can compare:

Xamarin production
       VS
MAUI production

using actual data.

23. Don't Combine Migration With a Major Rewrite

This is probably the most important practical recommendation.

Avoid:

Xamarin → MAUI
       +
New UI
       +
New architecture
       +
New API
       +
New database
       +
New authentication

Instead:

Release 1 — Migration

Xamarin
   ↓
MAUI

Focus on functional equivalence.

Release 2 — Stabilization

MAUI
 ↓
Performance
 ↓
Reliability
 ↓
Operational improvements

Release 3 — Modernization

MAUI
 ↓
New UI
 ↓
Architecture improvements
 ↓
New features

This makes failures easier to isolate.

24. Track Migration Debt

Not everything needs to be modernized immediately.

Create migration tasks such as:

MAUI-MIG-001
Replace legacy renderer

MAUI-MIG-002
Remove Xamarin compatibility dependency

MAUI-MIG-003
Modernize navigation

MAUI-MIG-004
Replace legacy native binding

MAUI-MIG-005
Remove platform-specific conditional logic

This prevents temporary migration compromises from becoming permanent architecture.

25. Enterprise Migration Scorecard

Track every module.

This creates a common language between developers, QA, architects, DevOps and management.

26. Recommended Migration Roadmap

A practical enterprise migration can be organized into these phases:

Phase 0
Assessment
       ↓
Phase 1
Baseline & Stabilization
       ↓
Phase 2
Architecture Decoupling
       ↓
Phase 3
MAUI Foundation
       ↓
Phase 4
Pilot Vertical Slice
       ↓
Phase 5
Platform & Native Migration
       ↓
Phase 6
Feature Migration Waves
       ↓
Phase 7
Regression & Performance
       ↓
Phase 8
Canary Production
       ↓
Phase 9
Full Production Rollout
       ↓
Phase 10
Xamarin Retirement
       ↓
Phase 11
Application Modernization

27. The Golden Rules

If I had to reduce the entire migration strategy to ten rules:

1. Don't start with the .csproj

Start with an assessment.

2. Establish a baseline

Measure the existing production application.

3. Don't migrate everything at once

Use incremental migration.

4. Decouple business logic

Reduce platform dependency.

5. Migrate vertical slices

Move complete business workflows.

6. Isolate native code

Keep Android/iOS implementation behind abstractions.

7. Don't blindly convert renderers

Determine whether they are still necessary.

8. Use feature flags

Keep rollback paths available.

9. Automate validation

Build tests before the migration becomes large.

10. Separate migration from modernization

First move to MAUI. Then improve the application.

Conclusion

A Xamarin-to-.NET MAUI migration for a large enterprise application should not be considered a simple framework upgrade.

It is an application transformation project.

The most effective strategy is to create a stable baseline, understand the application's dependencies, separate business logic from platform-specific code, establish the MAUI foundation, and then migrate complete business capabilities incrementally.

The migration should look like:

        ASSESS
           ↓
        BASELINE
           ↓
        DECOUPLE
           ↓
      MAUI FOUNDATION
           ↓
       PILOT SLICE
           ↓
    FEATURE MIGRATION
           ↓
      VALIDATE
           ↓
     CANARY RELEASE
           ↓
    FULL PRODUCTION
           ↓
    RETIRE XAMARIN
           ↓
      MODERNIZE

The most important mindset shift is this:

Don't ask, "How do we convert our Xamarin application to .NET MAUI?"

Ask:

"How do we move our enterprise application to .NET MAUI while keeping the business running?"

That question leads to a very different—and much safer—migration strategy.

By Niladri