The starting point with any migration project is determining what exactly is to be migrated. On the face of it, this may seem like a straightforward task. Moving from an on-premises or privately hosted environment to Azure is just swapping one infrastructure for another. However, migrating an SAP landscape to Azure presents some unique challenges that can only be adequately addressed if we accurately know the current source state, that is, the existing landscape.
Azure does not support all the hardware, operating systems, and database platforms that SAP runs on. Moving to a new OS or database platform adds another significant dimension to the migration process. This course investigates which landscape elements need to be considered and how they can affect the deployment design along with the migration strategy. We will also see what tools are available to help with assessing an SAP landscape.
Learning Objectives
- Understand why existing landscape assessment is important
- Learn ways to find landscape components
- Learn methods to determine landscape size and database size
- Understand how can Azure Migrate help with landscape assessment
Intended Audience
This course is intended for anyone who is looking to migrate their SAP landscape to an Azure environment and wants to understand what to consider before doing so.
Prerequisites
To get the most out of this course, you should have a basic understanding of Azure and SAP.
The heart of any software system is the hardware and OS that the applications, including the database management system, run on. When I talk about servers, I'm not differentiating between physical and virtual, whether that is VMware or Hyper-V. What is essential, in the context of migration is the underlying CPU architecture and operating systems. Some architectures and OSs, namely x64 running flavors of Windows Server and certain Linux distributions, e.g., RedHat, SUSE, and Oracle, have the potential to be directly transplanted into an Azure infrastructure in what's called a homogeneous migration. However, IBM's AIX, HP-UX, and Solaris source systems can't be transferred to Azure, meaning a different migration strategy is required, called heterogeneous.
The same principles apply when talking about database management systems. If you're not currently running an SAP DBMS or one supported on Azure like SQL Server or Oracle, then your migration strategy options will be different; that is, replication, and backup and restore is off the table – no pun intended.
Let's take a quick look at some of the SAP tools that can aid with landscape discovery.
You can list the application servers registered with the SAP message server by either executing the SM51 transaction or selecting Servers from System Monitoring within Monitor of System Administration inside Administration.
SAP's audit information system (AIS) is a tool that can be used to get a detailed security analysis of the SAP NetWeaver Application Server. The security audit log can record remote function calls, as well as successful and unsuccessful remote function call logon attempts.
There are a variety of third-party tools for mapping network topology, although none are SAP specific. SolarWinds is probably one of the most well-known, but recent negative publicity hasn't been helpful. Datadog Network Performance Monitor is a cloud-based tool that will scan and map out your network. Of course, there is manually drawing the network topology based on a server audit, and while relatively expensive, Microsoft Visio is still one of the "go-to" tools for this task. Having said that, there are plenty of good free network drawing packages available.
Most production SAP landscapes are critical to business operation, but not everyone's definition of critical is the same. Everyone wants their system to be operational 24x7, but can you tolerate downtimes for OS patching if you know in advance? Can you tolerate an unplanned system outage for 60 seconds or 5 minutes, or is any downtime unacceptable? Knowing your SLA commitments and those offered by the different Azure products and services will help you to determine your overall architecture in terms of high availability and disaster recovery. Database RTO – recovery time objective and RPO – recovery point objective parameters are vital information for deciding database high availability and disaster recovery strategy. Not only is landscape resiliency important from an operational aspect, but the solution you choose to implement can have a significant cost component.
Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.