Azure Migrate - Lift and Shift On-Premises VM to Azure without Modenization

Hello Nitrox, it sounds like you’ve accidentally been running the App Modernize (containerization) flow for your on-prem IIS/Oracle server, so Azure Migrate is treating your web app as a candidate for containers/Kubernetes. If all you want is a simple “lift-and-shift” of the entire Windows VM (OS, Oracle, web site) – no App Service, no containers – you need to use the Server migration scenario instead of the Web App containerization or Modernize option.

Here’s how to do a pure lift-and-shift of your Hyper-V VM “as is”:

1. Create (or use) an Azure Migrate project scoped to Server migration
   • When you set up replication, choose Hyper-V as the source.
   • Install the Azure Migrate replication appliance and Hyper-V provider agents (see “Migrate machines as physical servers to Azure”).
2. Skip the App Containerization blade
   • In the portal, go to Discover + assess > Servers rather than Web apps or Modernize.
   • Don’t add your web app under the Web App assessment.
3. Run an assessment and then enable replication for those servers
   • Once the VM is replicating, you’ll get a target Azure VM that contains everything on-prem, Oracle and IIS included.
   • Perform a test failover, validate functionality, then do the final cutover.

If you still see Kubernetes as a target, it means you’re on the App Modernize path. To switch back, either:

a) Create a fresh Azure Migrate project and choose Migrate servers to Azure.

b) Or in your existing project, under Assessments, filter out Web apps and only include the servers you want to replicate.

Hope that clears things up – you’ll end up with an Azure VM that’s a carbon copy of your on-prem server, no code changes or container work required!

Reference docs

• What is Azure Migrate? (overview for server & web apps) https://learn.microsoft.com/azure/migrate/migrate-services-overview?view=migrate
• Migrate Hyper-V VMs (server migration) https://learn.microsoft.com/azure/migrate/tutorial-discover-hyper-v?view=migrate
• Migrate machines as physical servers to Azure https://learn.microsoft.com/azure/migrate/tutorial-migrate-physical-virtual-machines?view=migrate
• Migrating web apps to Azure App Service (to see why the Modernize flow suggests containers) https://learn.microsoft.com/azure/migrate/tutorial-migrate-webapps?view=migrate

Azure Migrate supports both “lift and shift” (rehost to Azure VM) and modernization paths (for example, to App Service or Kubernetes). The behavior described occurs because the assessment and migration path for that workload is being driven by an application-level assessment with a modernization preference, not a pure infrastructure (Azure VM) assessment.

To ensure a true lift-and-shift of the entire Hyper‑V VM (OS + web app + Oracle) to an Azure VM without modernization:

1. Create an Azure VM–focused assessment instead of an application modernization assessment.
   • Use the Azure VM assessment path under Servers to check readiness, right-sized targets, and cost for migrating the whole server as a VM. This path is explicitly for “lift and shift to Azure VM”.
   • The Azure VM assessment is designed for quick lift-and-shift of on‑premises or public cloud servers to Azure VMs and will not try to break out the web app into Kubernetes or other PaaS targets.
   • See: “To quickly migrate your on-premises or public cloud servers to Azure using lift and shift, create an Azure VM assessment to check readiness, cost, and get migration advice for your workloads.”
2. Avoid using an application/web app assessment when the goal is to keep the server as-is.
   • Application assessments can recommend multiple migration paths, including:
     • Lift and shift to Azure VM
     • Lift and shift to AVS (Azure VMware Solution)
     • Modernization paths (for example, PaaS or Kubernetes) when the migration preference is set to “Modernize”.
   • If the assessment is created with a Modernize preference, the recommended migration path will try to maximize PaaS coverage, which can result in Kubernetes or other modern targets being selected automatically.
3. If using application assessments, explicitly set the migration preference to minimize modernization.
   • In the application assessment, the recommended migration path is selected based on migration preference:
     • If the preference is “Modernize”, the strategy maximizes PaaS coverage (which can include Kubernetes).
     • If the preference is minimum migration time, the strategy is the one that takes minimum time to migrate, which is typically a rehost/lift‑and‑shift option such as Azure VM.
   • Change the migration preference away from “Modernize” and review the strategy tabs to select the Lift and shift to Azure VM migration path.
4. When starting the actual migration for Hyper‑V VMs, choose “Servers or virtual machines (VM)” and “Azure VM”.
   • In the Azure Migrate project, under Start migration or Replicate, select:
     • What do you want to migrate? → Servers or virtual machines (VM)
     • Where do you want to migrate to? → Azure VM
     • Are your machines virtualized? → Yes, with Hyper‑V
   • If an assessment was run, you can import VM sizing and disk type recommendations from that Azure VM assessment. This keeps the migration as a VM rehost and does not modernize the web app.

By basing the process on an Azure VM assessment (or an application assessment with migration preference set to minimize modernization and explicitly choosing “Lift and shift to Azure VM”), the migration wave will treat the workload as a single VM to rehost, rather than attempting to move the web app to Kubernetes.

References:

• Azure Migrate: Common questions
• Review an application assessment
• Tutorial: Create web app assessment for modernization
• Create an Azure VM assessment
• What is Azure Migrate?
• Migrate Hyper-V VMs to Azure
• Migrate Hyper-V servers to Azure using Private Link