Azure IaaS to PaaS migration — how and why to do it

You rented the servers to stop buying hardware. Now you patch, scale, and babysit them anyway. Moving to PaaS is the step where you finally put that work down — for the workloads that let you.

New to cloud? CAMPUX is a free, build-first course. Start here →

Moving from IaaS to PaaS means retiring the VMs you patch and babysit and rehosting the workload on a managed service — a web app onto App Service, a database onto Azure SQL, a scheduled job onto Functions. You trade some control for a lot less operational toil, and it pays off exactly when running your own servers stops earning its keep. That last clause is the whole decision. Most teams get the mechanics right and the judgment wrong: they move things that should have stayed, and keep things that were bleeding them dry.

I have run this migration on real estates — a fleet of IIS boxes, a SQL Server someone patched by hand every Patch Tuesday, a cron VM whose only job was to fire one script at midnight. Here is what the move is, when to make it, and the order that keeps you from taking production down while you do.

The case for moving off the VM

An IaaS virtual machine is a rented computer. Microsoft keeps the physical host alive; everything above the hypervisor is yours. That "everything" is a longer list than people remember when they spin one up:

• Patching. The OS, the runtime, the web server, the framework — all of it is your responsibility, on your schedule, with your downtime. Miss a cycle and the audit finds it. Miss the wrong one and an unpatched CVE finds it first.
• Scaling. A VM is a fixed box. Traffic doubles and you are resizing SKUs, building a scale set, and wiring a load balancer by hand. On PaaS, scale-out is a slider or an autoscale rule.
• The security surface. Every VM is an open SSH or RDP port waiting to be misconfigured, a set of OS accounts to manage, an agent to keep current. A managed service has no host for you to leave exposed, because you never touch the host.
• The cost of operations. This is the one that hides. The VM's monthly bill is visible; the engineer-hours spent keeping it healthy are not. Patch windows, capacity planning, the 3 a.m. page when the disk fills — that labour is real money, and it does not show up on the invoice.

PaaS takes that list off your plate. The provider owns the OS and everything under your app; you own the app and its data. You go back to operating the thing that makes you money instead of the machine it happens to run on. If IaaS and PaaS are still fuzzy, the IaaS vs PaaS vs SaaS class draws the line cleanly before you spend a cent moving anything.

The VM's bill is on the invoice. The hours you spend keeping it alive are not — and that's usually the bigger number.

The honest when-not-to

PaaS is not free of tradeoffs, and pretending it is will get you burned. You give up the host. That is the point, and also the problem — for some workloads the host is exactly what they need. Stay on IaaS when:

• The app needs a custom runtime or the host itself. A kernel-level agent, a specific OS build, an old .NET framework version App Service does not offer, software that insists on being installed on the machine — if the managed service can't host it, you either refactor the app or you keep the VM. Sometimes the refactor is the right call; sometimes it costs more than the VM ever will.
• There are legacy dependencies you can't unpick. Hard-coded local file paths, a Windows service the app shells out to, an in-process COM component, a driver. These are the threads that turn a "quick lift to App Service" into a three-month rewrite. Find them before you commit, not after.
• Licensing is tied to the machine. Some vendor licences are bound to a physical or virtual host, or priced per-core in a way a managed service breaks. Check the licence terms before the architecture diagram — I have seen a clean migration plan die on a single line of a software agreement.
• The workload is nearly retired. If the app is switching off in six months, you don't replatform it. You let it run out its life on the VM and spend the migration budget on something with a future.

Common IaaS component to PaaS target

Most estates are not one workload — they're a VM doing web, a VM doing database, a VM doing a nightly job. You migrate them piece by piece, and each piece has an obvious managed target. Here's the map I work from, with the honest cost of each swap.

The pattern repeats: you gain the operational load off your back, you give up host-level control and the freedom to do arbitrary things to the machine. For most business workloads that is a trade worth making. For the exceptions in the section above, it isn't. The skill is telling them apart — which is exactly the gap the cert leaves open.

The migration sequence

Do this in order. The failures I have seen all came from skipping a step — usually assessment, occasionally the decommission at the end, which is how you end up paying for a VM nobody uses for another year.

1. Assess. Inventory what runs on each VM — the runtime versions, the open ports, the scheduled jobs, the file paths, the licences. This is where you find the legacy dependency that decides whether a piece can move at all. Azure Migrate will discover and map dependencies for you; use it, but read the output like an engineer, not a dashboard.
2. Pick targets and pick winners. Map each component to its PaaS target from the table — then decide which ones are worth moving now. Start with the workload whose maintenance hurts most and whose dependencies are cleanest. Not everything makes the first cut, and that's correct.
3. Replatform one piece. Move a single component — say the web tier to App Service — into a non-production environment. Deploy it, point it at the existing database still on its VM, and prove it runs. One piece at a time keeps the blast radius small and the rollback simple.
4. Cut over. Migrate the data, run old and new side by side where you can, then move traffic — DNS, a deployment slot swap, or a gradual shift. Watch it under real load before you call it done. Keep the old VM running but idle so you can fall back in minutes.
5. Decommission. Once the new service has held under production load for long enough to trust, shut the VM down, then delete it and its disks. This is the step that captures the savings. A migration that leaves the old infrastructure running has spent money to make two systems where there was one.

What this costs

The instinct is that PaaS is more expensive because the per-hour rate can be higher than an equivalent VM. Sometimes it is, on the sticker. But the sticker is the wrong number. Subtract the patch windows, the overprovisioned standby capacity you bought so the VM wouldn't fall over at peak, and the incidents you personally own — and PaaS often comes out ahead on the total, even when it looks pricier per hour.

Model it with real figures before you assume either direction; prices change, so run your actual workload through the Azure pricing calculator rather than trusting a rule of thumb. The cost management and FinOps class shows how to put the operational hours back into the comparison, which is where the honest answer lives. And if you're still choosing between compute models in the first place, the Virtual Machines class covers when a VM is genuinely the right tool — because sometimes it is.

Common questions