Moving any large system from one environment to another is not a trivial process. When that system is the centerpiece of an organization's operations, getting it right first time is absolutely critical. It's definitely a case of measure twice, cut once. 

Let's have a look at the stages that would make up a project to successfully move an SAP landscape to Azure. 

Before you can start the project in earnest, you need to know what you are migrating. What does your current SAP landscape look like, and will you be relocating the existing landscape, or will you take the opportunity to upgrade SAP while migrating. Armed with this knowledge, you can decide if you will be rehosting or re-platforming. Rehosting is taking your current SAP environment and moving it, essentially unchanged, onto a new infrastructure host. This type of move is referred to as lift and shift or a homogeneous migration. Alternatively, suppose your current environment, that is, CPU architecture, OS, or database platform, isn't supported in Azure or you want to perform an SAP upgrade, then you'll be re-platforming, which will involve a heterogeneous migration. This phase also consists of sizing your current landscape so you can correctly specify Azure target resources.

The output from planning and preparation is a list of suitable compute and storage resources, including those needed for disaster recovery, within a high-level network design. The network design should incorporate security features and accommodate high availability functionality based on your recovery time objective (RTO) and recovery point objective (RPO). Along with compute infrastructure, be that virtual machines or bare metal servers, you will have ascertained which available operating systems and DBMS platforms are available to support your target landscape. Documentation should include an inventory of SAP interfaces, including those to non-SAP systems. Speaking of non-SAP components, you also need to assess and document system dependencies, such as any third-party systems or services integral to the current system's operation. Do those systems or services or equivalent substitutes exist in Azure? If not, are you able you deploy them to the Microsoft cloud or use them from a cloud infrastructure? This stage also involves deciding on naming conventions for infrastructure resources as well resource tags. A tag is text associated with a resource that appears on Azure billing statements, helping you manage cost centers.

It is highly recommended to do a proof of concept or pilot phase. There is a reason why history and language are littered with sayings like "the best-laid plans of mice and men" or "no plan survives contact with the enemy." You have dev and test environments in your SAP landscape, so why wouldn't you do the same with your SAP migration. When vast amounts of data are involved, a pilot migration is essential to see how the data transfer method copes and that you have allocated enough bandwidth for it to complete in a timely fashion.  This stage is also valuable when the migration is heterogeneous, perhaps including an SAP upgrade that involves significant data transformations. You can test and benchmark system performance as well as your high availability and disaster recovery solution with simulated outages. A pilot will confirm, or not, your compatibility assumptions concerning OS and database versions, as well as any third-party software or appliances you need as part of organizational compliance.

The non-production phase is migrating your dev and QA environments. This is essentially more deployment and migration testing, making sure your infrastructure resource definitions are correct. Additional migration testing helps to refine table-splitting strategies to improve data transfer speed. After deploying and migrating the QA environment, assuming it is a reasonable facsimile of production, you can use it for its intended purpose, that is, test operational behavior and performance with production type data. This includes user setup, permissions, and Azure Active Directory integration.

Production preparation includes upgrading any SAP software that is necessary for compatibility in the target environment. Deploy and prepare your target production environment. Complete all your system and data backups. If you are doing a staggered migration or one where replication will be employed, copy across slow-moving data before the system-down cutover period.

The go-live phase is the period from when the existing SAP system becomes unavailable for data modification, inserting or deleting, to when the newly deployed and updated target system becomes available for use. By this stage, you should have conducted multiple tests of the deployment and migration process with both the pilot stage and the non-production environments, so this should be an automated and mechanical process with little manual input. However, if there is a showstopping problem, your source system should be in a state where it can immediately resume its intended functionality. Once the migration has completed, you should conduct all your predefined validation testing, verifying the target system against the source system.

Postproduction is resuming standard operational functionality, monitoring, and administration as you would perform on the system hosted in your old infrastructure, with the addition of optimizations available within the Azure environment. This includes, but is not limited to, price-performance trade-off analysis regarding virtual machines and storage based on tagged resources in your Azure invoices.