SAP workloads on Azure: planning and deployment checklist

This checklist is designed for customers moving SAP applications to Azure infrastructure as a service. SAP applications in this document represent SAP products running the SAP kernel, including SAP NetWeaver, S/4HANA, BW and BW/4 and others. Throughout the duration of the project, a customer and/or SAP partner should review the checklist. It's important to note that many of the checks are completed at the beginning of the project and during the planning phase. After the deployment is done, straightforward changes on deployed Azure infrastructure or SAP software releases can become complex.

Review the checklist at key milestones during your project. Doing so will enable you to detect small problems before they become large problems. You'll also have enough time to re-engineer and test any necessary changes. Don't consider this checklist complete. Depending on your situation, you might need to perform additional more checks.

The checklist doesn't include tasks that are independent of Azure. For example, SAP application interfaces change during a move to the Azure platform or to a hosting provider. SAP documentation and support notes will also contain further tasks, which are not Azure specific but need to be part of your overall planning checklist.

This checklist can also be used for systems that are already deployed. New features or changed recommendations might apply to your environment. It's useful to review the checklist periodically to ensure you're aware of new features in the Azure platform.

Main content in this document is organized in tabs, in a typical project's chronological order. See content of each tab and consider each next tab to build on top of actions done and learnings obtained in the previous phase. For production migration, the content of all tabs should be considered and not just production tab only. To help you map typical project phases with the phase definition used in this article, consult the below table.

Deployment checklist phases Example project phases or milestones
Preparation and planning phase Project kick-off / design and definition phase
Pilot phase Early validation / proof of concept / pilot
Non-production phase Completion of the detailed design / non-production environment builds / testing phase
Production preparation phase Dress rehearsal / user acceptance testing / mock cut-over / go-live checks
Go-live phase Production cut-over and go-live
Post-production phase Hypercare / transition to business as usual

Project preparation and planning phase

During this phase, you plan the migration of your SAP workload to the Azure platform. Documents such as planning guide for SAP in Azure and Cloud Adoption Framework for SAP cover many topics and help as information in your preparation. At a minimum, during this phase you need to create the following documents, define, and discuss the following elements of the migration:

High-level design document

This document should contain:

  • The current inventory of SAP components and applications, and a target application inventory for Azure.
  • A responsibility assignment matrix (RACI) that defines the responsibilities and assignments of the parties involved. Start at a high level, and work to more granular levels throughout planning and the first deployments.
  • A high-level solution architecture. Best practices and example architectures from Azure Architecture Center should be consulted.
  • A decision about which Azure regions to deploy to. See the list of Azure regions, and list of regions with availability zone support. To learn which services are available in each region, see products available by region.
  • A networking architecture to connect from on-premises to Azure. Start to familiarize yourself with the Azure enterprise scale landing zone concept.
  • Security principles for running high-impact business data in Azure. To learn about data security, start with the Azure security documentation.
  • Storage strategy to cover block devices (Managed Disk) and shared filesystems (such as Azure Files or Azure NetApp Files) that should be further refined to file-system sizes and layouts in the technical design document.

Technical design document

This document should contain:

  • A block diagram for the solution showing the SAP and non-SAP applications and services
  • An SAP Quicksizer project based on business document volumes. The output of the Quicksizer is then mapped to compute, storage, and networking components in Azure. Alternatively to SAP Quicksizer, diligent sizing based on current workload of source SAP systems. Taking into account the available information, such as DBMS workload reports, SAP EarlyWatch Reports, compute and storage performance indicators.
  • Business continuity and disaster recovery architecture.
  • Detailed information about OS, DB, kernel, and SAP support pack versions. It's not necessarily true that every OS release supported by SAP NetWeaver or S/4HANA is supported on Azure VMs. The same is true for DBMS releases. Check the following sources to align and if necessary, upgrade SAP releases, DBMS releases, and OS releases to ensure SAP and Azure support. You need to have release combinations supported by SAP and Azure to get full support from SAP and Microsoft. If necessary, you need to plan for upgrading some software components. More details on supported SAP, OS, and DBMS software are documented here:

Further included in same technical document(s) should be:

  • Storage Architecture high level decisions based on Azure storage types for SAP workload
    • Managed Disks attached to each VM
    • Filesystem layouts and sizing
    • SMB and/or NFS volume layout and sizes, mount points where applicable
  • High availability, backup and disaster recovery architecture
    • Based on RTO and RPO, define what the high availability and disaster recovery architecture needs to look like.
    • Understand the use of different deployment types for optimal protection.
    • Considerations for Azure Virtual Machines DBMS deployment for SAP workloads and related documents. In Azure, using a shared disk configuration for the DBMS layer as, for example, described for SQL Server, isn't supported. Instead, use solutions like:
    • For disaster recovery across Azure regions, review the solutions offered by different DBMS vendors. Most of them support asynchronous replication or log shipping.
    • For the SAP application layer, determine whether you'll run your business regression test systems, which ideally are replicas of your production deployments, in the same Azure region or in your DR region. In the second case, you can target that business regression system as the DR target for your production deployments.
    • Look into Azure Site Recovery as a method for replicating the SAP application layer into the Azure DR region. For more information, see a set-up disaster recovery for a multi-tier SAP NetWeaver app deployment.
    • For projects required to remain in a single region for compliance reasons, consider a combined HADR configuration by using Azure Availability Zones.
  • An inventory of all SAP interfaces and the connected systems (SAP and non-SAP).
  • Design of foundation services. This design should include the following items, many of which are covered by the landing zone accelerator for SAP:
    • Network topology within Azure and assignment of different SAP environment
    • Active Directory and DNS design.
    • Identity management solution for both end users and administration
    • Azure role-based access control (Azure RBAC) structure for teams that manage infrastructure and SAP applications in Azure.
    • Azure resource naming strategy
    • Security operations for Azure resources and workloads within
  • Security concept for protecting your SAP workload. This should include all aspects – networking and perimeter monitoring, application and database security, operating systems securing, and any infrastructure measures required, such as encryption. Identify the requirements with your compliance and security teams.
  • Microsoft recommends either Professional Direct, Premier or Unified Support contract. Identify your escalation paths and contacts for support with Microsoft. For SAP support requirements, see SAP note 2015553.
  • The number of Azure subscriptions and core quota for the subscriptions. Open support requests to increase quotas of Azure subscriptions as needed.
  • Data reduction and data migration plan for migrating SAP data into Azure. For SAP NetWeaver systems, SAP has guidelines on how to limit the volume of large amounts of data. See this SAP guide about data management in SAP ERP systems. Some of the content also applies to NetWeaver and S/4HANA systems in general.
  • An automated deployment approach. Many customers start with scripts, using a combination of PowerShell, CLI, Ansible and Terraform. Microsoft developed solutions for SAP deployment automation are:

Σημείωση

Define a regular design and deployment review cadence between you as the customer, the system integrator, Microsoft, and other involved parties.

Automated checks and insights in SAP landscape

Several of the checks above are checked in automated way with SAP on Azure Quality Check Tool. These checks can be executed automated with the provided open-source project. While no automatic remediation of issues found is performed, the tool will warn about configuration against Microsoft recommendations.

Φιλοδώρημα

Same quality checks and additional insights are executed regularly when SAP systems are deployed or registered with Azure Center for SAP solution as well and are part of the service.

Further tools to allow easier deployment checks and document findings, plan next remediation steps and generally optimize your SAP on Azure landscape are:

  • Azure Well-Architected Framework review An assessment of your workload focusing on the five main pillars of reliability, security, cost optimization, operation excellence and performance efficiency. Supports SAP workloads and recommended to running a review at start and after every project phase.
  • Azure Inventory Checks for SAP An open source Azure Monitor workbook, which shows your Azure inventory with intelligence to highlight configuration drift and improve quality.

Next steps

See these articles: