Introduction and Overview
SAP to Azure Migration
Migrating an SAP landscape to Azure is a complicated task with lots of moving parts. Apart from the sheer volume of data, a migration can involve software upgrades and data conversions. Not only will a landscape need to work properly once migrated, but in most cases, the migration needs to happen quickly as SAP systems are usually the information backbone of an organization.
Once the target environment structure has been finalized the next important phase is planning the migration so that system downtime is kept to a minimum. There are different migration strategies to suit multiple scenarios and this course looks at which strategy works best for each scenario. We then look at ways to optimize a migration, and its pros, cons, and issues to look out for.
- Understand the main scenarios and considerations when migrating from SAP to Azure
- Learn the two methods for getting your data into Azure
- Understand the difference between homogeneous and heterogeneous migration
- Understand how the database migration option available in SAP can be used to migrate your data to Azure
- Learn about the SAP HANA Large Instances service from Azure
- Database administrators
- Anyone looking to migrate data from SAP to Azure
To get the most out of this course, you should have a basic knowledge of both Microsoft Azure and SAP.
Regardless of the specific migration method you adopt, there are considerations common to all you need to keep in mind. How much data will you be migrating? Will you need to make additional provisions to your network connectivity and bandwidth to ensure a smooth migration? Will you utilize the Azure data box service? Which is essentially sending your data on a USB drive via snail mail.
Be aware that IP addresses can change as a workload is transferred into Azure, so if an interface contains or uses a hardcoded IP address, it will need to be checked and possibly changed. It is preferable to use hostnames where possible so that you will just need to change the DNS entry. As most migrations aren't a one-time event but happen in phases and iterations, it is crucial to make sure interfaces are correctly configured. This is a small but essential detail that can be a source of considerable frustration if not well documented.
It is unlikely that you will be able to migrate all workloads simultaneously due to the size and number. Azure Migrate can analyze your current environment for dependencies or closely coupled workloads. These closely linked workloads can be grouped in what's called a move group. Each move group can constitute a migration phase. This will allow you to prioritize the migration in terms of downtime, migrating the workloads least sensitive to downtime first and the most critical ones last.
Not wishing to state the obvious, but your Azure target environment will need to be ready and correctly configured to accept the workloads and data. You can create the VMs with Azure Resource Manager templates and blueprints. This ensures consistent deployments and prevents configuration drift.
We will look at ARM templates in more detail in the Deploy and Migrate an SAP Landscape to Azure course. The ability to specify infrastructure as code enables you to quickly deploy and tear down an environment, which is especially useful in the development and test stages of the migration process. Having said that, you don't want to have the VM deployment as part of the migration process. You can create your VM and network environment semi-automatically with templates ahead of time, and if required, shut them down to reduce costs. Just bear in mind that a VM's allocated storage will still accrue charges.
The migration process provides the opportunity to clean up your data or archive off old data to reduce the amount that needs to be transferred. The ability to do this and the potential benefit is very much on a case-by-case basis. It could be just as easy to migrate everything and then cull or archive old or redundant data once the migration is done. Then resize the affected VM's to reduce costs further.
Having addressed these general migration considerations, which, to be fair, are not SAP specific, let's now turn our attention to planning the different elements of the migration process.
One of the main aims of migration is to reduce total system downtime. Preparing the new environment in terms of setting up infrastructure and installing software is not time sensitive. It's the time from when users can no longer make changes to the data in the current environment to when the data is available again, and the SAP system is up and running in the new Azure environment, the cutover period, that is critical. Copying data from the current on-premises location to the data center will be the most time hungry task for a majority of migrations so let's start by looking at that.
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.