You have a massive .NET application sitting on a server somewhere. It runs your business. It also runs on Windows Server 2012, relies on IIS features nobody understands anymore, and causes a minor panic attack every time you need to patch the operating system.
You know you need to move to the cloud. You probably know you need to move to Microsoft Azure.
The real problem happens the minute you open the Azure portal. You are staring at a massive menu of computing options. Two services immediately jump out for running web applications. Azure App Service and Azure Kubernetes Service (AKS).
Making the wrong choice here will cost you six months of engineering time. I see companies burn through their entire IT budget trying to force older applications into the wrong hosting model.
If you want to skip the trial and error, your best move is to hire Azure developers who have done this specific migration a lot of times. Experience prevents unforced errors.
The Reality Of Dragging Older Code To The Cloud
Legacy .NET applications are usually built on .NET Framework 4.7 or 4.8. They are thick monoliths. They assume they own the entire server.
They write temporary files to the local C: drive. They rely on the Windows Global Assembly Cache. They use Windows Authentication to log users in seamlessly based on their Active Directory profile.
These assumptions break immediately in a cloud environment.
When you migrate a legacy system, you have to untangle those dependencies. You cannot just copy and paste the files to the cloud. You have to adapt the application to survive in an environment where servers are ephemeral.
Your choice of hosting platform dictates how much rewriting you actually have to do. Building Azure with .NET requires understanding the physical constraints of the platform you choose.
Azure App Service: The Path Of Least Resistance
Azure App Service is a Platform as a Service (PaaS). Microsoft manages the virtual machines, the operating system, and the IIS web server. You just provide the application code.
For 80% of legacy .NET applications, this is the correct choice.
App Service is designed specifically to host web applications. It understands .NET natively. You can take a standard ASP.NET Web Forms or MVC application, publish it directly from Visual Studio or Azure DevOps, and it will generally run.
You get automatic load balancing. You get automatic SSL certificate management. You can scale horizontally by dragging a slider in the portal.
I highly recommend App Service for internal business applications, CRM systems, and standard e-commerce sites.
It requires very little operational overhead. You do not need a dedicated DevOps engineer to keep an App Service plan running. Your existing C# developers can manage it.
The Pain Points Of App Service
App Service does have limits. The sandbox environment locks down certain operating system features.
If your application makes aggressive use of the Windows Registry, it will fail. If your application attempts to install custom COM components or run third-party MSI installers silently, App Service will block the execution.
You also have to rethink how you handle background tasks.
Older applications often have a Windows Service running alongside the web application to process emails, generate PDFs, or clean up the database. App Service does not support Windows Services. You have to extract that background logic and deploy it separately as an Azure WebJob or an Azure Function.
Handling File Storage And Dependencies
Local file storage is a massive trap during migrations.
Legacy applications love to save uploaded files directly to a folder inside the web application directory. When you move to App Service and scale out to three instances, those files only exist on the specific instance that handled the user's request. The next time the user loads the page, they might hit a different instance and see a broken image link.
You have to externalize your storage.
You will need to modify your application code to save files to Azure Blob Storage instead of the local disk. If rewriting the file I/O code is impossible due to missing source code or budget constraints, you have another option. You can mount Azure Files directly to the App Service. This maps a cloud file share as a local directory.
Choosing the right Azure storage option dictates how well your application scales under load. Blob storage is almost always the correct answer for web assets.
Azure Kubernetes Service: The Heavy Machinery
AKS is a managed container orchestration service. It is wildly popular. Every enterprise IT department wants to use it.
You probably do not need it for your 10-year-old monolithic application.
Kubernetes is built for microservices. It is built for applications composed of dozens of small, independent containers communicating over a network. It provides incredible control over networking, scaling, and resource allocation.
To run a legacy .NET Framework application on AKS, you have to use Windows Containers. Windows Containers are large. They are slow to start. The base image for a .NET Framework application can easily exceed several gigabytes. When AKS needs to spin up a new instance of your application to handle a traffic spike, it might take several minutes to pull the image and start the container.
When AKS Actually Makes Sense
I recommend AKS in very specific scenarios.
If your company is executing a massive modernization initiative where you are breaking the monolith down into smaller .NET 8 microservices over the next two years, AKS provides a solid foundation. You can run the legacy Windows Container alongside the new Linux-based microservices in the same cluster.
AKS also makes sense if you have extreme regulatory or networking requirements.
Some enterprise environments require custom network routing, specific outbound IP addresses, and aggressive network isolation. AKS gives you granular control over the virtual network. You control the ingress controllers. You control the service mesh.
You just have to pay for that control with complexity.
Managing AKS requires dedicated engineering time. You have to write YAML manifests. You have to manage container registries. You have to monitor the health of the nodes. Your application developers will need to learn Docker.
How To Choose Your Hosting Model
The decision comes down to your operational maturity and your ultimate goal for the application.
If the application is in maintenance mode and you just need to get it out of your on-premises data center, pick App Service. The migration will be faster. The hosting costs will be predictable. Your team will not have to learn a completely new deployment paradigm.
If the application is the core revenue driver for your business and you are actively re-architecting it for global scale, AKS is the correct target.
You also have to look at the broader technology context within your company. Organizations usually evaluate multiple cloud providers before a major migration. If you are comparing AWS Azure or GCP for enterprise workloads, Azure wins heavily on legacy .NET compatibility simply because App Service understands IIS natively. AWS Elastic Beanstalk and Google App Engine require much more wrestling to host older Windows workloads.
Let's look at the actual steps required to execute this move successfully.
Step 1: Fix The Configuration Drift
Your on-premises server has accumulated 10 years of manual configuration changes. Somebody tweaked a connection string in the web.config file directly on the production server in 2018. Nobody committed that change to source control.
The first step of any migration is auditing the physical server.
You have to pull the production configuration files and compare them against your repository. You have to identify every hardcoded IP address, every file path, and every external API endpoint.
You will need to replace these hardcoded values with environment variables. Both App Service and AKS allow you to inject configuration values at runtime. This allows you to deploy the exact same application binary to your staging environment and your production environment without recompiling the code. A structured Azure migration checklist helps you catch these dependencies before cutover day.
Step 2: The Authentication Problem
This is usually the hardest part of a legacy migration.
Internal applications rely heavily on Windows Authentication (NTLM or Kerberos). The application asks the local Active Directory server for the user's identity.
When you move the application to Azure, it loses access to that local domain controller.
You have to modernize the authentication flow. You will need to implement modern identity protocols like OpenID Connect or OAuth 2.0 using Microsoft Entra ID. This requires changing the authentication middleware in your .NET application.
If you absolutely cannot change the application code, you can use a feature called Azure AD Application Proxy to tunnel traffic back to your on-premises Active Directory. It adds latency and complexity. Rewriting the authentication code to use Entra ID is always the better long-term technical decision.
Step 3: Session State Management
Older ASP.NET applications often store user session data directly in the server's memory.
If a user logs in, their shopping cart or profile data lives in the RAM of that specific server. In a single-server environment, this works fine.
In Azure, this breaks immediately. Both App Service and AKS will route user traffic across multiple server instances to balance the load. If a user hits Instance A on their first click, and Instance B on their second click, Instance B has no idea who they are. Their session drops.
You have to externalize the session state.
The standard solution is deploying an Azure Cache for Redis instance. You update your web.config to use the Redis Session State Provider. The application will then read and write all session data to the centralized Redis cache. Every server instance accesses the same data pool.
Step 4: The Database Migration
The web application is only half the problem. You also have to move the SQL Server database.
Do not try to run SQL Server on a virtual machine unless you absolutely have to. You will end up managing backups, applying security patches, and configuring high availability groups manually.
Azure SQL Database is a fully managed database service. It handles backups automatically.
Legacy applications sometimes use deprecated SQL Server features like CLR assemblies, cross-database queries, or SQL Server Agent jobs. Azure SQL Database does not support these features.
If your application relies on those older capabilities, you must use Azure SQL Managed Instance. Managed Instance provides nearly 100% compatibility with on-premises SQL Server Enterprise edition while still providing automated backups and patching. It is more expensive than standard Azure SQL, but it prevents you from having to rewrite thousands of lines of stored procedures.
Tracking The Cloud Roadmap
The tools we use to manage these deployments change rapidly.
Microsoft releases new features for both App Service and AKS every month. We are seeing a massive push toward serverless container models like Azure Container Apps. Tracking every single Azure development trend is a full-time job.
You have to decide if you want your internal IT team focusing on tracking these cloud infrastructure updates or focusing on building features for your customers.
Building cloud infrastructure is a specialized skill. Writing Terraform scripts, securing virtual networks, and configuring Azure Key Vault takes deep platform knowledge.
Building The Team To Execute The Move
You cannot hand a legacy cloud migration to a junior developer.
A junior developer knows how to build a greenfield application using modern tutorials. They do not know how to untangle a monolithic Global Assembly Cache issue. They will spend three weeks trying to debug a cryptic IIS error code inside a Windows Container.
You need operators who have done this before.
Bringing in an experienced consultant for the initial architecture phase saves massive amounts of money down the line. They will tell you exactly which services to provision. They will write the deployment pipelines. They will structure the resource groups correctly from day one.
When you need that level of expertise, you should bring on a dedicated Azure developer. Having someone who understands both the older .NET Framework ecosystem and the modern Azure Resource Manager model is the only way to ensure the migration succeeds.
Start by auditing your current server environment. Catalog your dependencies. Then make the call between PaaS and containers based on your actual operational capacity.