| Timeline | Activity |
|---|---|
| Weeks 1–3 | Dependency mapping, runtime compatibility assessment, workload discovery, and migration planning |
| Weeks 4–5 | Azure architecture design, hosting model selection, security planning, and cost forecasting |
| Weeks 6–10 | Application remediation, CI/CD setup, database migration preparation, and environment provisioning |
| Weeks 11–14 | Database migration, deployment testing, performance validation, and user acceptance testing |
| Weeks 15–16 | Production cutover, post-deployment validation, monitoring setup, and performance optimization |
Quick Summary
This insight explains how Bacancy migrated a legacy .NET application to Azure for a US logistics enterprise running a freight and order management platform on aging on-premises infrastructure. It walks through the challenges we found before migration, the assessment process we followed, how we selected the Azure hosting model for each workload, the execution framework we used, and the results recorded after deployment.
Table of Contents
Introduction
When a US logistics enterprise asked us to migrate .NET application to Azure, the brief was simple to state and hard to execute. We needed to move a nine-year-old freight and order management platform off aging on-prem infrastructure without disrupting daily operations and deliver it in 16 weeks. The decision was not about running after a trend. For this client, it came down to three aspects.
First, the rising cost of staying on-prem, when traffic was growing, and the platform kept expanding, the on-prem setup got expensive to maintain.
Second, the application ran on .NET 8, which reaches the end of support on November 10, 2026. So migrating was the right decision to land on a current, supported runtime instead of carrying an aging one into the cloud.
Third, the client wanted room to scale, and the cloud makes that easy. It adds capacity when traffic rises and pulls it back when things slow down. Azure was the obvious pick here. The platform already ran on the Microsoft stack, and since Azure is part of the same family, it runs .NET apps more smoothly than AWS or GCP. That’s why most Microsoft-stack teams go with it.
This insight walks through the exact approach we used to migrate a nine-year-old freight and order management platform to Azure in 16 weeks, covering the assessment process, hosting decisions, migration execution, challenges encountered, and the outcomes achieved after deployment.
How We Executed .NET Azure Migration in 16 Weeks (Timeline)
While every migration timeline varies based on application complexity, this .NET Azure Migration project was completed over 16 weeks using a phased approach.
This phased approach allowed the logistics client to migrate their on-premises .NET app to Azure with minimal operational disruption while ensuring each migration stage was validated before moving to the next.
Migrate .NET Application to Azure: Planning and Readiness Before Migration
Many teams move directly into execution without fully understanding application dependencies, runtime limitations, and infrastructure requirements, and that’s where migration starts to fail. Here are the key areas we assessed before migrating the .NET application to Azure for our logistics client.
1. Dependency Mapping
When we checked for the dependencies of the on-premises .NET Logistics app, we discovered that a critical reporting module depended on a Windows service that wasn’t documented anywhere in the client’s architecture diagrams. If the application had been migrated without identifying that dependency, several business workflows would have failed immediately after deployment.
2. Runtime Compatibility Assessment
The app was on .NET 8. It runs fine on Azure, but support for .NET 8 ends in November 2026. We didn’t want to move it and then have to upgrade again a few months later, so we went straight to .NET 10, which is supported through 2028.
3. Workload Discovery and Rightsizing
After mapping the dependencies and checking for runtime compatibility, the next step for us was to discover and right-size the workload. We listed all the on-premises servers that need to move, mapping how they connect to each other, and estimating how much compute, memory, and storage each one uses under load.
We also look at the database migration scope and the existing security setup in the same phase, since both affect the target Azure design. If your team doesn’t have in-house Azure expertise to run this assessment, you can hire Azure developers from us to run it for you.
The Azure Hosting Model Options We Evaluated for .NET Application Deployment
The most important decision comes when selecting the right hosting environment when you are planning to migrate a .NET application to Azure. The hosting model directly affects overall scalability, operational complexity, performance, and long-term cloud costs. Here are the options we evaluated for our logistics client.
1. Azure App Service
Azure App Service is the common choice for ASP.NET Core web applications, REST APIs, and background services. It handles infrastructure management tasks such as OS patching, auto scaling, SSL termination, and deployment integration to migrate .NET applications to Azure without making any major architectural changes.
It works best for web applications, APIs, SMBs, mid-market workloads, and teams prioritizing faster deployment.
2. Azure Kubernetes Service (AKS)
Azure Kubernetes Service (AKS) is best designed for containerized and microservices-based applications that require complete advanced-level scaling, orchestration, and workload management.
This is best suited for microservices architecture, enterprise-scale workloads, multi-container environments, and teams that are already using Kubernetes.
If you are looking to implement microservices for your .NET app, you can refer to our blog on .NET microservices.
3. Azure Virtual Machines
Azure Virtual Machines are a practical choice for legacy enterprise applications with deep OS level dependencies, such as COM components or Windows Services that cannot easily be modernized. VMs are commonly used when organizations need to migrate .NET applications to Azure using a quick lift and shift approach with minimal code changes.
It’s a strong fit for Legacy .NET framework applications, Windows-dependent workloads, short-term migration timelines, and applications requiring full OS level control.
4. Azure Container Apps
Azure Container Apps provide a middle ground between App Services and AKS, allowing teams to perform containerized workloads without managing Kubernetes infrastructure directly.
It is an ideal pick for event-driven applications, background processors, scaling for zero workloads, and lightweight microservices.
After evaluating all four models, we ran the logistics platform’s web application, APIs, and background jobs on Azure App Service, and kept the reporting module on an Azure VM where its Windows service so dependency could run unchanged.
Not Sure Which Azure Hosting Model Fits Your .NET App?
Our Azure consulting services help you evaluate these options against your workload, dependencies, and timeline to help you make the right choice.
How Much Does It Cost to Migrate a .NET App to Azure?
Cost is one of the biggest reasons organizations delay cloud migration projects. Before companies look to migrate .NET applications to Azure, they want a realistic estimate of infrastructure costs, modernization, licensing, and long-term operational budget. The ranges below reflect what we’ve seen across the .NET-to-Azure migrations we’ve delivered.
| Migration Type | Typical Scope | Estimated Migration Cost | Key Cost Drivers |
|---|---|---|---|
| SMB Migration | 5–20 VMs, simple ASP.NET or .NET Core web apps, App Service deployments | $10,000 - $50,000 | Assessment, execution, testing, and cutover planning |
| Mid-Market Migration | 50–200 servers, mixed .NET Framework and .NET Core workloads | $80,000 - $280,000 | Dependency refactoring, database migration, and extended UAT cycles |
| Enterprise Migration | Legacy .NET Framework apps, custom Windows Services, SQL Server clusters | $250,000 - $750,000+ | Re-architecting, complex dependencies, HA/DR planning, and modernization effort |
Costs .NET Teams Often Overlook During Azure Migration
Even with a well-planned .NET Azure migration projects can run over budget when the hidden costs are not accounted for early. Here are some common overlooked costs that include:
- Data egress fees during database migration
- Third-party licensing upgrades for cloud deployment
- Refactoring .NET Framework-specific APIs
- Extended testing and UAT cycles for business-critical applications
Executing the .NET to Azure Migration: Step-by-Step Conduct
After assessing the freight and order management platform of our US logistics client and finalising the Azure architecture, we executed the .NET Azure Migration in a phased approach, over a 16-week timeline to minimize operational risk and maintain business continuity.
Step 1: CI/CD Pipeline Setup
We incorporated Azure DevOps for automated deployments, as manual deployments maximize the risk of failed releases and configuration drift. For most .NET workloads, dotnet publish artifacts can deploy directly to Azure App Service or container registries.
Step 2: Database Migration to Azure
We opted for Azure Database Migration Service (DMS) to move SQL Server workloads into Azure SQL Database. We migrated the schema first, validated the compatibility, and then performed data migration using constant sync and reducing downtime.
While validating the schema, we ran into database compatibility problems. Legacy stored procedures, SQL Server-specific features, and reporting jobs that relied on them all needed fixing before we could go live.
You can also refer to our blog on how to migrate SQL server to Azure SQL database, for a detailed walkthrough.
Step 3: Secrets and Configuration Management
Next, we moved connection strings, API keys, and credentials out of web.config or appsettings.json and into Azure Key Vault. And used managed identity to secure authentication between Azure services and the application.
Step 4: Phased Testing
App Service offers deployment slots, where a staging build runs on production-equivalent infrastructure and can be swapped to live with instant rollback. So we tested each release on a staging slot first, and only swapped it live once it checked out.
Step 5: Production Cutover and Validation
We ran the migration in phases, but the final cutover had to happen in one go. The app kept session data in memory, so the old and new systems couldn’t run side by side. We made the switch in a single low-traffic window, with the rollback slot standing by, and confirmed everything was running before calling it done.
Need Expert Help to Execute the .NET Azure migration for Your Application?
Hire .NET developers from Bacancy who have worked on similar .NET cloud migration projects before and can execute it alongside your team.
The Results: What Changed After Migrating the .NET Logistics Application to Azure
A .NET Azure migration proves its worth in the months after go-live, not on cutover day. The real impact becomes visible in the weeks and months that follow, when the application is handling production traffic, deployments are running through the new delivery pipeline, and operations teams are managing the environment day to day.
Here are the results recorded by the logistics client 90 days after their on-premises .NET App went live on Azure.
| Metric | Before (Legacy On-Prem) | After (.NET on Azure) |
|---|---|---|
| Monthly infrastructure cost | Fixed, capacity-bound spend | Lower, usage-based |
| Peak-season performance | Slowdowns under peak traffic | Autoscaled through peak traffic, no slowdowns |
| Deployment | Manual, periodic releases | Automated via CI/CD, on-demand |
| Release rollback | Slow and high-risk | Instant slot swap |
| Cutover downtime | Hours of planned outage | Single low-traffic window |
| Observability | Limited, reactive | Single low-traffic window |
| Runtime support | Aging .NET 8 Framework | Currently supported .NET 10 |
Note: Beyond the infrastructure improvements, the decision to migrate the .NET application to Azure modernized how the freight and order management platform is operated. Automated deployments, centralized monitoring, improved scalability, and a supported .NET runtime provided a stronger foundation for future enhancements and carrier integrations for the logistics client.
Conclusion
For this US logistics client, migrating the on-premises .NET platform to Azure was a strategic modernization initiative rather than a simple infrastructure move. The real challenge was executing the migration without disrupting critical freight and order management operations and addressing years of accumulated dependencies and technical debt.
A successful .NET Azure migration requires a defined approach that starts with readiness assessment, selecting the right Azure hosting model, forecasting infrastructure costs, and building monitoring and security into the environment from day one.
If your team is planning to migrate .NET application to Azure and needs end-to-end support from assessment to performance optimization post migration, we, as a leading .NET development company, can help you reach a stable Azure environment without the cost overruns and dependency surprises most migrations run into.
Frequently Asked Questions (FAQs)
The actual timeline to migrate .NET application to Azure depends on the application’s complexity, infrastructure size, legacy dependencies, and the level of modernization required. If you work on small ASP.NET or NET Core applications, it may take 2-6 weeks, mid-sized can take 2-4 months, and large enterprise migrations can take 6 months or longer.
Yes, organizations can easily migrate .NET applications to Azure with minimal or near-zero downtime when the migration is planned correctly. Azure services such as Azure Database Migration Service, Azure App Service Deployment, Azure Traffic Manager, and Azure Application Gateway help teams to validate the workload before production cutover and gradually shift live traffic into the Azure ecosystem.
We use a phased migration approach to run existing .NET applications alongside Azure-hosted workloads until the validation is complete, ensuring minimal downtime and business continuity.
Once organizations migrate .NET applications to Azure, the identity management generally shifts toward Microsoft Entra ID. The common approaches include Hybrid identity integration with on-premises Active Directory, Single Sign-On (SSO) implementation, Managed Identity for Azure services, and Azure Key Vault integration for secrets management.