| Metric | Before (Xamarin) | After 90 Days (MAUI) |
|---|---|---|
| Cold start time | 3.4 seconds | 2.1 seconds |
| App size | 84 MB | 63 MB |
| Patient intake render time | 480 ms | 290 ms |
| Play Store publish status | Blocked (Android 14 target) | Active, 6 updates shipped |
| App Store publish status | Blocked (iOS 18 target) | Active, 4 updates shipped |
| .NET version support | .NET 6 or before | (.NET 6+) |
| Pending CVE patches | 1 (5 months old) | 0 |
| Open HIPAA audit findings on the app | 2 | 0 |
| Average medication admin screen latency | 340 ms | 180 ms |
Quick Summary
This insight covers how Bacancy delivered a Xamarin to MAUI migration for a U.S. healthcare client running a clinical app on 800+ tablets and iPads across four hospitals. It includes the pre-migration audit, the HIPAA compliance care we took, the testing done, and the results at 90 days post-deployment.
Table of Contents
Introduction
In 2025, a US-based healthcare client reached out to us. They had an application built on Xamarin.Forms, running in production across four hospitals for four years. Their clinical staff used it in every shift for patient intake, medication administration, and reading patient charts on the move. From the user’s perspective, nothing was wrong. The problem was on the other side.
Google Play had rejected two of their recent update submissions. The Android build target was capped at Android 13, and the Play Store’s August 31, 2025 deadline required existing apps to target at least Android 14 (API level 34), with new submissions needing Android 15 (API level 35). Their iOS build had the same problem. Since April 24, 2025, Apple requires all App Store submissions to be built with the iOS 18 SDK in Xcode 16, which their Xamarin toolchain could not produce, and an iPad rollout for nursing staff had been on hold for three months.
Their compliance team had separately flagged the Xamarin-based app’s authentication layer in an internal HIPAA review, noting it would fail the proposed 2025 HIPAA Security Rule update on MFA and encryption.
They had looked at three options before calling us:
- Keeping the Xamarin app running with manual patches.
- A full native rewrite on iOS and Android separately.
- Or a Xamarin to MAUI migration with the existing shared codebase carried forward.
They wanted the migration path, but they wanted it run by a team that had experience working on HIPAA-regulated migrations before, and not just the version upgrade projects.
This insight covers how we ran the Xamarin to MAUI migration across a 14-week engagement, what went wrong during the migration, how we handled HIPAA and PHI constraints mid-build, and what the app looked like 90 days after go-live.
Results From the Audit Process Before We Started with the Xamarin to MAUI Migration
Before writing any MAUI code, we spent two weeks in a full audit of the existing codebase, dependencies, and compliance controls. Here are the key findings we collected:
1. Two of 47 NuGets Were Carrying PHI, and Nobody Was Maintaining Them
The Xamarin solution carried 47 third-party NuGet packages. We checked each one against these three parameters:
- Is there a MAUI-compatible version?
- Is the maintainer still active on GitHub? and,
- Does the package ever touch PHI?
41 had MAUI-compatible versions or direct replacements available. 4 needed version upgrades. 2 were unmaintained for 18 months, and both sat in the data path for protected health information (PHI). One handled barcode scanning for medication administration. The other handled local encryption for offline patient records.
We had to choose replacements and get them integrated before the Xamarin to MAUI migration work could start.
2. 19 HIPAA Controls Embedded Across the Codebase
We documented every HIPAA Security Rule control the application was supposed to follow, and matched each one to the code responsible for it.
19 distinct controls in total. Audit logging, encryption at rest, encryption in transit, authentication boundaries, session timeout handlers, role-based access checks, and PHI redaction in crash reports.
Each control went into a spreadsheet, linked to the specific Security Rule citation it addressed. The spreadsheet went to the client’s compliance officer before any code changes were made, and it became the final verification checklist at the end of the Xamarin to MAUI migration.
3. Six Custom Renderers in the Daily Clinical Workflow
The app had six Xamarin.Forms custom renderers, each built to handle a specific problem in how clinical staff interacts with tablets during a shift.
- Larger tap targets so nurses could hit buttons with gloved hands.
- Higher-contrast states for low-light patient rooms.
- Voice-input hooks for hands-free medication verification.
Three more renderers handled similar clinical-first adjustments to form inputs, signature capture, and barcode readouts.
Removing or breaking them during the Xamarin to MAUI migration would have affected every clinical user on every shift.
4. PHI Flow Mapping Across 23 Entry and Exit Points
We traced every path PHI took through the app. The count came to 23 points across entry, storage, and exit.
- 14 entry points, including EHR sync, barcode scan, manual intake form, and camera-based wound documentation.
- 6 storage points, including SecureStorage, in-memory view models, and a local SQLite cache for offline mode.
- 3 exit points, including outbound API calls, crash reporter, and analytics.
This map became the post-migration validation checklist. If PHI moved through a code path before the migration, an equivalent path had to exist after with the same encryption, audit trail, and access control.
Read our blog on MAUI vs Xamarin comparison to learn more about the differences between these two and why the migration actually made sense.
The Xamarin to MAUI Migration Architecture We Chose
With the audit complete, we designed the Xamarin to MAUI migration in three layers. This is how we usually run .NET migration services for clients from regulated industries, and each layer has to pass its own checks before the next one starts.
1. Framework Conversion Layer
We started with the .NET Upgrade Assistant running across the solution. It converted the csproj files to SDK style, swapped Xamarin.Forms namespaces over to Microsoft.Maui, and updated the package references that had direct MAUI equivalents.
About 60% of the mechanical work was handled in the first run without needing a second look. The other 40% was manual.
The custom renderers had to be rewritten as handlers, one at a time. DependencyService calls had to be replaced with MAUI’s built-in DI, which required updating every service registration in the app. Async handling also changed between Xamarin and MAUI in a few places, so older task-based and event-based code had to be rewritten against the new patterns.
2. HIPAA Control Preservation Layer
Every control from the pre-migration inventory had to be reimplemented and verified before we moved on. SecureStorage took the most time.
The APIs for Xamarin.Essentials.SecureStorage and Microsoft.Maui.Storage.SecureStorage shares method signatures, but the Android Keystore and iOS Keychain integrations behave differently on older OS versions, and we had existing PHI in storage that could not be lost or re-prompted for on first launch.
So, we wrote a first-launch re-encryption routine. For each entry, it read the value under the old key, decrypted it, re-encrypted it under the MAUI-managed key, verified the write, and cleared the old entry. We tested this on the actual tablet models that clinical staff used, including two older Samsung Galaxy Tab models that needed a device-specific retry path before we were comfortable shipping.
The audit logging pipeline was rebuilt against MAUI DI. Same log schema, same SIEM ingestion path, same field structure. We ran a replay test using a captured sequence of clinical actions from the pre-migration app, fed the sequence through the new logger, and diffed the output. Schema, timestamps, and user context all matched before the new pipeline went live.
3. Compliance Hardening Layer
The third layer was the compliance hardening work that would have come due anyway, and we took it on during the Xamarin to MAUI migration process, instead of scheduling it as a separate release.
We added TLS 1.3 enforcement, certificate pinning on the API client, and multi-factor authentication ahead of the proposed 2025 HIPAA Security Rule update, and tuned session inactivity timeouts for shared clinical devices.
Doing this during the migration avoided a second round of regression testing on the same screens later.
Want the same team on your Xamarin to MAUI migration?
You can hire .NET developers from Bacancy who have worked on HIPAA-regulated healthcare apps before.
How We Tested the Healthcare MAUI App Before Release
We ran the parallel testing of the Xamarin and MAUI apps for six weeks. The Xamarin app stayed in beta with production data while the MAUI version went through QA on matched devices. Clinical staff ran both on the same shifts and flagged anything different. Here’s what we did in particular for the Xamarin to MAUI migration in healthcare project testing:
1. PHI Leak Scanning Across Every Code Path
First, we looked for PHI leaking into logs, crash reports, or analytics events. We ran static analysis across the MAUI codebase to find every code path where a PHI-tagged variable could end up in one of those three places, and the scan returned 14 paths that needed fixing.
Static analysis misses cases where strings get built at runtime, so we also reviewed the three highest-traffic screens manually.
The crash reporter was where we spent the most time. Exception messages often include the object state that caused the exception, and that state can include PHI, so we added a PHI-stripping step to every serializer that worked with a protected model before any report left the app.
2. Checking Performance Benchmarks on Actual Clinical Hardware
We benchmarked the MAUI app on the tablets the client used in the hospitals, including three-year-old Samsung models that are still in daily clinical use. Older hardware is where an older Xamarin app shows its age the most, so we wanted numbers from the devices that would feel the change first.
We measured cold start going from 3.4 seconds down to 2.1 seconds. App size went from 84 MB to 63 MB. The patient intake screen rendered in 290 ms on the MAUI build, against 480 ms on the Xamarin build.
Syncfusion’s published benchmarks report roughly 40% faster launches and 25% smaller app sizes for MAUI versus Xamarin.Forms, and the numbers we recorded on the client’s devices matched that range.
3. Compliance Verification Against the Pre-Migration Inventory
Every one of the 19 HIPAA controls from the pre-migration inventory was re-verified after the Xamarin to MAUI migration.
- For audit logging, we replayed every PHI interaction type we could reproduce in test and confirmed the logger wrote the expected schema for each.
- For encryption at rest, we pulled PHI from SecureStorage on all the tablet models the client used and confirmed the data was unreadable without the MAUI-managed key.
- For session handling, we ran six idle scenarios, including one where a nurse steps away mid-screen and another where the tablet screen locks, and confirmed the session ended on schedule in every case.
The compliance officer reviewed the spreadsheet with us, going through each control, approved it, and we submitted the first MAUI release to the Play Store the next week.
Need help meeting HIPAA requirements for your healthcare application?
Bacancy offers HIPAA compliance services for healthcare teams running PHI-handling apps. We handle audit preparation, control verification, and remediation work for teams going into an OCR audit or internal compliance review.
Post-Migration Results at 90 Days: What Changed
The table below shows the measurements collected before and after at the 90-day post-deployment mark. These numbers were collected from the client’s own monitoring dashboards, and not just some projections.
Two numbers in the table need context.
The pending CVE patch had been on the client’s security risk register for five months because the Xamarin build could not publish updates. We released it on the Tuesday after deployment, and the CISO called it the most valuable outcome of the project. The medication administration latency drop was a secondary benefit. The handler rewrite and the SQLite cache work made reads and UI updates faster on that screen, and the 90-day numbers reflected it.
In the same 90-day window, the client published 10 updates across iOS and Android, closed every open HIPAA finding on the app, and moved one QA engineer off manual patch work and back onto feature testing.
Conclusion
This project of Xamarin to MAUI migration in healthcare was not just a framework upgrade project. It was a migration done to keep a critical application compliant with the HIPAA Security Rule, FDA QMSR, and the app store requirements that had already started blocking updates.
For healthcare organizations with a Xamarin app still in production, the right place to start is a structured audit of the existing codebase, dependencies, PHI flow, and HIPAA control inventory, run by a .NET development company that has done this before.
We, at Bacancy, handle .NET projects like this by planning the audit and the migration together, with the compliance team involved from the start.
Frequently Asked Questions (FAQs)
Most of the Xamarin to MAUI migration projects run 10 to 16 weeks. The timeline depends on how many custom renderers the app has, how many third-party NuGet packages need replacement, and whether compliance audits are part of the scope. Regulated apps in healthcare or finance take longer because every control has to be documented and verified before release.
Not if the compliance work is planned alongside the code work. The safest approach is to document every HIPAA control in the existing app before migration starts, match each one to the code that implements it, and verify every control in the MAUI build before it reaches production. Teams that skip this step usually find compliance gaps during the next internal audit.
Yes. MAUI replaces Xamarin.Forms custom renderers with handlers, which is a different pattern. Each renderer has to be rewritten against the handler API, and this is typically the largest manual effort in a Xamarin to MAUI migration. Apps with heavy UI customization, accessibility requirements, or platform-specific behavior tend to have the most renderers to convert.
Existing PHI has to be re-encrypted when the MAUI app launches for the first time. The typical approach is a one-time migration routine that reads each entry under the old key, decrypts it, re-encrypts it under the MAUI-managed key, verifies the write, and then clears the old entry. Older Android devices sometimes need a device-specific retry path because Keystore behavior varies across OS versions.