The course is part of this learning path
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.
Whether HANA or a traditional disk-based RDBMS – AnyDB, the size of your SAP database will significantly impact storage requirements and the choices of virtual machines you can choose from. In fact, a very large HANA database, over 12TB, will exclude the use of a virtual machine as a database server, and you'll have to use a bare metal server know as a HANA Large Instance (HLI). It's not just the size of the production DB while in use that has to be considered. You will also need to think about backup storage and how long backups need to be kept. High availability and redundancy will also impact the amount of storage required and consequently cost. The type of high availability you choose to implement, that is just locally redundant or geo-redundant will affect network traffic and cost.
Within SAP, there are multiple ways to measure an existing database's size depending on the database type. If you are currently running AnyDB and plan to move to HANA as part of the migration, use the ABAP sizing report, also referred to as the HANA sizing report – see SAP note 1872170. Sizing HANA for BW systems requires an additional report, HANA_BW_SIZING, which is also suitable for BW/4HANA estimates – see SAP note 2296290. If you plan to upgrade to S/4HANA, SAP has a self-service readiness check tool for S/4HANA, which is included in your SAP support contract.
Suppose you are currently running AnyDB and will continue to run a traditional relational database in Azure. In that case, you can use SQL scripts or whatever management tools your database software has.
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.