Migration Strategy Selection

Migration Strategy Selection for SAP Workloads on Azure

Introduction: The Criticality of Migration Strategy

Migrating SAP landscapes—which often include core ERP systems, S/4HANA instances, and various peripheral applications—to the cloud is one of the most complex technical undertakings an organization can face. When we talk about migrating SAP workloads to Azure, we are not simply moving files from a physical server to a virtual machine. We are fundamentally changing the delivery model of the business’s primary engine of operation. The strategy you select dictates the downtime, the risk profile, the total cost of ownership (TCO), and the ultimate performance of your SAP environment on the Azure platform.

Choosing the right migration strategy is important because SAP environments are notoriously sensitive to latency, storage throughput, and memory bandwidth. A poor choice in migration approach can lead to prolonged outages, data inconsistencies, or a "lift-and-shift" deployment that fails to take advantage of cloud-native benefits, resulting in higher operational costs than the original on-premises setup. By understanding the nuances between rehosting, replatforming, and refactoring, you ensure that your migration aligns with both your technical requirements and your long-term business goals.

Understanding the Migration Archetypes

In the industry, we often categorize migration strategies using the "6 Rs" model. However, when applied specifically to SAP on Azure, these are typically distilled into three primary paths: Rehosting (Lift-and-Shift), Replatforming (Lift-and-Shift to HANA), and Refactoring (Cloud-Native Transformation).

1. Rehosting (Lift-and-Shift)

Rehosting involves moving your existing SAP landscape "as-is" to Azure virtual machines. You keep your current operating system, your current database, and your current application configuration. This is often the fastest way to get out of a physical data center, but it rarely provides the performance gains or operational simplicity that Azure can offer.

2. Replatforming (Lift-and-Shift to HANA)

Replatforming usually involves moving your SAP application to Azure while simultaneously migrating your database to SAP HANA. This is the most common path for organizations currently running SAP ECC on AnyDB (like Oracle, DB2, or SQL Server). You gain the benefit of HANA’s in-memory computing without necessarily redesigning your entire application layer.

3. Refactoring (Cloud-Native Transformation)

Refactoring is the most ambitious strategy. It involves moving to SAP S/4HANA, potentially adopting SAP Business Technology Platform (BTP), and shifting from a monolithic architecture to a more modular, service-oriented approach. This requires the most effort but yields the highest long-term return on investment, enabling true agility and integration with other cloud services.

Callout: The "AnyDB" vs. "HANA" Distinction The decision to migrate to SAP HANA is often the single most significant factor in your migration strategy. While "AnyDB" (non-HANA databases) can run on Azure, SAP HANA is optimized specifically for the Azure platform's memory-optimized virtual machine series. Choosing to stay on AnyDB avoids the cost of a database migration project but limits your ability to utilize S/4HANA features.

Evaluating Infrastructure Requirements

Before selecting a strategy, you must conduct a rigorous assessment of your current infrastructure. SAP workloads are resource-intensive, and Azure handles these resources differently than a private data center.

Memory Requirements

SAP HANA is an in-memory database, meaning your entire active dataset resides in RAM. When you calculate your migration target, you cannot simply match current CPU counts. You must look at the total memory footprint of your database and add a buffer for growth and high availability. Azure provides specialized M-series and E-series virtual machines specifically designed for these high-memory demands.

Storage Throughput and IOPS

SAP applications perform massive amounts of read/write operations. In a traditional data center, you might have had a high-end SAN (Storage Area Network) providing consistent, low-latency storage. On Azure, you must map these requirements to Managed Disks (Premium SSD or Ultra Disk). You need to calculate the Input/Output Operations Per Second (IOPS) and throughput (MB/s) for your database logs and data files to ensure they meet SAP’s specific certification requirements.

Network Latency

The communication between the SAP Application Server and the Database Server is sensitive to network latency. In an on-premises environment, these servers might be on the same physical rack. In Azure, you must use Proximity Placement Groups (PPGs) to ensure that your virtual machines are physically located in the same data center, minimizing the distance data must travel.

Step-by-Step Selection Process

To select the right strategy, you should follow a structured evaluation process. Skipping these steps is the most common cause of migration failure.

Step 1: Inventory and Dependency Mapping

Use tools like Azure Migrate or SAP Landscape Management (LaMa) to catalog every component in your landscape. Identify the version of the SAP kernel, the database version, and the OS distribution. Note any third-party integrations, as these often break during migration.

Step 2: Performance Baselining

You cannot know if your migration was successful if you do not know how the system performed before you moved it. Document the average response times for critical transactions (like VA01 or ME21N) and batch job durations. Use this as your "golden baseline."

Step 3: TCO and ROI Analysis

Compare the cost of running your current infrastructure against the projected cost of Azure resources. Include the cost of licensing, labor, and potential downtime. If the cost of rehosting is higher than the cost of refreshing hardware on-premises, your strategy selection is likely flawed.

Step 4: Pilot Migration (Proof of Concept)

Never migrate your production system first. Select a non-production environment—ideally a sandbox or a development instance—and perform a "dry run." This will expose issues with network configuration, storage throughput, or OS compatibility that you missed during the planning phase.

Technical Considerations: Azure Resource Provisioning

When you are ready to configure your target infrastructure, you will likely use Infrastructure as Code (IaC) to ensure consistency. Using tools like Terraform or Azure Resource Manager (ARM) templates allows you to define your SAP environment in code, which makes it repeatable and less prone to manual error.

Example: Basic Terraform Snippet for SAP VM

The following is a simplified example of how you might define a virtual machine for an SAP application server in Terraform.

resource "azurerm_linux_virtual_machine" "sap_app_server" {
  name                = "sap-app-01"
  resource_group_name = azurerm_resource_group.rg.name
  location            = azurerm_resource_group.rg.location
  size                = "Standard_E8ds_v4"
  admin_username      = "adminuser"

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Premium_LRS"
  }

  source_image_reference {
    publisher = "SUSE"
    offer     = "sles-sap-15-sp3"
    sku       = "gen2"
    version   = "latest"
  }
}

Explanation of the code:

• Size (Standard_E8ds_v4): This is an E-series VM, which is the industry standard for SAP application servers due to its high memory-to-core ratio.
• Storage (Premium_LRS): We use Premium Locally Redundant Storage because standard HDD storage will not provide the IOPS required by SAP applications for stable operation.
• Image (sles-sap-15-sp3): We are selecting a SUSE Linux Enterprise Server for SAP Applications image, which is pre-configured with the necessary kernel parameters for SAP.

Best Practices and Industry Standards

Adhering to established industry standards will significantly reduce the risk of performance degradation. SAP and Microsoft have collaborated to provide the "SAP on Azure" certification program, which dictates exactly which VM types are supported for specific SAP workloads.

• Use Proximity Placement Groups: Always group your application and database servers in a PPG to ensure minimal network latency.
• Leverage Accelerated Networking: Enable Azure Accelerated Networking on all SAP-related network interfaces. This reduces jitter and latency by offloading network processing from the CPU to the hardware.
• Implement SAP-Certified Storage: Do not attempt to use uncertified storage tiers for production databases. SAP’s performance requirements are strict, and using the wrong storage tier will lead to database locks and system instability.
• Plan for High Availability (HA) and Disaster Recovery (DR): Azure Availability Zones provide protection against data center failures, while Azure Site Recovery (ASR) can be used for cross-region disaster recovery.

Note: Always consult the SAP on Azure support matrix. It is updated frequently, and using a VM size that was "just approved" can sometimes lead to stability issues. Stick to configurations that have been documented and tested by both Microsoft and SAP.

Common Pitfalls and How to Avoid Them

Even with careful planning, migration teams often encounter predictable obstacles. Recognizing these early is key to a smooth transition.

Pitfall 1: Ignoring the "Network Bottleneck"

Many teams focus entirely on the server specs and ignore the connection between the on-premises data center and the Azure region. If you are performing a large data migration, the speed of your ExpressRoute connection will be the limiting factor.

• Avoidance: Test your bandwidth throughput well in advance. If necessary, use physical data transfer devices like Azure Data Box to move massive database backups rather than sending them over the wire.

Pitfall 2: Over-provisioning Resources

It is tempting to "over-size" your Azure VMs to be safe, assuming that more CPU and RAM will solve any performance issue. This leads to massive, unnecessary monthly bills.

• Avoidance: Use the Azure SAP sizing tools. These tools analyze your current SAPS (SAP Application Performance Standard) requirements and recommend the exact VM size needed.

Pitfall 3: Neglecting Security Groups

In a physical data center, you might rely on hardware firewalls. In Azure, you must configure Network Security Groups (NSGs) and Application Security Groups (ASGs).

• Avoidance: Create granular rules that allow traffic only between necessary components (e.g., allow App Server to talk to DB Server on port 3200, but block all other traffic). Never leave ports open to the public internet.

Comparing Migration Strategies

The following table provides a quick reference to help you decide which path aligns with your current organizational capabilities and goals.

Deep Dive: The Importance of the SAP HANA Database Migration

When choosing a migration strategy, the transition to SAP HANA is often the deciding factor. SAP HANA is not just a database; it is a data platform that changes how you interact with your data. If you are currently on an older version of SAP ECC, you are essentially running on a legacy platform.

Moving to HANA allows you to utilize "side-by-side" reporting, where analytical queries run against the database in real-time without impacting transactional performance. When planning your migration, you must account for the "Database Migration Option" (DMO). This is a tool provided by SAP that performs the database migration and the upgrade of the SAP software in a single step, significantly reducing the amount of downtime required during the cutover window.

The Role of Azure Availability Zones

For production SAP environments, you should always deploy across multiple Availability Zones (AZs). An Availability Zone is a physically separate location within an Azure region. By placing your primary SAP application server in Zone 1 and your secondary server in Zone 2, you ensure that if one data center experiences a power or network failure, your SAP environment remains operational.

Warning: While Azure Availability Zones provide excellent fault tolerance, they do introduce a very small amount of network latency (usually less than 2ms). For most SAP workloads, this is negligible, but for extremely latency-sensitive batch processes, you must conduct performance testing to ensure the latency impact is within your acceptable threshold.

Advanced Infrastructure Configuration: The "SAP-Ready" Network

A successful migration requires more than just VMs; it requires a network architecture that mimics the security and performance of a private data center.

Virtual Networks (VNet) Design

You should design your VNet to be segmented. A typical architecture includes:

• Management Subnet: For jump boxes and management tools.
• Application Subnet: For the SAP Application Servers (PAS/AAS).
• Database Subnet: For the SAP HANA instance, restricted to only allow traffic from the Application Subnet.

Example: Network Security Group (NSG) Best Practice

You should define your NSGs to follow the principle of least privilege. Here is how you might structure a rule to permit communication between the Application Server and the Database Server:

• Name: Allow_App_To_DB
• Priority: 100
• Source: Application_Subnet_IP_Range
• Source Port: *
• Destination: Database_Subnet_IP_Range
• Destination Port: 3200-3299 (The SAP Instance ports)
• Protocol: TCP
• Action: Allow

By keeping these rules strict, you ensure that even if one component is compromised, the threat cannot move laterally through your SAP landscape.

Monitoring and Optimization: Life After Migration

Once the migration is complete and the system is live, your work is not finished. In the cloud, the infrastructure is dynamic, and you should treat your environment as a living entity.

Azure Monitor for SAP Solutions

Azure provides a native monitoring tool specifically designed for SAP workloads. It collects telemetry from the OS, the database, and the SAP application layer. You should configure alerts for:

• High Memory Utilization: If your HANA memory usage approaches 80%, you need to either scale up or optimize your queries.
• Disk Latency: If your write latency exceeds 5ms, your database performance will suffer, and you should investigate the storage throughput.
• CPU Steal: If you see high "steal" percentages, it indicates that your VM is competing for resources with other tenants on the host, which is a sign that you may need to look at Dedicated Hosts.

Cost Management

The cloud model allows you to "right-size" your environment continuously. Every six months, review your performance metrics. If you find that your database server is consistently using only 50% of its allocated RAM, you can downsize the VM to a smaller SKU and save significant costs. This level of flexibility is impossible in a traditional data center.

Comprehensive Key Takeaways

To ensure a successful migration of SAP workloads to Azure, keep these fundamental principles in mind:

1. Alignment with Business Goals: Select your migration strategy based on your long-term business needs, not just the fastest path out of your current data center. If innovation is the goal, invest the effort into a refactoring strategy.
2. Performance is Paramount: SAP workloads are sensitive to latency and storage throughput. Always prioritize certified VM sizes, Proximity Placement Groups, and Premium storage tiers to ensure the system remains responsive.
3. Data-Driven Planning: Use tools to inventory your landscape and baseline your current performance. Never guess about your resource requirements; use the SAP-on-Azure sizing tools to ensure you are neither over-provisioning nor under-provisioning.
4. Security by Design: Implement network segmentation using NSGs and ASGs from day one. Do not rely on perimeter security; assume that your internal network must be protected as if it were exposed to the internet.
5. Test, Test, and Test Again: Perform multiple dry runs with non-production systems. The "lift-and-shift" process rarely goes perfectly the first time, and you want to discover your "gotchas" in a sandbox environment, not during your production cutover window.
6. Continuous Optimization: The cloud is not a "set it and forget it" environment. Use Azure Monitor for SAP Solutions to track performance and regularly review your resource allocation to ensure you are not paying for capacity you do not need.
7. Leverage Native Azure Integration: Once migrated, look for ways to integrate your SAP data with other Azure services, such as Power BI for analytics or Azure Machine Learning for predictive maintenance. The true value of the migration is often found in what you do with the data after it reaches the cloud.

Common Questions (FAQ)

Q: Can I run SAP on Azure with a non-HANA database?

A: Yes, you can run SAP with Oracle, DB2, SQL Server, and other supported databases on Azure. However, you must ensure the specific database version and OS combination is certified by both SAP and Microsoft.

Q: How much downtime should I expect during a migration?

A: Downtime depends on the migration strategy and the size of your database. A "lift-and-shift" with a database backup restore might take several hours, whereas a DMO (Database Migration Option) with system move might take significantly longer. Use the pilot migration to get a realistic estimate for your specific landscape.

Q: Is ExpressRoute strictly necessary?

A: While you can use a Site-to-Site VPN for smaller environments or non-critical workloads, an ExpressRoute is highly recommended for production SAP environments. It provides a dedicated, private connection with consistent latency and higher bandwidth, which is essential for the stability of a production ERP system.

Q: What is the most common mistake in SAP migration?

A: The most common mistake is failing to account for the difference in storage performance between on-premises SANs and cloud-based storage. Many teams assume that because they have enough "space," they have enough "speed." Always check the IOPS and throughput limits of your Azure managed disks against your SAP database requirements.