Within the SAP Software Update Manager, there is the database migration option. DMO automates much of what we've already discussed with a classical migration. While it is technically possible to use DMO to migrate to the cloud, it isn't officially supported by SAP. However, DMO with system move is designed for migrating to the cloud. DMO with system move takes much of the downtime manual complexity out of the migration. DMO has a benchmark tool that will estimate migration times to aid with setting bandwidth size and downtime expectations.

In one step, it can perform a system upgrade, Unicode conversion if required, and a database to the cloud migration. As you would expect with an automated process, it is easier to implement; you don't need the same SAP certification as with a classical migration, but it is slightly less flexible, and there is less opportunity for performance tuning. DMO with system move only supports SAP HANA and SAP ASE as target databases, although other DBMS are available by request. It can't be used when the source DBMS is SAP HANA. Another DMO limitation is that it is designed to work with the ABAP stack. If your system runs Java components in a dual-stack configuration, then stacks have to be split before migration.

When you start a DMO with system move migration, the software update manager running on-premises begins by checking and preparing the source system. Once the source system is been prepared and is ready the shadow repository is created. The migration starts in earnest when data is exported to files on the source system, and these files are transferred via ExpressRoute or VPN to Azure. The exported files can be transferred to Azure either sequentially or in parallel. Sequential mode means that all files are exported to the SUM directory before the transfer to Azure occurs. Once all files have been uploaded to the cloud, then the import process begins.

As the name implies, a parallel data transfer mode starts transferring files to the target environment and begins the import process before the export process has finished. While there is limited opportunity to manually optimize a DMO migration, aside from determining the optimal number of R3Load processes, the software does have a form of AI that will optimize table splitting based on previous migration runs. It does this by detecting when the number of running R3Load processes falls below 90% of those configured to run. This is assumed to be an indication that no more tables are being extracted. The difference between this 90% point and the finish of the import process is called the tail. The goal is to have the shortest tail possible. The software update manager will use data from past migration runs to split tables, mix and match the table splits with smaller tables into packages, and then order the package execution to allow the maximum number of R3Load processes to be active simultaneously to minimize the tail and downtime.

It is clear with both the classical and DMO migration methods that the shortest downtime is achieved by a combination of the number of active parallel R3Load processes and the table makeup of the packages those processes execute. As the possible combinations of these factors are enormous, it is exceptionally unlikely that you will strike the optimum on the first run. In either scenario, that will take multiple repeat runs of the downtime phase for either you, using a classical migration, or for the DMO software to zero in on an optimal solution.

Near-zero downtime migration with DMO is basically a DMO migration where specified large tables are migrated in advance of the downtime or cutover period, but with replication to the target system set up. In addition to the normal migration process, any changes to those large tables are replicated. This is yet another variation on the divide and conquer strategy where only a small subset of the largest tables is migrated during the downtime.