AWS for SAP

Using the SAP Database Migration Option (DMO) to Migrate to AWS

Somckit Khemmanivanh is an SAP Solutions Architect at Amazon Web Services (AWS).

This blog post discusses how you can use the database migration option (DMO), which is a feature of the SAP Software Update Manager (SUM) tool, to migrate your anyDB database to SAP HANA on Amazon Web Services (AWS). SAP uses the term anyDB to refer to any SAP-supported, non-HANA source database (such as DB2, Oracle, or SQL Server). In this blog post, we will cover migration options from an on-premises architecture to AWS. (Note that there are many other migration options when SAP HANA is not your target platform; see the Migrating SAP HANA Systems to X1 Instances on AWS whitepaper for details.)

SAP HANA is a fully in-memory, columnar-optimized, and compressed database. The SAP HANA systems certified by SAP enable you to run your SAP HANA databases on systems ranging from 160+ GB of RAM up to 2 TB of RAM in a scale-up configuration. Certified scale-out configurations of up to 14 TB are also available. This system configuration flexibility enables AWS to scale to fit your business and IT needs. Please contact us if you have workloads requiring more memory—we’d like to work with you to satisfy your requirements.

For an introduction to DMO, see the SAP Community Network. At a high level, you can use DMO to migrate an SAP system that is running on anyDB to run on an SAP HANA database. You can also use DMO to upgrade your SAP system’s software components and to perform a Unicode conversion as part of your migration. (Note that as of Enhancement Package (EHP) 8, Unicode is mandatory.) The standard DMO process is an online and direct migration from your source anyDB to your target SAP HANA database.

sap-hana-dmo-process

Figure 1: SAP HANA DMO process

When your migration target is an SAP HANA system in the AWS Cloud, you must have your network connectivity in place to facilitate this direct migration process. Additionally, with the standard DMO process, SAP has specific restrictions, as detailed in SAP Note 2277055 – Database Migration Option (DMO) of SUM 1.0 SP18. (The SAP Notes referenced in this blog post require SAP Service Marketplace credentials.) This SAP note mentions restrictions when performing DMO transfers over a network connection (that is, between data centers). In our own testing and experience, latency does have some impact on the DMO runtime. We can help you evaluate your architecture and design and suggest possible solutions; please contact us at sap-on-aws@amazon.com.

On AWS, you have additional migration options beyond standard DMO. You can use automated migration products like ATAmotion, by AWS Advanced Technology Partner ATADATA, to replicate your source system (from your on-premises network) to AWS, and then use DMO to migrate the replicated system to SAP HANA. Please use the AWS Partner Solutions Finder to locate other AWS Partners who offer migration products and services.

Once your source systems are in AWS, you can leverage the agility and flexibility of AWS services to test your migration and to perform live migrations. An example scenario would be to run multiple tests to optimize your DMO downtime. With each test, you can take advantage of EC2 instance resizing to try different system sizes and combinations.

Now that we’ve covered the high-level processes and tools, let’s discuss the steps involved in the two migration options. We will start with the standard DMO migration process. This process assumes that your existing SAP systems reside in your on-premises data center, and that the single component that needs access to AWS is your DMO server. During the migration, the DMO server exports data from your source database into the target SAP HANA database. The migration process consists of the following steps:

      1. Create an AWS account, if you don’t already have one.
      2. Establish virtual private network (VPN) or AWS Direct Connect connectivity between your data center and the AWS Region, as shown in this illustration from the AWS Single VPC Design brief published on the AWS Answers website. See the “Internal-Only VPC” section of the brief for design considerations and details.

        vpc-connectivity-for-dmo

        Figure 2: VPC connectivity for DMO migration

      3. Deploy your AWS SAP HANA database instance and SAP application instance. (For deployment instructions, see the SAP HANA Quick Start.)
      4. Deploy your DMO server. (You can choose to use a DMO server on premises or in AWS.) The DMO server can be a separate server or co-located with your SAP application server, depending on your source database size, performance needs, system resources, and downtime requirements. (See the SAP documentation for details on this step.)
      5. Test connectivity between your on-premises DMO server and your SAP HANA database instance on AWS. (See the Amazon VPC for On-Premises Network Engineers series on the APN blog for more information.)
      6. Migrate your on-premises database to your SAP HANA database on AWS using DMO. (See the SAP documentation for details.)
      7. Install new SAP application servers on AWS that are connected to your SAP HANA database instance. (See the SAP documentation for details.)

dmo-migration

Figure 3: Standard DMO architecture

The second migration option we’ll discuss is to use an AWS Partner tool to replicate your source system on AWS, and then to migrate your system to SAP HANA. To use this process, your existing SAP systems must reside in your on-premises data center. The steps are similar to the standard DMO process:

      1. Create an AWS account, if you don’t already have one.
      2. Establish VPN or AWS Direct Connect connectivity between your data center and the AWS Region, as shown in this illustration from the AWS Single VPC Design brief published on the AWS Answers website. See the “Internal-Only VPC” section of the brief for design considerations and details.
      3. Replicate your source system on AWS. If you’re using ATAmotion, the ATADATA console is used to perform this replication.
      4. Deploy your SAP HANA database instance and SAP application instance on AWS. (For deployment instructions, see the SAP HANA Quick Start.)
      5. Deploy your DMO server on AWS. The DMO server can be a separate server or co-located with your SAP application server, depending on your source database size, performance needs, system resources, and downtime requirements. (See the SAP documentation for details on this step.)
      6. Run the DMO migration process against the source system that you replicated in step 3. Finalize the migration process on AWS. (See the SAP documentation for details.)
      7. Install new SAP application servers on AWS that are connected to your SAP HANA database instance. (See the SAP documentation for details.)

partner-migrationFigure 4: DMO architecture with ATADATA

Now let’s discuss some of the aspects of the architecture and design that are common to both migration options.

Network connection (bandwidth and latency)

For the network connection between your data center and AWS, you can use either a VPN or AWS Direct Connect, depending on how much data you need to transfer and how quickly you want to complete the migration. The amount of data to transfer correlates to the size of your target SAP HANA database. For example, if your source database size is ~2 TiB, the target SAP HANA database size may range from 250 to 600 GiB. (This estimate assumes the standard 1:4 or 1:5 times HANA compression ratio, although we have observed even higher compression ratios.) You would need to transfer 200-250 GiB over the network. You can get a good estimate of your target database size from the SAP sizing reports in SAP Note 1793345 – Sizing for SAP Suite on HANA and SAP Note 1736976 – Sizing Report for BW on HANA.

We recommend that you establish a reliable network connection to avoid interruptions and having to resend data during the migration process. AWS Direct Connect offers the most reliability and bandwidth over a VPN connection.

SAP application servers

DMO only migrates the source database to the target SAP HANA database—it does not set up SAP application servers. You will need to install new SAP application servers in AWS after your DMO migration is complete. You can choose from various installation scenarios, including:

You will need to decide on the best installation option based on your organization’s requirements, constraints, sizing, cost, complexity, and other tradeoffs.

There are many AWS technologies available to help streamline your SAP application server installation and configuration process. These include using AWS CloudFormation templates, creating an Amazon Machine Image (AMI) from a snapshot, and using the Amazon EC2 Run command. We will cover these topics in upcoming blog posts.

SAP virtual names

SAP systems can resolve host names via DNS or through your local hosts file. We recommend that you use DNS in combination with SAP virtual names for your SAP systems. Using SAP virtual names will make the migration easier by allowing you to keep the same virtual name on AWS. For details, see SAP Note 962955 – Use of virtual or logical TCP/IP host names.

Start small

SAP migrations are complex, and proper planning is needed to minimize any potential issues. We recommend that you first target smaller, standalone SAP systems to familiarize yourself with AWS and SAP on AWS. Such systems could potentially be sandbox, development, training, demo, and SAP Internet Demonstration and Evaluation System (IDES) environments. If you decide not to proceed with the SAP DMO migration, your existing source system will still be fully functional—you would just need to re-enable it.

Drop us a line at sap-on-aws@amazon.com if you have any questions. For specific SAP on AWS support issues, please create an SAP Support Message with the components BC-OP-LNX-AWS or BC-OP-NT-AWS.

Thanks for reading!

— Somckit