Azure Migration: How to Move Without Breaking Things

Most failed Azure migrations don't fail technically. The servers move fine. They fail because the bill came in at twice the estimate, or because something nobody documented turned out to depend on the machine that moved. Both are preventable at the planning stage.

Before anything: decide what not to move

The best migration outcome is usually fewer servers, not the same servers somewhere else.

Lifting a virtual machine into Azure unchanged — "lift and shift" — is the fastest approach and frequently the most expensive long-term. You keep every operating system you were patching, every backup job, and every licensing cost, and you add a monthly bill on top. The savings in cloud migration come from eliminating things.

So the first pass is subtraction:

• File servers should generally become SharePoint and OneDrive rather than Azure VMs. Included in Microsoft 365, and the server disappears entirely.
• Anything with a SaaS equivalent your vendor already offers — ask before you migrate.
• Servers nobody could name a purpose for. There are almost always one or two.
• Print and utility servers that modern cloud services replace.

Whatever survives that pass is what you're actually migrating, and it's usually a much shorter list. We cover the cost reasoning in when Azure migration makes sense.

Assess properly — the step that prevents surprises

Azure Migrate is free and will discover your environment, measure actual resource usage, and estimate costs. Run it for at least two weeks before sizing anything, because sizing from what the hardware has rather than what the workload uses is the number one cause of Azure bills coming in high. A server with 32GB of RAM using 6GB does not need a 32GB VM.

Alongside the automated discovery, map dependencies by hand. The failure mode here is specific and common: you migrate an application server, and a scheduled task on a different machine that nobody documented was writing to it every night. Nothing errors visibly. You find out at month-end.

For each system, write down what talks to it, what it talks to, which scheduled jobs touch it, and who would notice within an hour if it stopped.

Get the foundations right first

Build the landing zone before you move a single workload. Retrofitting these is painful:

• Naming and tagging standards. Every resource tagged with owner, project, and environment. This is what prevents orphaned resources billing forever — see Azure cost optimization.
• Network design. Address ranges that don't collide with your office network, and segmentation so a compromise in one area can't reach everything.
• Identity. Entra ID configured, MFA enforced, role-based access defined. Cloud resources are reachable from anywhere, so identity is the entire perimeter.
• Budgets and alerts configured from day one, so cost surprises arrive as notifications rather than invoices.
• Backup strategy defined before migration, not after.

Sequence the migration by risk

Move things in an order that lets you learn cheaply.

1. Backup first. Send backups to Azure before migrating anything. Low risk, immediate benefit, and it teaches you how Azure billing behaves with real data.
2. Then test and development environments. Genuine workloads, no consequences if something goes wrong.
3. Then low-criticality production. Something real, but survivable if it's down for a few hours.
4. Then the important systems, one at a time, never two in the same weekend.
5. Retire the old infrastructure last, after a stability period — but do actually retire it, or you'll pay for both indefinitely.

Plan the cutover in detail

For each migration, write down before the day:

• The rollback plan and its deadline. "If we're not working by 6am Sunday, we revert." Decide the cutoff in advance, because at 5am nobody wants to admit defeat and that's how a weekend outage becomes a Monday outage.
• What DNS changes are needed and their TTLs. Lower TTLs a day or two ahead so changes propagate quickly.
• How you'll verify success — a specific checklist of things to test, not "it looks up."
• Who's available, and who tells staff what's happening.
• How much data has to move and how long that takes. Large data transfers over a business internet connection routinely take far longer than assumed. Measure with a real test.

The 60-day follow-up that pays for itself

Migration isn't finished at cutover. Two months later, with real usage data, do a right-sizing pass. Initial sizing is always a guess and almost always generous — dropping a VM one size typically halves its cost.

At the same time, apply reserved instances to anything that's clearly steady-state. A workload that ran continuously for two months will run continuously for the next year, and committing cuts 40–60% off the rate. And check for Azure Hybrid Benefit eligibility if you own Windows Server licenses with Software Assurance — it's a checkbox worth roughly 40% on Windows VMs.

Businesses that skip this step pay significantly more than they need to, indefinitely.

Mistakes worth avoiding

• Sizing from hardware specs instead of usage. The most expensive mistake there is.
• Migrating everything at once because it seems efficient. When something breaks you won't know which change caused it.
• Forgetting egress costs. Data into Azure is free; data out is billed. Applications that move large volumes outward can be expensive in ways the estimate missed.
• Assuming cloud means backed up. It doesn't. You still need backup with real retention.
• Not checking vendor support. Some line-of-business vendors won't support their application in Azure. Ask in writing before planning.
• Leaving the old environment running. Set a decommission date and hold it.