Migration feasibility for SUSE Linux Enterprise 11 SP4 (VMware) to Azure

I would like to seek guidance regarding the feasibility of migrating an on-premises workload to Microsoft Azure.

Current Environment:

  • OS: SUSE Linux Enterprise Server (SLES) 11 SP4
  • Platform: VMware (on-premises)
  • Workload type: SAP

Requirement:
We are planning to migrate this VM to Azure using a lift-and-shift approach (e.g., Azure Migrate or similar tools). However, due to application dependency constraints, we prefer not to upgrade the OS version prior to migration.

Questions

  1. Is SLES 11 SP4 supported for migration to Azure as-is (without upgrading the OS)?
  2. If migration is technically possible:
    • Will the VM be supported by Azure (including Azure VM agent, extensions, and updates)?
      • Are there any limitations or risks (e.g., security, compatibility, lack of support)?
  3. If direct migration is not supported, what is the recommended approach?
    • Upgrade OS before migration?
      • Migrate first, then upgrade on Azure?
        • Any alternative strategies?

Additional considerations:

  • We are mindful that SLES 11 SP4 is an older OS version and may be in extended or unsupported lifecycle.
  1. Suchitra Suregaunkar 14,595 Reputation points • Microsoft External Staff • Moderator

    Hello @Youthanun Lertrat (UTL)

    Thank you for posting this issue on Microsoft Q&A platform.

    Azure Migrate's agentless VMware migration explicitly lists SLES 11 SP4 as a supported OS for the hydration process. During migration, Azure Migrate automatically performs the required configuration changes, including updating the kernel image with Hyper-V LIS drivers, updating /etc/fstab, removing problematic udev rules, configuring network interfaces, and installing the Azure Linux VM Agent.

    So, a lift-and-shift migration using Azure Migrate (agentless method) from VMware to Azure is technically supported for SLES 11 SP4.

    Reference: Prepare machines for agentless migration with Azure Migrate

    Post-migration: Support limitations and risks:

    While the migration itself is supported, there are important considerations once the VM is running on Azure:

    1. SLES 11 SP4 is NOT a current Azure-endorsed distribution. The endorsed Linux distributions page currently lists only SLES 12 SP5, 15 SP5, 15 SP6, 15 SP7, and 16 as platform images. SLES 11 is not listed among them. This means you will not have the same level of platform image support (predictable updates, Azure-tuned kernels, etc.) as with current endorsed versions.

    Reference: https://learn.microsoft.com/en-us/azure/virtual-machines/linux/endorsed-distros

    2. SLES 11 SP4 is end-of-life from SUSE. General support ended March 31, 2019. LTSS ended March 31, 2022. Only LTSS Core support (x86-64 only) extends until March 31, 2028, and this requires a separate paid contract with SUSE. Without an active LTSS Core subscription, there will be no security patches or updates from SUSE.

    Reference: https://www.suse.com/lifecycle/

    3. Azure Monitor Agent does NOT support SLES 11. The Azure Monitor Agent supported OS list includes only SLES 15 SP7 and OpenSUSE 15 under the SUSE family. SLES 11 is not listed, so you won't be able to use Azure Monitor Agent for log collection or monitoring on this VM.

    Reference: https://learn.microsoft.com/en-us/azure/azure-monitor/agents/azure-monitor-agent-supported-operating-systems

    4. Hyper-V integration services are built-in for SLES 11 SP4. The good news is that SLES 11 SP4 has built-in Hyper-V LIS drivers, so core VM features like networking, storage, and live migration will work. However, newer features like SR-IOV, vRSS, and accurate time sync are not available on SLES 11 SP3/SP4. [learn.microsoft.com]

    Reference: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/Supported-SUSE-virtual-machines-on-Hyper-V

    Given that this is an SAP workload, the recommended path would be:

    Option 1: Migrate first, then upgrade (side-by-side):

    1. Migrate the SLES 11 SP4 VM to Azure using Azure Migrate (agentless VMware method) this is supported.
    2. Once on Azure, deploy a new Azure VM using a supported SLES image from the Marketplace (e.g., SLES 15 SP6 for SAP).
    3. Migrate the SAP application and data from the legacy VM to the new VM using SAP-native migration tools.
    4. Decommission the legacy SLES 11 SP4 VM after validation.

    Option 2 : Upgrade OS on-premises before migration: Upgrade SLES 11 SP4 → SLES 12 → SLES 15 on-premises first, then migrate. Note that direct in-place upgrade from SLES 11 to SLES 15 is not supported by SUSE — intermediate hops through SLES 12 are required, which adds complexity.

    Reference for general Linux preparation: https://learn.microsoft.com/en-us/azure/virtual-machines/linux/suse-create-upload-vhd

    You can migrate the VM to Azure as-is, the migration tooling supports it. But once on Azure, you will be running a legacy, end-of-life OS with limited Azure feature support and no security patches (unless you have a SUSE LTSS Core contract). The strongly recommended long-term approach is to plan a side-by-side migration to a supported SLES version (15 SP5/SP6 for SAP) after the initial lift-and-shift.

    I hope this helps clarify the path forward. If you have any follow-up questions, feel free to ask.

    Thanks,

    Suchitra.

  2. Suchitra Suregaunkar 14,595 Reputation points • Microsoft External Staff • Moderator

    Hello @Youthanun Lertrat (UTL)

    Could you please let us know if the comment above resolved your issue? If you need any further assistance, feel free to reach out, we're always here to support you.

    If you found the comment helpful, please consider clicking "Upvote it."

    Thanks,
    Suchitra.

Sign in to comment

1 answer

  1. AI answer

    1. Migration support for SLES 11 SP4 on VMware

    SUSE Linux Enterprise Server 11 SP4 on VMware is within the operating systems that Azure Migrate supports for agentless VMware migration and for automatic configuration (“hydration”):

    • The agentless VMware migration support matrix lists SUSE Linux Enterprise Server 11 SP4 as a supported Linux OS for migration to Azure.
    • The preparation guidance explicitly includes SUSE Linux Enterprise Server 11 SP4 in the list of Linux versions for which Azure Migrate automatically performs required changes for Azure (kernel/LIS, fstab, udev, network, Azure Linux agent, etc.).

    Therefore, SLES 11 SP4 on VMware can be migrated “as-is” (lift-and-shift) to Azure using Azure Migrate.

    1. Post‑migration support, agent, and limitations

    From the provided content:

    • Azure VM requirements for migrated VMs include:
      • 64‑bit guest OS
      • OS disk ≤ 2,048 GB
      • 1 OS disk, up to 64 data disks (≤ 32 TB each)
      • No shared VHD or FC disks
      • BitLocker not supported
    • For Linux connectivity after migration, SSH must be enabled on the source VM and allowed through firewalls and NSG rules.

    For supported Linux versions (including SLES 11 SP4 in the list):

    • Azure Migrate automatically:
      • Updates kernel image with Hyper‑V Linux Integration Services.
      • Updates fstab entries.
      • Removes problematic udev rules.
      • Updates network interfaces.
      • Installs the Azure Linux VM agent during migration for supported versions.

    Implications for SLES 11 SP4:

    • Technically supported for migration and for running as an Azure VM.
    • Azure Linux VM agent is installed automatically during agentless migration for the listed SLES versions, so VM extensions and Azure platform integration are available according to that agent’s capabilities.
    • Because SLES 11 SP4 is an older OS, there are inherent risks and limitations:
      • Lifecycle/patching: older OS versions may be in extended or end‑of‑support state from the OS vendor, which implies reduced or no security updates.
      • Security posture: running an EOS/EOL OS in production increases security risk.
      • Future compatibility: newer Azure features, extensions, or tooling may not be validated or supported on legacy OS releases.
    1. Recommended approach if staying on SLES 11 SP4

    From the migration planning guidance:

    • Azure Migrate supports lift‑and‑shift first, then performing OS upgrades in Azure.
    • There is explicit support for Windows OS in‑place upgrade during/after migration; for Linux, the guidance is to ensure the OS is in the list of supported distributions and versions and to apply required changes.

    Given that SLES 11 SP4 is supported for migration but is an old release, recommended strategies are:

    1. Lift‑and‑shift first, then modernize on Azure
      • Use Azure Migrate (agentless VMware migration) to replicate and migrate the SLES 11 SP4 SAP VM to Azure.
      • Validate SAP workload functionality after test migration.
      • Plan an OS upgrade path on Azure to a supported SLES version (or another supported SAP‑certified Linux) once the workload is stable.
    2. Upgrade before migration (if change windows and testing capacity allow)
      • Upgrade SLES 11 SP4 to a currently supported SLES version on‑premises.
      • Then migrate with Azure Migrate, benefiting from a longer support horizon and better security posture from day one in Azure.
    3. General guidance regardless of sequence
      • Ensure the VM meets all Azure VM requirements (disk sizes/count, 64‑bit OS, no unsupported storage types).
      • For Linux, verify SSH is enabled and firewall rules allow SSH before migration.
      • Run a test migration first to validate boot, networking, SAP application behavior, and agent/extension operation.

    In summary, SLES 11 SP4 on VMware can be migrated as‑is to Azure with Azure Migrate, and Azure Migrate will automatically perform the necessary OS‑level changes and install the Azure Linux agent for this version. However, due to its age and lifecycle status, it should be treated as a transitional state, with a clear plan to upgrade to a newer, fully supported SLES (or other supported Linux) version after or around the migration.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.
Sign in to answer

Your answer