Migrating SAP Workloads to Azure
Planning the migration
Start with an inventory of the SAP landscape: NetWeaver or S/4HANA release, database (HANA, AnyDB, ASE, SQL Server), OS, kernel version, sizing (SAPS and memory), and dependencies between systems. The migration method follows from downtime tolerance and database size: homogeneous lift-and-shift with export/import, backup/restore, or the Database Migration Option (DMO) of SUM for in-place upgrades plus migration. HANA system replication or log shipping reduces cutover windows for large databases.
Platform choices and traps
Questions often test whether a workload is certified. Large HANA instances must use Azure M-series or Mv2-series VMs, which are SAP-certified and require specific storage layouts; smaller systems fit E-series. Do not assume any VM size is certified - check the SAP Note for certified Azure instance types and the OS/database support matrix. Another trap is network design: ExpressRoute for production hybrid connectivity, and Azure Accelerated Networking plus proximity placement groups when latency between app and database tiers matters. Remember that Azure resource limits (vCPU per subscription, storage throughput) can block a large HANA scale-up; plan quotas early.
Worked example
A customer migrates a 6 TB HANA database with a 12-hour maintenance window. Rule of thumb: a full export/import of that size will not fit the window, so pre-seed with HANA system replication or backup/restore to the target, then perform a short delta cutover. Provision an M-series VM, attach premium storage or Azure NetApp Files per the certified layout, and validate with SAP Note checks before go-live.