Azure Migrate - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Azure migrate is free and it will tell you what your own servers are really costing you. That sounds simple, but the hard part of a migration usually happens before anyone opens the cloud portal because nobody mapped what was connected to what. It's the Microsoft service that discovers your workloads, checks whether they're ready, estimates what they'll cost, and then runs the move. Welcome to the M365 FM podcast, where we explore the people, ideas, and technologies shaping the future of work. And you don't do it all at once because it works in waves. What Azure Migrate actually is start with the plain version, because the name makes it sound like a single button. You press.

0:40 Azure migrate is a free service from Microsoft that helps you decide on plan and run a move to Azure. It looks at what you're running today and tells you whether any of it is ready for the cloud. It works out roughly what the move will cost, and then helps you carry it out with as little downtime and risk as possible. That last part matters more than it sounds. A migration is more than a copy job, because the things you're moving are still serving real people while you move them. So the range of things it handles is wider than you'd guess. Microsoft built it for servers, databases, web apps, virtual desktops, and large offline data moves. It handles the biggest of those with a product called Azure Data Box. A server here just means a computer that runs something on premises just means the machines sitting in your own building or your own rented space, rather than in a Microsoft data center.

1:21 The Azure Migrate service itself is free to use. You still pay for the Azure resources. You end up running because you're renting computers in the cloud. A few third party tools that plug into it charge their own fees. But the discovery, the assessment, and the planning, the stuff that actually stops you making an expensive mistake costs nothing. It helps to say who this is for too, because the name can sound like software built only for giant companies. The same service that helps a large business plan. A data center exit also helps a small team move a handful of servers. The work of figuring out what you have doesn't really change with size. Everything happens in one place, which Microsoft calls the Azure Migrate Hub. Think of it as a single front door, so you're not juggling five different products to get one job done, and the whole journey fits into three phases decide, plan and execute.

2:05 You decide by discovering what you have. You plan by assessing readiness, size and cost, and then you execute, which is the actual move. How discovery works. The journey starts with a question that catches almost everyone off guard, and the question is simply what you actually have. Most teams believe they know their own environment. Then they run a discovery and find servers. Nobody can name running things nobody remembers building. That's not a failure of the team, because environments grow quietly over years, and the people who set them up often moved on. Discovery is simply the step that replaces memory with real data. So you're planning from facts instead of a guess. Microsoft's recommended way to do it is with the Azure Migrate Appliance. An appliance sounds technical, but it's really just a small virtual machine. You spin up inside your own data center.

2:45 It collects two things what each server is configured like and how hard each server is working. It sends that information back to Azure on its own, and it keeps updating so your view stays current as things change. You don't have to use the appliance for everything. If your network is locked down and can't reach the internet, there's the Azure Migrate Connector, which takes a quick one time snapshot instead of a continuous feed. If you already keep a tidy list of your machines, you can just import that list from a spreadsheet and skip the scanning altogether. The scale is bigger than you might expect to. A single appliance can deliver up to ten thousand servers across ten vCenter servers, or five thousand servers across three hundred Hyper-V hosts, or one thousand physical servers. Those names describe different ways of running virtual machines, and you don't need to master them.

3:25 The idea is simple because one small helper can take inventory of a whole data center. Behind the scenes, that appliance is doing something patient. It records what each machine is made of, meaning its processor, memory, and disks. It also watches how busy those parts get over time. So the record covers what you own and how hard it's working. Each appliance registers with a single project, which keeps the reporting tidy, and a project can hold several of them, so a sprawling estate isn't a problem. The assessment readiness sizing cost once you know what you have, the next question is the one that keeps finance teams awake. Whether any of this is ready for the cloud and what it will cost. That's what an assessment answers, and it works through three questions in a strict order. First, it decides whether the workload is ready for Azure.

4:06 Second, it works out what size it should be. Third, it estimates what it will cost each month. The order matters because if something fails the readiness check, it's marked unsuitable and it never gets a size or a price at all. There's no point costing a machine that can't move yet. Those assessments come in a few flavors depending on what you're moving. There's one for plain servers, one for SQL databases, one for web apps, and one for teams weighing a VMware specific path. There's no need to memorize them because the tool picks the right kind once it knows what you've got. What matters is the habit it encourages, which is assess first and move second. Sizing is where a lot of beginners get caught because there are two ways to do it. The first is as is sizing, which copies your current setup straight across. It sounds safe, but it copies your waste as well. So if your server has been running at a fraction of its capacity for years, you keep paying for all of it.

4:50 The second is performance based sizing, which looks at how much the machine actually uses. Microsoft recommends this one because it stops you paying for capacity you'll never touch. The mechanics are more careful than you'd expect. The appliance samples each server's performance at fine intervals. It checks every 20s on VMware, every 30s on Hyper-V, and every five minutes on physical servers. It rolls those samples into data points and keeps a month of them, then sorts them and picks a value to size against. Choose the ninety fifth percentile and you ignore the odd spike. Choose the ninety ninth and you keep it in. On top of that sits something called the comfort factor, which is just a buffer for the real world. Say a server has ten calls but only ever uses twenty percent of them on paper. Two calls would do the job, add a comfort factor of two, and you get four cores instead, which leaves room for a busy month or a bit of future growth.

5:36 That single number is often the line between a cloud bill you can defend and one you can't. Then comes cost. The assessment lets you say whether you're paying standard pay as you go prices or a negotiated agreement. It folds in things like one year or three year reservations and a scheme called Azure Hybrid Benefit, which lets you reuse licenses you already own instead of buying them again. There's also a broader view called a business case. It compares the full cost of running things on premises against running them in Azure. Year by year, and shows how you shift from paying for hardware upfront to paying monthly for what you use. One more thing about assessments, and it's easy to miss an assessment is a snapshot of a single moment, and it can go stale almost immediately. That's why you rerun it as you go.

6:17 Instead of framing the first report and treating it as gospel, knowing the price of each server is only half the story, though servers rarely live alone. And that simple fact is where more migrations go wrong than anywhere else. Dependency analysis. Sizing one server is straightforward. The trap is that servers are almost never really alone. Picture a web server that handles logins for a whole department. You assess it. It's ready. The size is right. The price is fine, so you move it to Azure over a weekend. Monday morning, nobody can log in because that web server depended on an authentication server you left sitting on premises. Nothing was broken in the technical sense because you just moved one half of a pair. Dependency analysis exists to stop exactly that. It watches which servers are talking to each other.

6:57 That lets you see which ones belong together, so you can move them as a set instead of splitting them up by accident. Microsoft's recommended version is called Agentless Dependency Analysis, which is a mouthful for a simple idea. It needs no software installed on the servers at all. It just observes the network connections going in and out every five minutes or so and turns them into a map. Those connections get grouped into applications, so instead of a wall of machine names, you see the shape of how your systems lean on each other. What you get back is a map of your environment as it really works with servers grouped into applications, and the ones that must travel together clearly flagged. The payoff doesn't show up on any chart, but it's huge because you avoid the surprise outage that nobody predicted, and you stop finding out about a hidden connection the hard way at the worst possible moment with everyone watching.

7:42 Agentless or agent based. By this point, you know what's in your environment, what it will cost, and what has to move together. The next decision is how to copy a server. And again, there are two routes. The first is Agentless. Agentless means nothing gets installed inside the server. You're moving for VMware, the same appliance you used for discovery also handles the copy. It uses something called a snapshot, which is a quick point in time picture of the machine, plus change tracking that copies only the parts that changed. For Hyper-V, the work happens on the host, which is the physical machine running your virtual machines. It's Microsoft's recommended method for most VMware and Hyper-V cases, precisely because you don't have to touch the servers themselves. The second route is agent based. Here, a small piece of software called an agent gets installed once inside each server, alongside a separate replication appliance that handles the transfer.

8:29 It's a bit more work, but it reaches places Agentless can't. That's why it shows up so often in mixed environments where old physical servers sit next to newer virtual ones. There are four cases where you need it instead. The first is when agentless prerequisites aren't met, which means snapshots or change tracking aren't available or access is locked down. The second is when the server runs an operating system that Agentless can't prepare for the cloud. The third is when it has an unusual disk or boot setup. And the fourth and simplest is when the server isn't running on VMware or Hyper-V at all, which covers physical machines and servers hosted with other cloud providers. The way to think about the trade is this Agentless is the simpler hands off option, and it fits the common case.

9:09 Agent based is the one that reaches everything else. It hands you finer control per machine at the cost of installing and looking after an agent on every server you move. Neither is the wrong answer, and the choice comes down to what you're actually running. Moving in waves. Now we get to the part that turns a scary project into a manageable one, and it's called the wave. A wave is just a group of applications and workloads that you migrate together instead of trying to move everything in one tense weekend. You split the estate into batches. You move one batch, learn from it, and carry those lessons into the next. Microsoft's guidance is clear that moving in waves beats trying to plan everything perfectly upfront. Each wave teaches you something. The plan couldn't take a first wave. That's just a test environment and a second. That's one department's internal app.

9:50 Neither one can take the business down if something goes sideways. So both are safe places to make your mistakes early while they're still cheap. Planning a wave comes down to three moves. First, you group things that share dependencies or business needs. So connected pieces travel together. Second, you sequence the waves, which means deciding what goes early and what goes late. That comes down to how critical each thing is and how complex it is. Third, you run independent waves side by side when it's safe, so the whole program moves faster without adding risk. The sequencing advice matters more than it looks, because it's the difference between a calm migration and a chaotic one. Get the order wrong and the mistake shows up in production on a system real people depend on. Start with the simpler, lower risk workloads so your team builds confidence before anything important is on the line.

10:34 Move your development and test environments before production because they give you a safe place to rehearse the real thing. Schedule your most critical systems for later. Once you've proven the process, drop one or two properly complex workloads into the early waves so the hard problem surface while the stakes are still low. And if you'd rather not build the plan by hand, Azure you migrate can suggest the waves for you. It pulls together your inventory, your dependencies, and your assessment data, then scores each workload from zero to one hundred for migration priority. You get back a recommended sequence with a confidence level and a risk note attached. You still make the final call, but you are not starting from a blank page. The hub and its tools. All of this lives in one place, and that's the point to hold on to. The Azure Migrate Hub is a single portal where you start, run, and track the entire journey from the first discovery scan to the final move.

11:20 Underneath it, a small set of tools does the specific jobs discovery and assessment handles the scanning and the reports you've just heard about migrate and modernize. Does the actual copying of servers for databases, there's the Data Migration Assistant and the Azure Database Migration Service for web apps. There's the App Service Migration Assistant, and for very large data moves where the internet would be too slow. Azure Data Box ships your data physically. The tools line up neatly with the phases you've already met. Discovery and assessment covers the decide and plan stages and migrate and modernize covers execute. Which is why the whole thing feels less like a crowded toolbox and more like a guided path. You're also not locked into Microsoft's tools alone. A set of partner tools from companies like Carbonite Cloud, amaze, Corinth, and Zerto plugs into the same hub so you can mix and match what fits your situation.

12:05 The single front door is the whole idea. A migration is hard enough without also having to learn five unrelated products to get through it. So when you open the hub for the first time, you're looking at the entire migration in one screen, not a maze. The pitfalls to avoid. Now that you've seen how the journey is meant to go, it's useful to name the places where it usually goes wrong because a smooth migration and a painful one usually come down to a short list of mistakes. Start with migrating blind, which means skipping discovery and assessment and jumping straight to moving things. It's tempting because planning feels slow, but it's also how you end up surprised by costs and breakage you could have seen coming. The whole point of the service is to look before you leap. Then there's. As is sizing, the one that pays for capacity you never use.

12:45 If your servers have been oversized for years, copying them as they are copies. The overspend to Performance based sizing is the fix and it's a few clicks, not a project. Missing dependencies is another common one, and it's how you move half of an application and break the other half. Dependency analysis handles it, and it's the single most underrated step for anyone doing this for the first time. Assuming Agentless always works trips people up as well. It depends on snapshots and change tracking being available on a guest operating system. The service can prepare and on access that isn't locked down. When any of that isn't true, agent based isn't a downgrade, it's just the right tool. Treating an assessment like a final answer is a subtle mistake. An assessment only tells you the truth for the moment it was created, and it changes as your environment changes and as more performance data flows in, refresh it as things move.

13:31 Rather than treating last month's report as permanent, trying to do everything at once is a big one. Big bang migrations raise the risk and they throw away the learning that waves give you for free. That learning is the safety net that makes the whole approach work. Ignoring the money model underneath all of it is another. And that means the move from owning your hardware to renting what you use along with the savings you can unlock through license, reuse and renovations. The last trap is assuming the tool does the thinking for you as your migrate hands you numbers, maps, and recommendations, but the judgment calls like what to move first and what to leave where it is still belong to your team. The service sharpens the decision and it doesn't make it for you. None of these are exotic. They're the ordinary ways migrations stumble, and each one has a plain fix that the service already gives you the recap.

14:14 So let's bring it together. Azure migrate is the free Microsoft service that guides you through a migration in three phases. It discovers what you actually have, assesses what's ready and what it will cost. Maps the dependencies that decide what has to move together, lets you choose between agentless and agent based copying, and then helps you move everything in waves instead of one risky night. The one thing to carry out of all this is that a migration is a plan, and the plan starts long before the move itself. That's why the free part, the discovering and the assessing is the part you shouldn't skip. Before you go sit with one question. If you looked at your own environment tomorrow, how much of it could you honestly say, you know, inside and out?