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.