MAUI Native to Blazor Hybrid — Migration Estimate

Updated: 2026-08-08 · Audited: 2026-06-26 · Analysis date: 2026-03-12

Historical LOE analysis — kept for the record, not for planning. This is the pre-decision level-of-effort analysis dated 2026-03-12; the Blazor Hybrid decision resolved 2026-06-08 and the migration has since been executed — ~55 Razor pages exist under ALPAMobile.Presentation/Components/Pages/, including LoginPage and the Jumpseat suite. The estimates, codebase measurements, and tier assignments below describe the codebase as of 2026-03-12. The live state of the UI is the ALPAMobile.Presentation project.

Status: Planning / Analysis — Decision resolved 2026-06-08: proceeding with Blazor Hybrid straggler migration

Codebase Profile

This is an upper-moderate / borderline large enterprise application.

Dimension	Measurement
Screens/Pages	52 XAML pages + 7 custom controls = 59 UI elements
ViewModels	69 files, ~15,000–20,000 LOC
Services	17 files, ~8,000–10,000 LOC
Business Logic	4 files (regulatory FTDT calculations)
Data Models	40+ model files, 3 databases (LiteDB)
Helpers	14 files, ~2,000–3,000 LOC
Platform-specific	18 files across Android/iOS
DI Registrations	~60+ singletons/transients
Shell Routes	47 registered routes
Total estimated LOC	30,000–40,000
Converters	6

Migration Approach

The recommended approach is a straggler migration: keep the MAUI app shell and native integrations, then progressively replace XAML pages and view logic with Razor components hosted inside BlazorWebView.

Guiding Principles

MAUI stays the host. Platform projects, startup, lifecycle, permissions, and packaging remain unchanged initially.
Extract logic into services first. Business logic must move out of ViewModels and code-behind before UI is replaceable.
Introduce BlazorWebView beside existing XAML. Mixed app during the transition.
Keep native capabilities behind service abstractions. Razor components call injected interfaces; MAUI provides implementations.
Replace MVVM bindings with component state. Component parameters, injected services, event handlers, and shared state containers replace bindings, converters, and commands.
Two-layer navigation during transition. MAUI Shell for app-level routing; Blazor routing inside hybrid sections.
Redesign at the component level. Preserve branding and UX intent, rebuild layout in HTML/CSS.

Complexity Factors

Authentication — Very High

Dual-mode auth: JWT (active) + MSAL (scaffolded, incomplete)
Semaphore-protected token refresh with session recovery
AutoLogin state machine: 11+ stages, dual-platform JS bridges, script reinjection recovery, MFA handling
Platform-specific: AES-GCM MSAL token cache (Android), WKWebView script message handler (iOS)
Decision: Auth layer remains fully native, consumed by Blazor via injected services. Estimated wrapping/abstraction: 2–3 weeks.

Jumpseat Flight Search — High

Two ViewModels alone total 1,900+ LOC
Cancellation token patterns, real-time filtering, location-based search, pagination, saved flights
Push notification integration for flight alerts
6 pages total (search, results, filters, saved, details, frequent searches)
Estimate: 3–4 weeks for Razor component migration.

FTDT (Flight/Duty Time) — High

Regulatory calculation engine (USA + Canada) — stays as service
6 related pages with complex scroll behaviors, editor focus, swipe-to-delete
Custom time picker control, form validation, duty period CRUD
Estimate: 2–3 weeks.

Document Center — Medium-High

Thread-safe collection syncing, unread tracking, auth-guarded async operations
PDF viewer (PDFJSPage) with embedded JavaScript
Category/list/detail pattern across 3 pages
Estimate: 1.5–2 weeks.

Phase Breakdown

Phase 0: Prerequisites

Item	Complexity	Effort
Extract logic from ViewModels into services	Foundational	3–4 weeks
Fix .NET 10 blockers (AB#1809 StackLayout, bugs)	In-progress	2–3 weeks
Set up BlazorWebView infrastructure	Low	1 week

Phase 1: Simple Screens

Item	Pages	Complexity	Effort
Settings, Profile, Card pages	~6	Low	1–2 weeks
Contact/Directory pages	~4	Low	1 week
Member Resources, Advocacy	~3	Low-Med	1 week
Info/content pages (etiquette, emergency)	~5	Low	1 week

Phase 2: List/Detail Screens

Item	Pages	Complexity	Effort
Document Center (list, detail, PDF)	4	Med-High	2 weeks
Pilot Group pages	6	Medium	1.5 weeks
Push Notification list/settings	2	Medium	1 week
KCM pages (airlines, airports, details)	4	Medium	1.5 weeks

Phase 3: Complex Screens

Item	Pages	Complexity	Effort
Jumpseat Flight Search suite	8	Very High	3–4 weeks
FTDT duty period suite	6	High	2–3 weeks
Home page (dashboard, drag-drop)	1	High	1–2 weeks

Phase 4: Auth and Native (Stay MAUI)

Item	Complexity	Effort
Login page / AutoLogin WebView	Very High	Keep native + wrap
Auth service abstraction for Blazor	High	2 weeks
Navigation dual-routing design	Medium	1–2 weeks

Phase 5: Cross-cutting

Item	Complexity	Effort
Styling/CSS design system	Medium	2–3 weeks
Testing (Blazor component tests)	Medium	2–3 weeks
Integration testing, regression, polish	Medium	2–3 weeks

Total LOE Estimate

Scenario	Effort	Assumptions
Straggler migration (recommended)	7–10 person-months	Keep native shell, migrate UI progressively, auth stays native
Aggressive migration (all UI to Blazor)	9–13 person-months	Everything to Razor except auth, push, platform integrations
Conservative (only simple screens)	4–5 person-months	Migrate ~20 simple pages, keep complex screens native

Recommended Staffing

Team Size	Duration
1 senior developer	8–12 months
2 developers (1 senior + 1 mid)	4–6 months
3 developers	3–4 months

What Stays Native (Should Not Migrate)

Login page / AutoLogin WebView — tightly coupled to platform WebView
Push notification registration (Firebase/APNS) — platform APIs
MSAL token cache — Android AES-GCM, iOS keychain
Map cache service — WiFi-gated image downloading
App lifecycle management

Key Traps Specific to This Codebase

Service Locator anti-pattern — heavy use of Shell.Current?.Handler?.MauiContext?.Services.GetService<T>() needs refactoring before Blazor components can consume services.
WeakReferenceMessenger coupling — Blazor components need a different state notification pattern (cascading parameters, shared state containers).
Custom ObservableRangeCollection — all list-binding logic assumes MAUI collection change notifications. Blazor uses StateHasChanged() instead.
AutoLogin JS bridge — current Android [JavascriptInterface] and iOS WKScriptMessageHandler patterns break inside BlazorWebView.
StackLayout deprecation (AB#1809, 1,042 warnings) — irrelevant for migrated pages, but any page staying native still needs them fixed.

Summary

Bottom line: ~7–10 person-months for the recommended straggler migration path. This maps to the upper-moderate / borderline large range (6–9 months), pushed higher by auth complexity, regulatory logic, and screen count (59 vs the typical 10–25 moderate benchmark). The effort is roughly 50–65% of original build cost given the broad UI migration scope and service extraction work.

The practical model is: native shell + hybrid UI + shared services — not a hard switch from MAUI to Blazor.