Start with the big picture: what the service does, who uses it, and the three jobs it performs.

Azure Migrate is a service inside Microsoft Azure that gives you one central place to discover, assess, and migrate your existing computer systems to Azure. The word migrate simply means to move from one place to another. In computing, a migration is the project of moving systems, data, and applications from one environment to another, for example from your own data center to the cloud. A data center is a building, or a room, full of servers, storage, and network equipment. When the servers belong to you and sit in your own building, we call this on-premises, often shortened to on-prem.

The three jobs of Azure Migrate match the three steps of any careful move. Discovery means finding out what you actually have: how many servers, how big they are, what software runs on them, and how busy they are. Assessment means checking what would happen if you moved each item to Azure: will it work there, how large a machine will it need, and how much will it cost each month. Migration means actually copying the systems to Azure and switching over to the copies. Azure Migrate provides tools for all three, plus a central dashboard that shows the progress of the whole project.

The service handles several kinds of things. It can move servers, which are computers that run applications, whether they are virtual machines (software-made computers that share one physical machine) or real physical machines. It can move databases, such as SQL Server and others. It can move web applications, the websites and online services your customers use. It can move virtual desktops, the remote Windows desktops that staff log in to. And it can move large amounts of raw data using shipped storage devices. For each kind, Azure Migrate either contains a tool or connects to a partner tool, so you can follow one project from start to end without juggling many unrelated products.

Where the service came from

Azure Migrate began as a simple tool that assessed virtual machines running on VMware, a popular software for making virtual machines. Over the years Microsoft expanded it into a full hub. It now brings together tools that were once separate products, including tools for server replication (copying), database migration, and web app migration, and it also lets partner companies plug in their own tools. Microsoft also describes Azure Migrate as part of a bigger guide called the Cloud Adoption Framework, a set of advice on how to plan and run a move to the cloud. Product names and screens change from time to time, so check Microsoft’s current documentation when you start a project.

Moving to the cloud sounds easy on a slide. In real life, it fails for very ordinary reasons.

The cloud means renting computing power, storage, and services over the internet from a provider like Microsoft instead of buying and running your own equipment. Companies move to the cloud for many reasons: their old hardware is reaching end of life, their data center lease is ending, they want to grow faster, or they want to save the cost of running buildings full of machines. But the move itself is where projects often go wrong. Four problems appear again and again.

Azure Migrate addresses each one. Discovery builds a trustworthy list from the real machines instead of from memory. Dependency analysis draws the hidden connections. Assessments recommend sizes based on how busy each machine really is, and estimate the monthly cost. Continuous replication keeps the copy almost up to date while the old system runs, so the final switch-over takes minutes rather than days.

There is also a human problem: scale. A company with five servers can plan on a whiteboard. A company with five thousand servers, hundreds of applications, and many teams cannot. It needs groups, waves, reports, and a shared view that managers can read. Azure Migrate gives that shared view so that everyone, from the engineer to the finance team, looks at the same numbers.

Before opening any tool, decide how each system should move. The tool follows the strategy, never the other way around.

Not every system should be moved in the same way. Cloud experts talk about a handful of migration strategies, often called the “Rs”. Microsoft’s Cloud Adoption Framework describes them, and different books count five or six or seven of them, but the core idea is the same: choose how much to change a system while moving it.

Azure Migrate is strongest for rehost and replatform moves, which are the most common first step. Its server migration tool copies a machine exactly. Its database and web app tools help you replatform onto managed services. For refactor and rearchitect work, Azure Migrate still helps with discovery and assessment, but the redesign itself is done by your developers, perhaps with the help of other tools.

The journey in phases

A cloud migration generally moves through phases. Microsoft’s guidance names them differently in various documents, but the shape is stable: strategy and planning (why are we moving and what will success look like), readiness (build the place in Azure where systems will land), discover and assess, migrate, and finally optimize and govern (tune the cost and keep everything under control after the move). Azure Migrate mostly lives in the middle three phases.

flowchart LR
    S["Strategy and planning"] --> R["Readiness - landing zone"]
    R --> D["Discover"]
    D --> A["Assess"]
    A --> M["Migrate in waves"]
    M --> O["Optimize and govern"]
    O -.->|"learn and repeat"| D
    

Learn these words once and the rest of the guide reads easily.

Azure Migrate is not one program. It is a hub with tools attached, and some parts live in Azure while others live in your own environment.

The center of the system is the Azure Migrate project, which lives in an Azure subscription and a chosen geography. A subscription is the billing and access container for Azure resources, and a geography is a region of the world, such as Europe or India, where project data is stored. Choosing the geography matters because the metadata about your servers is kept there, and some organizations have laws about where information may be stored.

On the left side of the picture, in your own environment, sit the things being moved and the helper that watches them. The helper is the Azure Migrate appliance. It connects to your virtualization system, such as VMware vCenter or Microsoft Hyper-V, or to individual physical servers, and reads configuration and performance information. It sends that information securely to the Azure Migrate project. A second helper, called a replication appliance in some scenarios, may be used to copy data to Azure when the copy method requires it.

On the right side, inside Azure, the project holds the tools. Discovery and assessment reads the data from the appliance and creates assessment reports. Migration and modernization manages replication of servers into Azure storage and creates the final virtual machines. Database Migration helps move databases to Azure database services. Web app migration helps move websites to Azure App Service. Further tools cover virtual desktops and bulk data. Partner tools from other companies can also register in the same project.

flowchart LR
    subgraph ONPREM["Your environment"]
        VM["VMware, Hyper-V, physical servers, other clouds"]
        APP["Azure Migrate appliance"]
        REP["Replication appliance or provider"]
    end
    subgraph AZURE["Azure"]
        PRJ["Azure Migrate project"]
        ASM["Discovery and assessment"]
        MIG["Server migration"]
        DBM["Database migration"]
        WEB["Web app migration"]
        LZ["Landing zone - network, storage, security"]
    end
    VM --> APP
    APP -->|"inventory and performance data"| PRJ
    PRJ --> ASM
    PRJ --> MIG
    PRJ --> DBM
    PRJ --> WEB
    VM --> REP
    REP -->|"replicated data"| MIG
    MIG --> LZ
    

The picture reads from left to right. The appliance observes and reports. The project stores and organizes. The tools inside the project turn information into reports and actions. Finally, replicated machines arrive in the landing zone, where the network and rules are already prepared for them. Notice that the appliance sends information about your servers, while the replication path sends the actual data of your servers. These are two separate paths and have different security and network needs.

Two things come first in any real project: create the project, and install the appliance.

Creating a project is simple. In the Azure portal, a web page where you manage Azure, you open Azure Migrate, choose a subscription and resource group, name the project, and select a geography. A resource group is a folder-like container that keeps related Azure items together. The project is then ready, and you choose which tools to add. A single project can serve many teams, but large companies often create more than one, for example one per business unit or one per region, so that access and reporting stay tidy.

The Azure Migrate appliance is a small virtual machine. For VMware and Hyper-V environments, you download a ready-made image from the portal and import it into your virtualization system. For physical servers and servers in other clouds, you run an installer on a Windows or Linux machine. The appliance asks you to connect it to your project using a key produced by the portal, and then to give it read-only credentials for your virtualization system so it can list machines and measure performance. Read-only means it can look but never change anything, which keeps the risk low. The appliance then discovers machines, and starts to collect performance numbers about once every few seconds, sending summaries to Azure.

The appliance is designed to be small and safe. It only makes outgoing connections to Azure over the secure web protocol, HTTPS, so you normally do not need to open any incoming ports from the internet. Organizations with strict network rules can also use private endpoints, which let the traffic travel through a private connection, such as ExpressRoute or a VPN, rather than the public internet. The appliance has its own local web page for configuration, where you can check connection status, add credentials, and see what has been discovered.

Discovery turns a vague feeling of “we have a lot of servers” into a precise, trusted list.

Once the appliance is connected, discovery begins. For each machine, the appliance gathers configuration data: the name, operating system, number of processor cores, amount of memory, the number and size of disks, and the network cards. It also gathers performance data: how much of the processor and memory the machine actually uses, how fast the disks read and write, and how much network traffic flows. Performance data is vital, because a machine configured with 16 cores that never uses more than 2 does not need 16 cores in the cloud.

The appliance can also perform software inventory, listing the applications, roles, and features installed on each machine, and it can detect SQL Server databases and web applications running on the servers. This is done without installing agents, by connecting to the machine with credentials you provide. With this information, Azure Migrate can answer questions such as “which servers run SQL Server 2012?” or “which servers run a website on an old version of a framework?”, which are the kind of questions that decide the migration strategy.

Discovery is not a one-time snapshot. It keeps running, so the picture updates as machines are added or removed. For good sizing results, Microsoft recommends letting performance collection run for a reasonable period before relying on it. A machine measured only on a quiet Sunday will look much smaller than its Monday morning self. Many teams collect for at least a few weeks, and for systems with month-end or seasonal peaks, they cover a full business cycle. The tool lets you pick how much history to consider when making an assessment.

An application is rarely one server. Dependency analysis finds the whole family so that you never move one member alone.

A dependency is a relationship where one piece needs another to work. A website server may need a database server, an authentication server, and a file server. If you move the website to Azure but leave the database in your old data center, every page request now travels a long distance, and the site may become painfully slow or stop working because firewalls block the new path. Dependency analysis shows these relationships by watching the network connections between machines: which machine connects to which, on what port, and how often. A port is a numbered doorway on a machine that a particular kind of service listens on, for example 443 for secure web traffic and 1433 for SQL Server.

Azure Migrate offers two styles. Agentless dependency analysis uses the appliance to collect connection information from the machines without installing software on each one. It needs credentials and works for a limited number of machines per appliance, so it is best for planned batches. Agent-based dependency analysis installs two small agents on the machines and sends data through Azure Monitor. It is more detailed and works for machines in many environments, but it needs installation work on each machine. Teams choose depending on how many machines they need to study and how much they can touch.

The result is a dependency map, a diagram that shows machines as boxes and connections as lines. You can zoom in on one machine and see what talks to it, and from which time period. You can then use the map to build groups of machines that belong together, for example “Payroll application: web server, application server, and database server”. Groups become the unit of assessment and the unit of migration waves. Dependency maps also expose surprises: connections to a forgotten server, to a shared service, or to a system outside the company.

flowchart TB
    U["Users"] --> W["Web server"]
    W --> A["Application server"]
    A --> D[("Database server")]
    A --> F["File server"]
    A --> X["Old licensing server - forgotten"]
    W --> L["Load balancer"]
    D --> B["Backup server"]
    

An assessment answers three questions for each machine: will it work in Azure, how big should it be, and what will it cost.

An assessment is a calculated report based on the discovered data and a set of properties you choose. You create an assessment from a group of machines, pick the target (for example, Azure virtual machines), and set assessment properties. These properties tell the tool how to think: which Azure region to target, which pricing plan to assume, whether to apply Hybrid Benefit, how many days of performance history to look at, which percentile of usage to use, and how much extra room to leave as a comfort margin.

The first answer is readiness. The tool checks each machine against what Azure supports. It may mark a machine as ready for Azure, ready with conditions (for example, an old operating system that needs an update or a paid extended support plan), not ready (a disk too large or a feature not supported), or unknown if data is missing. These labels are not final judgments but a helpful first filter, and each comes with a message explaining the reason and often the recommended fix.

The second answer is sizing. There are two sizing criteria. As-on-premises sizing simply copies the current configuration: if the machine has 8 cores and 32 gigabytes of memory, choose the Azure size closest to that. This ignores real use and is useful when you have no performance data or want a quick, cautious estimate. Performance-based sizing looks at how much the machine really used and recommends a size that fits that use, plus the comfort margin. It usually produces smaller and cheaper recommendations, and it also chooses the disk type, such as standard hard-disk-style storage or faster solid-state storage, based on measured input and output speed. For most projects, performance-based sizing is the better starting point, provided you collected data over a representative period.

The third answer is cost. The assessment estimates the monthly price of running each machine, its disks, and sometimes extras, based on the chosen region, currency, and pricing options. Pricing options include pay-as-you-go, reserved instances (a discount for promising to use a machine size for one or three years), savings plans (a flexible discount for committing to a spend per hour), and Azure Hybrid Benefit. You can compare scenarios side by side, such as “all pay-as-you-go” versus “three-year reservation with Hybrid Benefit”, and see how the monthly total changes.

Servers are only one kind of workload. Azure Migrate assesses several kinds of destinations, each with its own questions.

Moving a machine as a whole is the simplest path, but it keeps all the management work. Often it is wiser to move the contents of the machine to a managed Azure service, where Microsoft looks after patches, backups, and availability. Azure Migrate can assess several of these destinations.

Databases

For SQL Server, the assessment checks the version, the features used, and the size and performance needs of each database. It then recommends the best Azure destination. Azure SQL Database is a fully managed database for one database at a time. Azure SQL Managed Instance is closer to a whole SQL Server, with high compatibility, so applications usually need fewer changes. SQL Server on an Azure virtual machine keeps full control, and is the fallback when features are not supported elsewhere. The tool lists migration blockers, features that prevent a move to a particular target, and warnings, which are behaviors that change but can be handled. This helps teams choose an appropriate replatform path before touching anything.

Web applications

For websites, the assessment studies the web server and the application framework and tells you whether the site can run on Azure App Service, a managed place to host web apps, or in containers. It can report issues such as use of local files, unsupported components, or settings stored on the old machine. The result guides whether a quick move is possible or whether developers need to adjust code.

Azure VMware Solution

Some organizations run thousands of virtual machines on VMware and want to leave their data center quickly without changing anything. Azure VMware Solution provides real VMware environments running inside Azure data centers. The assessment sizes the number of hosts needed and estimates cost. Since the virtual machines keep the same format and tools, migration can be fast and low risk, and you can modernize later at your own pace.

Technology is only half of the story. Leaders need a money case, and engineers need an order of work.

A business case is a document that compares the cost of staying on-premises with the cost of moving to Azure, over several years. Azure Migrate can generate one from your discovered data. It estimates the current cost of running the machines, including hardware, electricity, space, software licenses, and some staffing assumptions, and compares them to the estimated Azure cost under chosen options. It can also show the effect of savings such as reserved pricing, Hybrid Benefit, and rightsizing. The result is a set of numbers and charts that finance teams understand. As with any estimate, the output depends on the assumptions, so your own cost information is more reliable than defaults.

Once the case is approved, you plan waves. A wave is a group of applications moved together within a period, such as a few weeks. The usual advice is to start with simpler, lower-risk systems to build skill and confidence, then move to more complex and critical systems. Waves are built from dependency groups, so related machines move together. They are also shaped by business events: nobody wants to migrate the shop’s website a week before the biggest sale of the year.

Never move into a flat with no electricity. Prepare the Azure environment before the first machine arrives.

A landing zone is a well-prepared Azure environment with the basics already in place: accounts and permissions, network, security rules, monitoring, and policies. Microsoft’s Cloud Adoption Framework offers a design for it, often called an Azure landing zone. It organizes subscriptions into groups called management groups, so that rules can be applied to many subscriptions at once, and separates areas such as shared platform services (identity, connectivity, management) from areas where applications live.

The most important parts for a migration are these. Identity: how people sign in, usually through Microsoft Entra ID, and who gets which role. Networking: virtual networks in Azure, the connection between your data center and Azure through a VPN or ExpressRoute, address ranges that do not clash with your on-premises addresses, and firewall rules. Security: policies that enforce encryption, approved regions, and required tags; protection services such as Microsoft Defender for Cloud. Governance: naming, tagging, and cost controls. Management: backup, monitoring, and update management. If these are not ready, migrated machines may land in an unsafe or unreachable place.

When you start replicating a machine, you choose the target settings: which subscription, resource group, virtual network, and subnet the new machine should use, and which machine size and disk type. A good landing zone means these choices are already clear and safe. Many teams define the landing zone using infrastructure as code tools such as Bicep or Terraform, so it can be built the same way every time and reviewed like software.

Now to the heart of the matter: how a running server is copied to Azure without stopping it.

The server migration tool uses a technique called replication. Instead of copying a disk once, which would take a long time while the server keeps changing, it copies the data in stages. First comes initial replication, a full copy of all disks. This may take hours or days, depending on the data size and the network speed, but the source server keeps running normally. After this, delta replication begins. A delta is only what changed since the last copy. The tool keeps sending these small changes, usually every few minutes to every hour depending on the method, so the Azure copy stays close behind the live server.

There are different ways to capture the changes, depending on where the server runs. For VMware, there is an agentless method: the tool talks to the virtualization system and uses its built-in change tracking to find modified disk blocks, so nothing is installed inside the server. For Hyper-V, a small provider is installed on the hosts to track changes. For physical servers, other clouds, and cases where agentless is not available, there is an agent-based method that installs a Mobility service inside each server, which watches disk writes, and sends them through a replication appliance that compresses and forwards them. Under the surface this technology comes from Azure Site Recovery, the Azure disaster recovery service.

In Azure, the data lands first in a storage account and is then turned into managed disks. The tool keeps these disks updated. When you are ready to test, it creates a virtual machine from the latest copy, in a network of your choice. When you are ready to switch, you run the migrate action: it can optionally shut down the source server, send a last delta so no data is lost, and then create the production Azure virtual machine. After you confirm that everything works, you stop replication and clean up.

sequenceDiagram
    participant S as Source server
    participant R as Replication path
    participant Z as Azure storage and disks
    participant T as Test network
    participant P as Production network
    S->>R: Initial replication - full copy of disks
    R->>Z: Writes data to Azure
    loop Every few minutes
        S->>R: Delta - only changed blocks
        R->>Z: Updates the Azure copy
    end
    Z->>T: Test migration - start copy in isolated network
    T-->>Z: Checks pass, test copy deleted
    S->>R: Planned downtime - final delta, optional shutdown
    R->>Z: Last changes applied
    Z->>P: Cutover - create the production virtual machine
    P-->>S: Old server kept stopped until confirmed
    

When the plan says replatform, different tools take over from server replication.

For databases, Microsoft provides several tools. The Azure Database Migration Service, often called DMS, is a managed service that moves data from a source database to an Azure database service. It supports online migrations, where the source stays in use while changes keep flowing to the target until the cutover, with only a short outage; and offline migrations, where the source is stopped and the data copied in one go, which is simpler but needs a longer outage. The Azure Data Studio migration extension and the older Data Migration Assistant help assess and prepare databases, finding compatibility problems before the move. For SQL Server moves to Azure SQL Managed Instance, there are also methods based on backup and restore, which are familiar to database administrators.

For web applications, the Azure App Service migration assistant and related tools scan a website on a Windows or Linux server, report whether it can run in App Service, and then package and move it. If the site depends on features not supported there, it points them out. For container-based moves, Azure Migrate has options to convert certain applications into container images and deploy them to Azure Kubernetes Service or App Service, which can speed up modernization of older web applications.

For very large amounts of raw data, networks can be too slow. Imagine copying a petabyte (a thousand terabytes) over a 1 gigabit link: it would take about three months of non-stop transfer. For such cases, Azure offers Azure Data Box, ruggedized storage devices that Microsoft ships to you. You copy data onto the device, ship it back, and Microsoft uploads the data into your Azure storage account. This is often called an offline transfer.

The safest move is the one you rehearsed. Test migration is the rehearsal, and cutover is opening night.

A test migration creates a temporary virtual machine in Azure from the replicated data, without touching the live source server and without stopping replication. You place it in a separate test network, one that cannot reach your production systems, so that the copy does not accidentally send emails, charge customers, or update a live database. Inside this safe room, you check that the machine starts, that the application runs, that people can sign in, that the connections to other systems behave as expected, and that performance is acceptable. When you are done, you delete the test machine with a single action and the replication continues. You can run test migrations as many times as you wish, and you should, because each run teaches you something.

The cutover, which the tool calls migrate, is the real switch. A good cutover follows a written plan. First, announce the outage window to users. Second, stop the application on the source, so no new data is created. Third, run the migrate action, which can shut down the source server and perform a final sync, so the Azure copy has every last change. Fourth, the production virtual machine is created from the final data, using the settings you chose. Fifth, update the pointers that tell users and other systems where to find the application, such as DNS names (the phone book of the internet) or load balancer settings. Sixth, run the agreed checks, and have the business owner confirm the system works. Finally, keep the old server powered off but available for a short period in case you must go back.

A migration is, above all, a large transfer. The road between your site and Azure sets the pace.

Bandwidth is the amount of data a network can carry per second. Replication needs it twice: once for the big initial copy, and again, in smaller amounts, for the continuing deltas. A quick rule helps: one terabyte over a link that really delivers 100 megabits per second takes roughly one full day of continuous transfer. If you plan to replicate fifty terabytes at once, you must know your usable bandwidth, which is always less than the number on the contract, because other traffic also uses the link. Plan to replicate in batches matching the bandwidth, and use throttling features to avoid choking daily business traffic.

There are three common ways to connect. The first is the public internet using encrypted HTTPS. It is easy and needs no extra equipment, and is often fine for smaller moves. The second is a site-to-site VPN, a secure encrypted tunnel over the internet between your network and an Azure virtual network. It is quick to set up but its speed is limited. The third is ExpressRoute, a private, dedicated connection between your site and Azure, offering predictable speed and lower delay, with no use of the public internet. Large migrations and sensitive data often use ExpressRoute. Azure Migrate can use private endpoints so that the appliance and replication traffic stay on the private path.

Name resolution, firewalls, and timing

Besides raw speed, check the details. The appliance and the machines must be able to reach the specific Azure addresses and names that the tool needs; firewalls must allow them. DNS (the Domain Name System, the internet’s phone book) must resolve names correctly in both places. Time on machines should be accurate, because secure connections can fail if clocks are far apart. After cutover, migrated machines need routes back to the systems they still use on-premises, and those systems may need firewall changes to accept requests from the new Azure addresses.

A migration moves your most valuable data across a network. Treat it like a bank transfer.

Security begins with who may do what. Azure uses role-based access control, or RBAC, where people receive roles at a chosen scope, such as a subscription or resource group. For Azure Migrate you typically need enough permission to create a project and its helper resources, and then separate permissions for people who only run assessments or only run migrations. Give each person the smallest role that allows their work, and use Microsoft Entra ID groups so that access follows team membership. For powerful actions, such as the final cutover into production, consider time-limited elevation using Privileged Identity Management.

Security continues with how data travels. Data sent from the appliance and replication path to Azure is encrypted in transit using TLS, the standard that protects HTTPS. Data stored in Azure is encrypted at rest by default, and you can use your own keys through Azure Key Vault if your rules require it. You can reduce exposure by using private endpoints and by blocking public access to the storage accounts used during replication.

It also includes the source and the appliance. Use dedicated, read-only accounts for discovery; rotate their passwords; and remove them after the project. Keep the appliance patched and limit remote login. Finally, remember the migrated machine itself: copying a server also copies any old weaknesses, such as unpatched software, weak passwords, and open ports. Use the move as a chance to patch, to enable Microsoft Defender for Cloud, to turn on disk encryption, and to place the machine behind proper network security groups, which are sets of allow and deny rules for traffic.

A migration is a long-running activity. Good dashboards tell you early when something drifts.

Azure Migrate shows progress on its own pages. The overview page summarizes how many servers are discovered, assessed, replicating, and migrated. The replicating machines list shows each machine’s status, such as initial replication in progress, protected, or error, along with the time of the last successful sync and the amount of data pending. The jobs view lists actions like starting a test migration or a cutover, with success or failure and error details. Notifications and error messages usually explain the cause and suggest a fix, such as a blocked network port or a disk that failed a consistency check.

Beyond these pages, use Azure’s general monitoring tools. The Azure Activity Log records who did what in your subscription, which is useful for audits and troubleshooting. Azure Monitor can send alerts when something needs attention. On the source side, watch the health of the appliance, its connection status, and available disk space. After the move, install monitoring on the new virtual machines, using Azure Monitor and, for application-level views, Application Insights, so you can compare performance with what you saw before.

Things will go wrong. Good teams plan what to do before they do.

A migration has many moving parts, so failure comes in many forms. The key principles are to change as little as possible at once, to keep the old system until the new one is proven, and to rehearse. Below are common failures and the usual responses.

The most valuable safety net is the rollback plan: a written, tested route back to the old system. Because the source server is not changed by replication, and because you keep it stopped but intact for a period after cutover, rolling back is usually as simple as switching traffic back and restarting it. The catch is data: any changes made in Azure after cutover would be lost on rollback, so set a clear point after which rollback is no longer allowed, and agree it with the business.

The migration tools are cheap. The destination is where the money goes, so most of the work is making it smaller.

For many scenarios, Azure Migrate’s discovery, assessment, and server migration tools are offered without separate charges for the tool itself. You pay for the Azure resources that the process uses. During replication, this includes storage for the replicated disks and for temporary storage accounts, some compute for processing in certain methods, and network traffic. During testing, you pay for the test virtual machines while they run. After cutover, you pay for the production virtual machines, disks, backup, monitoring, and any managed services you use. Some advanced features or partner tools have their own prices. Pricing rules and free offers change, so always confirm on the official pricing page and in the pricing calculator.

To keep costs in check, think in three layers. Before the move: retire unused servers, rightsize using real performance data, and choose managed services where they reduce work. During the move: delete test machines when finished, avoid long periods of replicating machines that will not move soon, and clean up temporary storage. After the move: use reserved instances or savings plans for steady workloads, Azure Hybrid Benefit for existing licenses, auto-shutdown for non-production machines outside working hours, and cost alerts. Microsoft also runs offers and funding programs to help customers migrate, such as the Azure Migration and Modernization Program, which provide guidance and sometimes financial support; availability and terms change, so ask your Microsoft contact.

Cutover is not the finish line. It is the starting line of life in the cloud.

A freshly migrated machine is usually a faithful copy of the old one, which means it carries old habits. The optimize phase uses real Azure data to improve it. Start with rightsizing: Azure Advisor and Azure Monitor show which machines use little of what they have, and recommend smaller sizes or shutdown. Look at disks: choose the type that fits actual speed needs, since premium disks cost more than standard ones. Check availability: for important systems, use features like availability zones (separate buildings inside a region) or availability sets, and take advantage of Azure Backup and Azure Site Recovery for protection and disaster recovery.

Then look for modernization opportunities. A machine that runs a database could move to a managed database. A website could move to App Service. A scheduled job could move to a function that runs only when needed. Each step reduces upkeep and often cost, and each is easier now that the system runs in Azure. Many teams call this “migrate first, modernize later”, and it is a sound approach as long as the second step is actually scheduled and not forgotten.

Performance work includes measuring latency, the delay between asking and getting an answer. When an application server moves to Azure but its database stays on-premises, latency may jump from one millisecond to dozens, and chatty applications suffer. Fix this by moving the pair together or by caching. Compare key business timings before and after: page load time, report run time, batch job duration. If a figure is worse, investigate size, disk, network path, and placement before assuming the cloud is slow.

Teams that have moved thousands of servers keep finding the same good ideas and the same traps.

A short checklist from experienced teams, followed by the slips that cost beginners the most.

Mistakes that cost the most

Several tools help with moves. Knowing the neighbors helps you place Azure Migrate correctly.

The tools are often used together. A company might use Azure Migrate for discovery and server replication, the Database Migration Service for the main databases, Data Box for a large archive, and Azure Site Recovery after the move to protect the new machines. Product names, scope, and features change, so confirm current details in Microsoft’s documentation before choosing.

Three stories show how the pieces fit, followed by a quick guide to when this tool is the right choice.

A simple decision guide

Azure Migrate is a hub that takes you from “we think we have a lot of servers” to “everything is running safely in Azure”.

We began with a family moving house: first make a list, then measure the new home, pack in order, move room by room, and keep the keys until the new place feels right. Azure Migrate follows the same path. The appliance discovers what you own. Dependency analysis reveals which systems belong together. Assessments judge readiness, size, and cost. The landing zone prepares the new home. Replication copies servers while they run, test migrations rehearse the move, and cutover switches with a short outage. Database and web app tools handle replatforming, and shipped devices handle huge data. Throughout, security, monitoring, and a rollback plan keep the move safe, and optimization afterward turns a copied system into a good cloud citizen.