Migration path
IIS to Azure App Service: Fit, Limits, and What Breaks
App Service is the cleanest exit from server maintenance — no operating system to patch and no end-of-support date to track. It is also deliberately not a general-purpose Windows server, and that is where migrations run into trouble.
Published July 29, 2026 · Last updated July 29, 2026
The trade you are making
App Service is a managed platform. Microsoft runs the operating system, patches it, and keeps it supported. You deploy an application and configure it; you do not administer a server.
That is the entire appeal. It ends the cycle where every few years an operating system reaches end of support and the whole thing has to be moved again. It also means giving up the things a general-purpose server lets you do, and legacy IIS applications frequently depend on several of them without anyone realising.
The migration is straightforward when the application is a conventional web application that happens to run on IIS. It is difficult when the application has grown into the server it lives on.
What genuinely does not work
These are the constraints that surface most often, roughly in order of how frequently they stop a migration.
COM and the GAC. You cannot register COM components, and you cannot install assemblies into the Global Assembly Cache. An application calling Server.CreateObject against a registered component, or depending on a library installed machine-wide, will not run. Assemblies that can be deployed alongside the application are fine; anything requiring machine-level registration is not.
MSI installers and machine-level configuration. There is no way to run an installer, modify the registry meaningfully, or install software onto the host. If the application depends on a third-party product installed on the server — a PDF engine, a reporting runtime, a licensing service — that dependency has to be replaced or the application needs a virtual machine.
The file system is not general-purpose storage. Applications get writable areas, but the local file system should be treated as ephemeral rather than durable. Legacy applications routinely write uploads, generated documents, caches, or logs to local paths and assume they persist and are shared across instances. On a multi-instance platform they are neither. This usually needs redirecting to blob storage.
Windows services and scheduled tasks. There is nowhere to install a Windows service or register a scheduled task. Background work moves to WebJobs, Azure Functions, or an external scheduler. Applications with a background processor quietly running alongside the website need that component rehomed.
Certificates in the machine store. Applications that load client certificates from the Windows certificate store for outbound authentication need reconfiguring, because that store is not directly available in the same way.
What maps across cleanly
The picture is more encouraging for standard IIS configuration, most of which has a direct equivalent.
| IIS feature | On App Service |
|---|---|
| Application pools | Each app runs in its own isolated context by default |
| URL Rewrite rules | Supported through web.config as normal |
| Custom domains and TLS | Managed by the platform, with free certificates available |
| Virtual directories | Configurable, with some structural limitations |
| Connection strings and app settings | Platform configuration, overriding web.config |
| Deployment | Git, ZIP deploy, or CI pipeline rather than manual file copy |
| Windows authentication | Replaced by Entra ID, not carried across directly |
The last row is the one that most often forces a decision. Applications relying on integrated Windows authentication against an on-premises Active Directory do not move to App Service unchanged; identity has to move to Entra ID, which is a project of its own and worth scoping separately.
How to tell before committing
The assessment is mostly a matter of asking specific questions about the existing server rather than the application, because the blockers are nearly always environmental.
Does anything get installed on this server that is not the website itself? Is there a scheduled task or Windows service running alongside it? Does the application write files anywhere and expect to read them back later? Does it instantiate COM objects? Does it authenticate users against Active Directory? Is there anything in the GAC? Are there registry keys the application depends on?
A no to all of those means App Service is very likely a clean fit. Two or three yes answers usually means either the application needs modest changes first, or a virtual machine is the more sensible target — which is a legitimate outcome rather than a failure. The comparison of App Service, virtual machines, and containers covers how to choose between them.
The honest position is that App Service is the best destination for applications that fit it, and forcing an application that does not fit is how migrations overrun. Establishing which one you have early is most of the value of the assessment. The manufacturing rehost case study is an example of an application that went to virtual machines rather than App Service, deliberately.
Frequently asked questions
Will classic ASP run on Azure App Service?
Yes, classic ASP is supported on Windows App Service plans. The complication is rarely the ASP itself and almost always the COM components a classic ASP site depends on, since App Service cannot register COM. A classic ASP site with no COM dependencies generally moves without difficulty.
Can I use App Service if my app needs a COM component?
Not if the component requires machine-level registration, which most do. The options are to replace the component with a library that can be deployed alongside the application, reimplement its functionality, or use a virtual machine or container instead. This is one of the most common reasons an application ends up on a VM rather than App Service.
What happens to my scheduled tasks and Windows services?
They need rehoming. App Service has no facility to install a Windows service or register a scheduled task. Background work typically moves to WebJobs, which run alongside the web application, or to Azure Functions for work that is genuinely independent. This is usually straightforward but it does need to be planned rather than discovered at cutover.
Does Windows authentication work on App Service?
Not against an on-premises Active Directory in the way it does on a domain-joined IIS server. Identity moves to Entra ID instead. For applications that rely on integrated Windows authentication this is a meaningful piece of work and should be scoped as its own workstream rather than assumed to carry across.
Wondering whether your site will run on App Service?
Thirty minutes, free, no obligation — bring your site address and whatever you know about the hosting.