Moving to the cloud is a project, not a button.

Many organisations own hundreds or thousands of servers, built up over many years by many different teams. Some run important business applications, some run forgotten test systems, and some nobody can explain. Moving all of this to the cloud raises hard questions. What do we actually have? Which servers depend on which? How large should each cloud machine be? What will it cost? In what order should things move? How do we copy a live server without switching off the business?

Azure Migrate is the central hub in Azure for answering these questions. It brings together tools to discover your existing environment, assess its readiness and cost for Azure, build a business case that compares staying put with moving, and migrate servers, databases, web applications and data. It supports workloads running on VMware, Hyper-V, physical servers and even virtual machines in other public clouds.

The hub idea matters. Instead of using a different product for each stage, you create a single project in Azure and use it to track the whole journey. Everything discovered, every assessment and every migration lives in one place, so teams can see progress and share results.

Migration versus modernisation

Moving a server as-is is often called lift and shift. It is the fastest route, because nothing about the application changes. But the cloud also offers managed services that remove a lot of operational work. Moving a database to a managed database service, or a website to a managed web hosting service, is called modernising. Azure Migrate helps with both, and its assessments can compare the options so you can choose what suits each workload.

Every successful migration follows the same arc, whatever the tools.

Cloud migrations that go well share a shape. They begin with understanding and end with improvement, and the move itself is only one stage in the middle. Azure Migrate is organised around this arc.

flowchart LR
  A["Discover: inventory servers, apps and dependencies"] --> B["Assess: readiness, sizing and cost"]
  B --> C["Business case: compare staying versus moving"]
  C --> D["Plan: landing zone and migration waves"]
  D --> E["Migrate: replicate, test and cut over"]
  E --> F["Optimise: right-size, secure and monitor"]
  F --> G["Decommission old systems"]
        

The strategy choices for each workload

Not every workload deserves the same treatment. A common way to think about it is a short list of strategies, sometimes called the “R” options. Choosing one per workload is a core planning task.

A small vocabulary unlocks every screen and every planning meeting.

Migration has its own jargon, and Azure Migrate adds some product-specific terms. Learn the following and the documentation becomes much easier to read.

What you deploy, what Azure runs and how they talk.

Azure Migrate has parts in the cloud and parts in your own environment. Understanding who runs what clarifies firewall requirements, permissions and troubleshooting.

The appliance in the middle

The appliance is the most visible component. It is a small virtual machine, downloaded from your project and deployed in your environment. It connects to your virtualisation platform with a read-only account, gathers configuration and performance data and sends it over a secure outbound connection to the project. It does not receive inbound connections from Azure, which keeps firewall rules simple.

flowchart LR
  subgraph OnPrem["Your environment"]
    H["Hypervisor or physical servers"]
    AP["Azure Migrate appliance"]
  end
  H -->|"Read-only inventory and performance data"| AP
  AP -->|"Outbound HTTPS"| P["Azure Migrate project"]
  P --> A["Assessments and business case"]
  P --> M["Migration tool"]
  AP -.->|"Replication data for agentless VMware"| S["Azure storage in your subscription"]
  S --> V["Azure virtual machines"]
        

Follow one virtual machine from your data centre to a running Azure copy.

The most common scenario is moving a VMware virtual machine using the agentless method, because it requires no software installed inside the server itself. The following sequence shows what happens.

sequenceDiagram
  participant VM as Source virtual machine
  participant App as Azure Migrate appliance
  participant Store as Azure storage
  participant Tool as Migration tool
  participant AzVM as Azure virtual machine
  App->>VM: Take snapshot and read disks
  App->>Store: Send initial copy of disks
  loop Until cutover
    App->>VM: Read changed blocks since last cycle
    App->>Store: Send only the changes
  end
  Tool->>AzVM: Test migration in isolated network
  AzVM-->>Tool: Validation result
  Tool->>VM: Planned cutover: shut down source
  App->>Store: Send final changes
  Tool->>AzVM: Create live Azure virtual machine from replicated disks
        

Spreadsheets of servers are almost always wrong.

Most organisations maintain an inventory of servers somewhere, and nearly all of those inventories are out of date. Machines get added and forgotten, ownership changes and nobody records how systems depend on each other. Automatic discovery replaces guesswork with data.

Three ways to feed the project

What gets collected

The assessment answers: will it work, how big should it be and what will it cost?

Once discovery has data, assessments turn it into decisions. You create an assessment by choosing a group of servers, a target type and a set of assumptions, and the tool calculates results for each server.

Types of assessment

What the results tell you

Settings that change the answer

Executives approve money, not appliances.

Technical teams can produce excellent assessments, yet a large migration still needs budget and approval from people who ask different questions. Is moving worth it? How much will we save? What happens to cash flow over several years? Azure Migrate’s business case capability is designed to answer these.

What a business case compares

Newer capabilities for planning at scale

Recent updates have focused on making large programmes easier to plan. Microsoft’s release notes describe features such as application-aware discovery that groups servers by roles and naming patterns into likely applications, planning of migration waves using discovery and assessment data, and reports that give executive-level summaries, security insights and business case insights. Several of these have appeared first as previews, so confirm which are generally available before building a plan around them.

A migration is only as smooth as the destination you prepared.

Moving a server to a poorly prepared Azure environment is like moving furniture into a house with no electricity. Before the first migration, you need a destination with the right foundations.

The landing zone

A landing zone is an Azure environment prepared to receive workloads. It includes network design with connectivity back to on-premises, identity and access arrangements, security controls, governance rules, monitoring and a sensible structure of subscriptions. Building it first means each migrated server arrives into a safe, consistent environment rather than a hurried improvisation.

Planning waves

A wave is a batch of workloads migrated together. Good waves are built from applications, not random servers, so that things that depend on each other move at the same time. Early waves are usually simple, low-risk workloads that let the team learn and build confidence. Complex and business-critical systems come later, when the process is proven.

flowchart TD
  A["Inventory and dependency maps"] --> B["Group servers into applications"]
  B --> C{"Strategy per application"}
  C -->|"Retire"| R["Decommission"]
  C -->|"Retain"| T["Leave on premises for now"]
  C -->|"Rehost or replatform"| W["Place in a wave"]
  W --> W1["Wave 1: simple and low risk"]
  W --> W2["Wave 2: moderate complexity"]
  W --> W3["Wave 3: critical and complex"]
  W1 --> L["Learn and refine the process"]
  L --> W2
  W2 --> W3
        

Different sources need different methods, but the stages are the same.

The Migration and modernization tool handles server replication and cutover. The method depends on where your servers run today.

Before you replicate

Reducing downtime

Because the source server stays online during replication, downtime is limited to the cutover window, often minutes to a couple of hours depending on the application and the amount of changed data. Applications that cannot tolerate even that, such as busy databases, may use their own replication technologies, such as built-in database replication, in combination with the migration plan.

Servers are only part of the estate.

An environment contains more than virtual machines. Databases, web applications, large file stores and virtual desktops each have their own migration paths, and Azure Migrate acts as the hub that points to the right tools.

A migration moves your most sensitive data. Protect it at every step.

During a migration, data is copied, stored temporarily and used to create new systems. Credentials are used, new network paths are opened and many people hold unusual access. Each of these deserves attention.

The migration is not finished at cutover.

Many programmes celebrate the cutover and forget the work after it. Yet the savings and benefits of cloud come from what happens next: tuning, protecting and cleaning up.

A migration programme needs a dashboard as much as an application does.

Replication runs for days or weeks, across hundreds of servers, and can stall for many small reasons. Without monitoring, a server may sit stuck while everyone believes it is ready. Good tracking happens at three levels.

Replication health

The migration tool shows the status of each server’s replication: initial copy progress, delta cycles, health warnings and errors. Common issues include a lack of storage space on the source, network interruptions, expired credentials or an unreachable appliance. Review replication health daily during active migration, and set alerts for servers that stop progressing.

Programme progress

Track how many servers or applications are discovered, assessed, replicating, tested and cut over. This gives programme managers a clear picture and allows early detection of slipping waves.

Post-migration health

Once servers run in Azure, normal monitoring takes over. Use Azure Monitor and application monitoring to compare performance and error rates before and after the move, and to detect problems introduced by the new environment.

The tools are often free; the cloud resources they create are not.

Azure Migrate’s discovery and assessment capabilities have been offered without a separate charge, and the migration tool has historically been free for a period of replication per server, with charges for the Azure resources used. Pricing details and free periods can change, and some related services have their own pricing, so check the official pricing and documentation pages for current terms.

Where costs actually appear

Ways to save

Doing it once is a project. Doing it a thousand times is a factory.

Moving ten servers can be done by hand. Moving two thousand needs a repeatable process, clear roles and automation. Mature programmes treat migration as an assembly line.

Organise the people

Automate the repeatable parts

Replication setup, tagging, naming and post-migration configuration can be scripted using command line tools, scripting modules and templates. Automating them reduces errors and lets small teams handle large waves. Documented runbooks, standard test checklists and clear communication templates make each wave faster than the last.

Shapes that work, and shortcuts that hurt later.

Patterns worth adopting

Anti-patterns to avoid

Habits that separate calm migrations from heroic ones.

Best practices

• Start with the business reason. Know whether the goal is closing a data centre, saving cost, gaining agility or meeting a deadline, because the goal shapes every decision.
• Collect enough performance history. Include your busiest periods so sizing reflects real peaks.
• Use dependency analysis. Keep tightly connected servers in the same wave.
• Prepare the landing zone. Networking, identity, governance and monitoring come first.
• Test migrations repeatedly. Rehearse cutover with runbooks and named roles.
• Plan the downtime. Agree windows with the business and communicate clearly and early.
• Keep a rollback route. Retain the source until validation is complete.
• Secure the process. Least-privilege access, hardened appliances and clean-up afterwards.
• Optimise after the move. Right-size, apply commitments and modernise gradually.
• Check official sources often. Features, previews and supported scenarios change frequently.

Common mistakes

How different organisations put the moving company to work.

The following scenarios are typical patterns rather than descriptions of specific companies. They show how the same capabilities combine for very different needs.

Quick answers to questions that come up again and again.

No. It is a hub covering discovery, assessment, business cases and migration of servers, and it points to companion tools for databases, web applications and data.

For VMware virtual machines the agentless method needs no software inside the servers, only the appliance. Agent-based methods, used for physical servers and other clouds, do install components.

No. It communicates outbound to Azure and connects to your own infrastructure with the accounts you provide, which keeps firewall requirements simple.

They are estimates based on discovered data and your assumptions, and they are useful for planning. Actual bills depend on usage, discounts and additional services.

Only during cutover, because the server stays online while data replicates. The window depends on the application and how much data changed, and is commonly minutes to a few hours.

A test migration starts a copy in an isolated network to prove it works, leaving the source untouched. A cutover is the real, final move that makes the Azure copy the live system.

Yes. Virtual machines in other clouds are treated like physical servers and moved using agent-based replication.

Azure Migrate assesses them and guides you to companion migration tools for managed database and web hosting services, in addition to moving the servers they run on.

If you need funding or approval, it helps greatly. It compares on-premises costs with Azure over several years and can model licence benefits and commitment discounts.

Not necessarily. Several newer capabilities, such as discovery through Azure Arc and some reporting and planning features, have been introduced as previews. Check the current status in the official documentation before depending on them.

Validate the workload, enable backup and monitoring, right-size resources, apply pricing commitments where sensible and decommission the old servers on a firm schedule.

Azure Migrate is the survey team, the planner and the moving crew for your journey to Azure. It discovers what you own, assesses readiness, size and cost, models the business case, plans waves, replicates and cuts over servers with little downtime, and points to the right tools for databases, web applications and data. Success depends less on the tool and more on the discipline around it: discover thoroughly, prepare a landing zone, move whole applications in sensible waves, rehearse every cutover, secure the process and optimise afterwards. Because the platform evolves quickly, with new discovery methods and planning features appearing, always confirm current capabilities and their maturity in the official documentation.