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.
Typically, an SAP landscape will consist of at least three environments: Dev, QA, and Production. An SAP environment follows a three-tier architecture of database server, application server, and GUI or presentation layer. Network connectivity between the database and application layer must be very efficient with low latency, meaning they should be on the same network with no intervening gateways or firewalls. The GUI layer can be both desktop applications and browser-based, potentially adding another sub-layer in the form of a webserver. SAP uses its ABAP programming language and Java to extend system functionality, both of which rely on conversion to byte code form for execution. This typically translates into an SAP system running two software stacks. Keep this in mind as some SAP automated migration tools can only deal with one stack.
Most of the time, Production and QA will be very similar in terms of software versions and size, while Dev will usually be qualitatively different and much smaller.
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.