Azure App Service vs VM vs Containers for Legacy IIS

The axis that actually matters

These three options are usually compared on price, which is the least useful axis. The one that matters is how much of the operating system stays your problem, because that is what determines whether you are having this same conversation again in four years.

On a virtual machine, all of it is yours. You patch the operating system, manage the certificates, handle the backups, and track the next end-of-support date. On App Service, none of it is — Microsoft patches the platform and keeps it current. Containers sit in between, and where exactly depends on the base image you choose.

Everything else follows from that. Cost differences are real but usually smaller than the difference in ongoing operational effort, and they point the same direction anyway.

The three side by side

	App Service	Virtual machine	Containers
OS patching	Microsoft	You	You, via the base image
Future EOL deadlines	None to track	Yours to track	Base image lifecycle
Install arbitrary software	No	Yes	Yes, in the image
COM registration	No	Yes	Yes
Windows services	No, use WebJobs	Yes	Possible, awkward
Migration effort	Low to medium	Lowest	Highest
Ongoing effort	Lowest	Highest	Medium
Scaling	Built in	Manual	Built in with orchestration

The row worth dwelling on is the contrast between migration effort and ongoing effort. Virtual machines are the easiest destination to reach and the most expensive to live with. App Service is the reverse. Choosing on migration effort alone is how organisations end up rehosting the same application repeatedly.

When each one is right

App Service is the default worth trying to reach. If the application is a conventional web application with no machine-level dependencies, it removes server maintenance permanently and ends the end-of-support cycle. The article on what breaks covers how to establish whether the application qualifies before committing.

A virtual machine is right when the application has dependencies that cannot be removed within a sensible budget — registered COM components, installed third-party products, Windows services, or authentication tied to on-premises Active Directory. It is also right when the priority is speed, because a lift-and-shift onto a VM is the fastest way off failing hardware or a past-deadline operating system. Extended Security Updates come free with Azure-hosted workloads, which makes this route more attractive than it first appears when a deadline has already passed.

Containers earn their place in a narrower band than the current enthusiasm suggests. They make sense when the application genuinely needs machine-level dependencies packaged with it, when there are several related applications to run with consistent deployment, or when there is already container expertise and tooling in place. For a single legacy IIS website with no existing container practice, they usually add operational complexity without a proportionate benefit — the base image still has a lifecycle, so the patching problem is reduced rather than removed.

The staged approach

These are not mutually exclusive, and treating them as a single irreversible decision makes the choice harder than it needs to be.

A common and sensible sequence is to lift onto a virtual machine first, which removes the hardware risk and any support deadline quickly and with minimal application change, then move to App Service later once the dependencies that blocked it have been dealt with. The first step is fast and low-risk; the second happens on a timeline you control, without a deadline forcing it.

The argument against is that the second step often does not happen once the pressure is off, and the organisation is left paying to maintain a virtual machine indefinitely. That is a real risk and worth naming honestly. It is a good approach when the intermediate step is a deliberate decision with a follow-up scheduled, and a poor one when it is a way of avoiding the harder assessment.

Which shape fits is exactly what the rehost, rebuild, or replace decision is meant to surface, and the case studies show all three playing out on real projects.

Frequently asked questions

Which is cheapest for a small business website?

App Service is usually cheapest in total cost, though not always in monthly hosting fees, because the ongoing operational effort of a virtual machine — patching, backups, certificate renewals, and eventually another migration — is a real cost even when it is not itemised. Comparing monthly hosting alone tends to favour virtual machines and tends to be misleading.

Do containers solve the end-of-support problem?

Only partly. The container base image has its own lifecycle and needs updating, so the patching obligation is reduced rather than eliminated. Containers solve dependency packaging and deployment consistency well; they are not a route to never thinking about operating system support again. App Service is the option that genuinely removes that concern.

Can I move to a VM now and App Service later?

Yes, and it is a reasonable sequence when a deadline is pressing. Lifting onto a virtual machine is fast and requires little application change, which buys time to address the dependencies blocking App Service. The honest caveat is that the second step frequently gets deferred indefinitely once the urgency passes, so it works best when scheduled deliberately rather than left as an intention.

What if my application needs Windows authentication?

That points towards a virtual machine, at least initially. Integrated Windows authentication against an on-premises Active Directory does not carry across to App Service, where identity moves to Entra ID instead. Moving identity is a substantial piece of work in its own right, and it is usually better sequenced separately from the hosting migration rather than combined with it.