| What we measured | Result after 12 Weeks |
|---|---|
| Infrastructure and licensing cost | Down by 63% |
| Application response time | From 1.2s to 300ms, a 75% Drop |
| Availability / unplanned downtime | 99.95% uptime, from 10-12 unplanned outages to 0 |
| Patching and maintenance effort | Almost Eliminated |
| Audit and compliance readiness | Access logging closed the audit-trail gap; encryption and HIPAA-eligible services throughout |
| Handling of spikes during traffic load | Monday check-in surges now absorbed by autoscaling, no manual work |
Quick Summary
This insight covers how Bacancy helped migrate .NET application to AWS for a U.S. healthcare client running a clinical operations platform across a multi hospital network. It walks through the pre-migration audit, the refactor to .NET 10 on AWS, the HIPAA and PHI controls built into the architecture, the testing done before cutover, and the results at 12 weeks post-migration.
Table of Contents
Introduction
Around October 2025, a healthcare client based in the USA approached us with a requirement. They were running a multi-hospital network and required help with a clinical operations platform that handled patient records, scheduling, and billing.
This platform was built on .NET Framework 4.6.1, hosted on premise across their in house servers, with patient data in SQL Server and the web application running on IIS on Windows Server.
The application was stable, and clinicians were using it daily. The framework under it was the problem:
- The .NET Framework 4.6.1 had reached end of support, so it no longer received security patches, leaving known vulnerabilities unpatched in a system holding patient records
- Compliance exposure was mounting as a direct result, since running unsupported software with protected health data fails the Security Rule’s safeguard requirements
- Growth outpaced the on premise setup, so scaling for more facilities meant buying and maintaining more servers, which was no longer feasible
So, not only did the application need to be modernized, but also a new hosting environment since on-premises locked growth potential. So, cloud was the most obvious choice. And, on the cloud, AWS was the natural fit, not just because it leads the market, but because it offered a service built for exactly this job: AWS Transform, which uses AI to port legacy .NET Framework apps to modern .NET.
This insight covers how we ran the .NET AWS migration across a six-month engagement, what the audit surfaced, how we modernized a dead-end .NET Framework app to .NET 10 on AWS, how we handled HIPAA and PHI constraints mid-build, and what the platform looked like 12 weeks after the switch.
What We Found During the Pre-Migration Audit of the .NET Healthcare App
Before we proceeded to migrate .NET application to AWS, we audited the .NET healthcare platform. We needed to know exactly what we were moving, because an undiscovered issue in a system holding patient data carries far more risk than a delayed timeline. That audit took two weeks, and what it returned shaped every decision that came after.
1. 8 Outdated Packages and 3 Windows-Only Dependencies
The application ran on .NET Framework 4.6.1, which Microsoft retired on April 26, 2022, so it had run without security patches for years before we saw it. Our first job was to find everything holding the app to that old runtime.
We ran the codebase through AWS Transform, which read the project and flagged what would not move to modern .NET. It found 8 outdated NuGet packages we could just swap for current versions, and 3 Windows-only dependencies that took actual work to deal with: server-side WCF services, System.Web and Web Forms components, and System.Drawing, which the billing module used for PDFs.
2. PHI Spread into Logs, and No HIPAA Access Trail
Next we tracked the patient data. We went through the app and found every place protected health information was stored, written to logs, cached, or sent to another system. The app had grown for years, and the PHI had spread into places nobody had documented.
We found issues like patient data written to application logs in plain text, and gaps in how database access was recorded. The biggest one was observability. The .NET healthcare app kept no clear record of who opened which patient file, so it could not produce the access trail a HIPAA audit needs. That same gap was what had prompted the client’s security review.
3. Why Refactor was the Better Option than Lift-and-Shift
The audit gave us a clear idea of what to do next. We could have easily lifted the .NET healthcare app from on-premises to AWS, but that would have just moved the same problems to a new place. The framework would still be out of support, still Windows-locked, and still failing the compliance checks that brought the client to us. Moving it without fixing it was not worth doing.
We ended the audit by deciding how to handle each part of the healthcare app, using the six Rs of migration as the framework. For this app, the answer was refactor: rebuild it on a current framework, then run it on managed infrastructure in AWS.
If your team doesn’t have in-house AWS expertise to run this cloud migration assessment for your on premise application, you can hire AWS developers from us to run it for you.
How We Rebuilt the App on .NET 10 and Ran It on AWS
After deciding on the refactor strategy to migrate the .NET healthcare portal to AWS, the next task for us was to rebuild the portal on .NET 10 and prepare the AWS environment to host it. We did both together, because the rebuilt application needed a place to run, and the environment had to match what the new code expected. Here’s how we did it:
1. Porting the codebase with AWS Transform
We used AWS Transform to handle most of the rework. It read the .NET Framework project and converted what it could to .NET 10, which gave us a working build to start from instead of porting everything manually.
AWS Transform converted the 8 outdated NuGet packages on its own. The Windows-only code needed manual work: we turned the WCF services into ASP.NET Core Web API endpoints, replaced System.Drawing in the billing module with QuestPDF, and rebuilt the System.Web and Web Forms front end on ASP.NET Core MVC. Reworking those parts manually took us 3 weeks.
2. Moving the database to Amazon RDS
We moved the patient data to Amazon RDS for SQL Server, which let us keep the database engine the application already used while shifting patching, backups, and failover to AWS. We left the T-SQL and stored procedures unchanged, so the clinical workflows built on them like records, scheduling, and billing can function exactly as before.
We migrated their databases to AWS through AWS Database Migration Service with change data capture enabled, which kept the on-premises database available to clinicians while the copy synchronized in the background. We deployed RDS in a Multi-AZ configuration because a clinical platform cannot tolerate an outage from a single database failure.
3. Building the HIPAA compliant .NET Architecture on AWS
Before any patient data moved, we signed a Business Associate Agreement with AWS and confirmed every service in the design was HIPAA-eligible. The BAA only covers eligible services, so that list set the boundary for everything we built. Compute and database sat in private subnets with no public route in.
We encrypted patient data at rest with AES-256 using customer-managed KMS keys, and in transit with TLS 1.2 and above. CloudTrail and CloudWatch now record who accessed what and when, closing the audit-logging gap the old app had.
Read our guide on AWS HIPAA compliance for detailed insights on how to set up these controls for your healthcare application.
With the application rebuilt on .NET 10 and the AWS environment ready around it, the platform was set for testing before we moved anyone onto it.
Need Help Rebuilding Your Legacy .NET Application on the Latest .NET Version?
Hire .NET developers from Bacancy to handle the rewrites and dependencies that don’t port on their own, and get your app running on .NET 10.
The Testing Process Before We Migrate .NET Application to AWS
We spent more time testing than on any other part of this healthcare .NET AWS Migration project. The old system had run for years, and clinicians trusted the numbers it produced, so the rebuilt app had to return the same results on the same data before we could put it in front of anyone. We ran the testing in three phases, each answering a different risk.
Phase 1: Matching the Patient Data with the Source after Migration
The first job was confirming no patient data had changed during the move. After the AWS Database Migration Service (DMS) finished the sync work, we compared the new RDS database against the on-premises database directly, and checked for row counts on every table, value comparisons on the patient-record tables, and a manual review of 100 sample patients covering records, scheduling, and billing.
Phase 2: Running the Modernized App against Actual Clinical Workflows
A ported .NET app can pass in a test environment and still fail when clinical staff run their daily work through it. So we ran the .NET 10 build through the workflows clinicians work in, like regular patient registration, appointment scheduling, data charting, and billing. The client’s staff also helped test the exceptions that they have earlier faced in real practice, not something that gets covered in a test script.
This phase brought up 9 differences from the framework change, most in billing calculations and two in how dates printed on patient statements. We corrected each one and re-ran the same cases to confirm the fix, so none of them carried into live patient care.
Phase 3: Testing under Load, then Switching in Stages
The last testing phase for this .NET AWS migration project involved checking the platform under peak load. Because we need to make sure the modernized .NET healthcare application can also perform under severe conditions.
So we tested it during some Monday mornings, the time when the platform usually observed a surge in check-ins, and then we watched how Auto Scaling responded and where response times settled. Once the application seemed stable and able to work properly under different conditions, we started migrating the traffic and workloads.
We didn’t move the app all at once. We used DNS-weighted routing to send a small portion of traffic to AWS, checked that it held, and raised the share gradually while the on-premises system stayed live on standby.
Also, we kept the rollback path open until AWS had run clean for 8 weeks, then retired the old servers.
Need your ported .NET app tested before it goes into clinical use?
Bacancy provides healthcare software testing for clinical apps moving to a new platform. We check that the patient data matches the source, that the app works the way clinical staff expect, and that it stays stable under peak load.
Post-Migration Results After 12 Weeks: What Changed
The client’s original problems were cost, downtime, and a failing audit trail. After 12 weeks on AWS, here’s where each of those landed.
Conclusion
This .NET AWS migration for the healthcare client was not just a normal cloud migration. It was done to get a clinical platform off an out-of-support framework and an on-premises setup, move it to .NET 10 on AWS, enhance user experience for the clinicians, keep the patient data inside it compliant, and secure the whole way through.
For healthcare organizations exploring .NET cloud migration, the right place to start is a structured audit of the codebase, the dependencies, where the PHI lives, and the HIPAA controls already in place, and which parts are ready for the cloud and which need work first.
Doing this in-house is slow and risky when you’re working with patient data against a support deadline. As a trusted .NET development company, we at Bacancy take on .NET migrations like this as a single project, modernizing the app, moving it to the cloud, and handling the compliance work along the way.
Frequently Asked Questions (FAQs)
The cost of .NET app migration to AWS depends on the app more than the move. A modern .NET app that needs to be containerized and runs with a managed database usually costs less. A legacy .NET Framework app with Windows-only dependencies has to be rebuilt first, requires upgrading to the latest .NET version, and then migrated to AWS, so it costs more.
The clearest signal is the access trail. If the app can’t show who opened which patient record and when, it can’t produce what a HIPAA audit asks for, no matter how stable it otherwise runs. The other signs are an out-of-support .NET version no longer getting security patches, and PHI that has spread into logs, caches, or exports nobody is tracking. Any one of these is enough to put the app on a remediation list.
Keep the data encrypted the whole way through: AES-256 with customer-managed KMS keys at rest, and TLS 1.2 or above in transit. Run the compute and database in private subnets with no public route in, and while the data copies over with DMS, keep the on-premises system as the source of truth until the copy reconciles and matches. For PHI, sign a BAA, keep every service HIPAA-eligible, and use CloudTrail and CloudWatch to record who accessed what.